Back
[00:07:28] -!- Tecan has quit [Quit: Ex-Chat]
[00:07:48] -!- Tecan has quit [Changing host]
[00:15:30] -!- mendes has quit [Client Quit]
[00:17:20] -!- cmorley1 has quit [Ping timeout: 255 seconds]
[00:20:06] -!- micges has quit [Quit: Leaving]
[00:22:38] Tom_sbc is now known as Tom_itx
[00:29:11] -!- wildbilldonovan has quit [Read error: Connection reset by peer]
[00:41:56] toudi_ is now known as micges
[00:47:46] -!- wildbilldonovan has quit [Quit: EOT]
[00:54:04] -!- mephux has quit [Excess Flood]
[00:57:55] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:59:18] -!- asdfasd has quit [Ping timeout: 248 seconds]
[01:00:23] -!- micges has quit [Quit: Leaving]
[01:02:32] toudi_ is now known as micges
[01:06:42] -!- bedah has quit [Remote host closed the connection]
[01:07:02] -!- Brandonian has quit [Quit: Brandonian]
[01:07:43] -!- snkashis has quit [Quit: Page closed]
[01:22:54] -!- Tecan has quit [Quit: Ex-Chat]
[01:22:56] -!- jp_ has quit [Ping timeout: 245 seconds]
[01:25:46] -!- PCW has quit [Remote host closed the connection]
[01:33:42] -!- skorasaurus has quit [Quit: left the building.]
[01:35:13] -!- rob__H has quit [Ping timeout: 240 seconds]
[01:37:15] -!- TheLargeRod has quit [Quit: Leaving.]
[01:43:50] -!- plushy has quit [Quit: Leaving.]
[01:52:13] -!- mozmck has quit [Quit: Leaving.]
[01:53:39] -!- V0idExp1 has quit [Quit: Leaving.]
[01:54:37] -!- FinboySlick has quit [Quit: Leaving.]
[01:55:13] -!- cmorley has quit [Ping timeout: 248 seconds]
[02:00:05] -!- jst has quit [Read error: Operation timed out]
[02:07:32] -!- Tecan has quit [Changing host]
[02:10:32] -!- Servos4ever has quit [Quit: ChatZilla 0.9.89 [SeaMonkey 2.14.1/20121129191050]]
[02:39:10] -!- adb has quit [Read error: Connection reset by peer]
[02:49:45] -!- micges has quit [Quit: Leaving]
[02:51:25] -!- ve7it has quit [Remote host closed the connection]
[02:52:53] -!- cmorley1 has quit [Ping timeout: 252 seconds]
[02:54:56] -!- andypugh has quit [Quit: andypugh]
[02:55:58] -!- cmorley has quit [Ping timeout: 256 seconds]
[03:02:13] -!- cmorley1 has quit [Ping timeout: 240 seconds]
[03:05:56] -!- Wildhoney has quit [Ping timeout: 252 seconds]
[03:18:33] -!- sumpfralle has quit [Read error: Operation timed out]
[03:22:27] -!- dr00bie has quit [Read error: Connection reset by peer]
[03:43:50] -!- cmorley has quit [Ping timeout: 256 seconds]
[03:49:13] -!- nOStahl has quit [Quit: nOStahl]
[03:50:38] -!- cmorley1 has quit [Ping timeout: 256 seconds]
[03:57:13] -!- nOStahl has quit [Read error: Connection reset by peer]
[04:22:23] -!- cevad has quit [Quit: Leaving]
[04:26:56] -!- mhaberler [mhaberler!~mhaberler@extern-187.stiwoll.mah.priv.at] has joined #linuxcnc3
[04:43:47] -!- ravenlock has quit [Ping timeout: 248 seconds]
[04:50:55] -!- cmorley has quit [Ping timeout: 260 seconds]
[05:06:38] -!- AR_ has quit [Ping timeout: 252 seconds]
[05:45:15] -!- Keknom has quit [Quit: Leaving.]
[05:45:20] -!- FinboySlick has quit [Quit: Leaving.]
[05:45:31] -!- [Chance] has quit [Ping timeout: 260 seconds]
[05:56:01] -!- mhaberler has quit [Quit: mhaberler]
[05:59:35] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc3
[05:59:47] -!- AR__ has quit [Ping timeout: 255 seconds]
[06:01:40] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:15:36] -!- cmorley1 has quit [Quit: Leaving.]
[07:07:11] -!- tayy has quit [Remote host closed the connection]
[07:16:10] -!- ktchk has quit [Client Quit]
[07:27:02] frewsxcv is now known as frewsxcv94709
[07:32:41] -!- DaveCVI has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Organize your IRC]
[08:47:27] -!- [Chance] has quit [Ping timeout: 244 seconds]
[09:08:04] -!- racycle has quit [Quit: racycle]
[09:18:25] -!- rob_h [rob_h!~rob_h@5e04027e.bb.sky.com] has joined #linuxcnc3
[09:32:30] -!- vladimirek has quit [Remote host closed the connection]
[10:04:49] -!- Wildhoney has quit [Ping timeout: 248 seconds]
[10:34:35] -!- psha has quit [Quit: Lost terminal]
[10:46:52] -!- mattions_ has quit [Quit: Leaving]
[10:50:40] -!- mattions has quit [Remote host closed the connection]
[10:59:59] -!- pjm_ has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
[11:15:43] -!- micges has quit [Quit: Leaving]
[11:15:45] -!- motioncontrol has quit [Client Quit]
[11:26:33] -!- hdokes has quit [Quit: When the chips are down, well, the buffalo is empty]
[11:34:51] -!- micges has quit [Quit: Leaving]
[11:41:29] -!- syyl has quit [Ping timeout: 256 seconds]
[11:45:11] -!- sumpfralle has quit [Ping timeout: 244 seconds]
[12:06:58] -!- phantoxeD has quit [Read error: Operation timed out]
[12:34:54] -!- cmorley has quit [Ping timeout: 264 seconds]
[14:26:11] -!- bedah has quit [Ping timeout: 248 seconds]
[14:50:05] -!- gimps has quit []
[15:00:54] -!- jp__ has quit [Read error: Connection reset by peer]
[15:23:19] -!- Wildhoney has quit []
[15:30:42] -!- bedah2 has quit [Quit: bye]
[15:37:40] -!- motioncontrol has quit [Quit: Sto andando via]
[15:44:15] -!- [Chance] has quit []
[15:59:18] -!- kwallace has quit [Ping timeout: 252 seconds]
[16:13:28] -!- skorasaurus has quit [Ping timeout: 245 seconds]
[16:17:32] -!- norbert [norbert!~norbert@a89-182-180-224.net-htp.de] has joined #linuxcnc3
[16:41:58] -!- firephoto has quit [Quit: ZNC - http://znc.in]
[16:42:40] -!- hashfail has quit [Read error: Connection reset by peer]
[16:48:20] firephoto_ is now known as firephoto
[16:55:35] -!- skorasaurus has quit [Quit: left the building.]
[17:15:57] -!- ve7it has quit [Remote host closed the connection]
[17:23:47] -!- mattions has quit [Ping timeout: 248 seconds]
[17:42:25] -!- hdokes has quit [Ping timeout: 248 seconds]
[17:52:53] -!- jmk-mcfaul [jmk-mcfaul!~jmkasunic@adsl-75-33-43-57.dsl.bcvloh.sbcglobal.net] has joined #linuxcnc3
[17:53:37] <jmk-mcfaul> anybody home?
[17:54:55] <mhaberler> yessir!
[17:55:01] <jmk-mcfaul> hi!
[17:55:06] <mhaberler> hi!
[17:55:19] <mhaberler> I have this buddy in the uk, an ex-office
[17:55:20] <jmk-mcfaul> I wish I could be more active in this
[17:55:30] <jmk-mcfaul> my weekdays are useless
[17:55:47] <mhaberler> I always start with 'permission to speak, Sir!!' on skype
[17:56:00] <mhaberler> occasional advice is good
[17:56:35] <mhaberler> did you read through all my mail blurbs ;-?
[17:56:44] <mhaberler> the last one is key I think
[17:56:53] <jmk-mcfaul> read them as they came in, I need to read again
[17:58:09] <jmk-mcfaul> the part about things being able to come and go at any time
[17:58:18] <jmk-mcfaul> that is true in HAL today
[17:58:40] <mhaberler> right
[17:58:41] <jmk-mcfaul> people rarely choose to do so, but you can load or unload a component, connect or unconnect a signal anytime you want
[17:58:50] <mhaberler> yes
[17:59:09] <jmk-mcfaul> just like cutting wires on a working physical machine, you better know what you are doing or you will break something
[17:59:47] <mhaberler> right, that's why I used that 'loose/connected wire' paradigm, I think its as close as it gets
[18:00:26] <mhaberler> NB: a wire with a loose end is a different concept from an unlink in my scheme
[18:00:39] <jmk-mcfaul> you seem to treat distributed as a different case though, where such things are more likely to happen, and possibly not under the direction of a human
[18:01:21] <jmk-mcfaul> IOW, unreliable communication links
[18:01:25] <mhaberler> well its like I said, there are new failure modes like netlinks coming or going
[18:01:27] <mhaberler> exactly
[18:01:45] <mhaberler> the question is: do you represent that in the model somehow
[18:02:03] <mhaberler> if not, you push it to comps doing that, likely in a non-uniform way
[18:02:04] <jmk-mcfaul> well, a failure of communications between the realtime engine that is running a cutting tool, and the user interface, is IMO a cause for an emergency stop
[18:02:24] <mhaberler> exactly, which is why it needs to be detected
[18:02:58] <jmk-mcfaul> it seems like the latent pin approach is a very complex approach to that
[18:03:01] <mhaberler> note however I see these remote links more in the command&control/UI plane, not really in the inner logic of the machine
[18:03:07] <jmk-mcfaul> it goes far beyond simple detection
[18:03:31] <jmk-mcfaul> yes, that is another difference between our views of the problem
[18:03:36] <mhaberler> well I have a tentative protocol design which does that; not, it isnt just linking
[18:03:40] <mhaberler> or unlinking
[18:03:50] <jmk-mcfaul> I can tell that you are looking at the problem as "how do we remote the UI"
[18:04:01] <mhaberler> no, the protocol is more general
[18:04:06] <jmk-mcfaul> I'm looking at it as "how do we distribute HAL"
[18:04:12] <mhaberler> it allows for completely symmmetric mirroring
[18:04:30] <mhaberler> it might be some scenarios, like the gladevcp case, only require a subset
[18:04:33] <jmk-mcfaul> so you could have two RT HALs in the two different computers?
[18:04:38] <mhaberler> yes
[18:04:51] <jmk-mcfaul> ok, I must have missed something somewhere
[18:05:19] <mhaberler> the _protocol_ does; the most pressing use case going forward is the UI case
[18:05:34] <jmk-mcfaul> damn I wish we were in person. I need a pencil and paper, this is much easier to understand with diagrams
[18:05:35] <mhaberler> thats why it looked single purpose probably
[18:05:47] <mhaberler> yes, a flipchart would go a long way
[18:06:13] <mhaberler> if you want I give you a short rundown starting from requirements
[18:06:31] <jmk-mcfaul> ok
[18:06:41] <mhaberler> ok, let me fetch that..
[18:07:47] <mhaberler> ok.
[18:07:55] <mhaberler> goal of protocol: Bridging HAL namespaces by messaging.
[18:08:05] <jmk-mcfaul> stop
[18:08:15] <mhaberler> that is a tad fuzzy, I agree
[18:08:34] <jmk-mcfaul> you are using messaging in the computer scientist way :-)
[18:09:01] <mhaberler> connecting wires between HAL namespaces, and dealing with a plug beaing pulled
[18:09:04] <jmk-mcfaul> do you mean "providing access to a single hal namespace on two computers"
[18:09:21] <mhaberler> no, the proto is for arbitrary number of namespaces
[18:09:31] <jmk-mcfaul> or do you means connecting some subset of signals between two separate hal namespaces on two computers
[18:09:48] <mhaberler> it is assumed that namespaces overlap to some extent
[18:09:49] <jmk-mcfaul> s/two/two or more, my question still stands
[18:10:01] <mhaberler> so linking pins and signals makes sense
[18:10:08] <mhaberler> two or more
[18:10:24] <mhaberler> that comes into play in the binding negotitation phase
[18:10:30] <jmk-mcfaul> my question is still not answered, I'm apparently not phrasing it right
[18:10:37] <mhaberler> n >= 2
[18:10:49] <jmk-mcfaul> understood that part, the size of N is not the question
[18:10:49] <mhaberler> n.. number of HAL namespaces
[18:10:55] <mhaberler> oh
[18:11:11] <jmk-mcfaul> you talk about linking making sense across namespaces
[18:11:47] <mhaberler> yes, that would be the matching and linking of 'loose wires' if you will
[18:11:48] <jmk-mcfaul> that makes it sound like you want to achieve "transparent" linking, where a user can specify a net command and the endpoints get connected even if they are on different computers
[18:12:01] <mhaberler> you look at the wire labels and twist them together
[18:12:10] <jmk-mcfaul> to my eyes, that is a single namespace
[18:12:44] <mhaberler> that is the matching/linking thing and it is worth consideration in detail, but youre too far ahead
[18:12:55] <jmk-mcfaul> the datapipe concept is different, it says there are two completely separate HALs (and namespaces), and you explicitly decide what gets connected between the two
[18:13:02] <mhaberler> let me define it as I see it:
[18:13:33] <mhaberler> for linking to make sense, there must be subsets of names and objects where names match, and object type and direction match
[18:13:47] <mhaberler> it does not require exactly identical namespaces
[18:13:59] <mhaberler> to have any effect, there must be a nonempty subset
[18:14:12] <mhaberler> common subset with the above criterium
[18:14:36] <jmk-mcfaul> nowhere is it written that the names must match at all
[18:14:59] <jmk-mcfaul> the person making the connections can decide that "foo" in this namespace should be connected to "bar" in that one
[18:15:07] <mhaberler> no, that is correct,, but you would want to enable that case
[18:15:20] <mhaberler> because of the config breakage aspect
[18:15:33] <jmk-mcfaul> just like within a single HAL he can decide that or2.0.out should be connected to mux2.3.sel
[18:15:35] <mhaberler> I am not saying it has to be the only case
[18:15:52] <jmk-mcfaul> oh, that gets back to another thing you said that confused me
[18:15:54] <mhaberler> for me that is a string requirement that that case not be excluded+
[18:15:57] <jmk-mcfaul> "config breakage"
[18:16:19] <mhaberler> look at gladevcp linked into HAL today
[18:16:42] <jmk-mcfaul> I think it is unreasonable (and perhaps unwise) to expect a set of config files targeted at a single PC system to work on a distributed system
[18:16:48] <mhaberler> you have 'gladevcp.button1', a pin, which is linked to say or2.in.1 i
[18:17:04] <mhaberler> tell that to the IETF, sorry
[18:17:16] <jmk-mcfaul> the who?
[18:17:33] <mhaberler> there is absolutely no reason to distinguish these cases _at the naming level_
[18:17:40] <mhaberler> (internet standards body)
[18:17:56] <jmk-mcfaul> what does internet standard have to do with designing machine tools?
[18:18:01] <mhaberler> it has to be distinguished, but not at the namespace level
[18:18:17] <mhaberler> well for instance the decoupling of IP addresses and domain names?
[18:18:30] <jmk-mcfaul> for someone to design a distributed machine tool control system without explicitly deciding what functions are on which PC seems utterly reckless to me
[18:18:37] <mhaberler> you have consistent naming whatever the underlying address setup looks like
[18:18:52] <mhaberler> you decide too early.
[18:18:58] <mhaberler> you havent heard the story yet.
[18:19:50] <jmk-mcfaul> the part of the story where you say that Gene Heskett should be able to take his non-distributed config and distribute it without editing any files (and therefore without making any design decisions) is the part that worrys me
[18:20:23] <mhaberler> I have no issue if you want to reflect a distributed setup in naming
[18:20:43] <mhaberler> the problem comes in if you force it for trivial scenarios where there is no value but downside
[18:21:03] <mhaberler> as far as linuxcnc goes now:
[18:21:32] <mhaberler> if gladevcp runs on machine X and HAL on Y, or X=Y: why should the UI setup care?
[18:21:41] <mhaberler> if you link several machines, that makes sense
[18:21:43] <mhaberler> not here
[18:22:07] <mhaberler> this is why I want to not exclude that case
[18:22:42] <jmk-mcfaul> I can understand if there is a general solution, and then you provide a shorthand or convenience that helps the special case
[18:22:56] <jmk-mcfaul> but this seems more like designing with the special case in mind
[18:23:12] <jmk-mcfaul> and I have been completely unable to grasp the general solution
[18:23:32] <mhaberler> well of course, we're not there yet
[18:23:37] <mhaberler> how should you
[18:23:47] <jmk-mcfaul> well, I guess that is the problem
[18:23:51] -!- Loetmichel has quit [Ping timeout: 260 seconds]
[18:23:55] <jmk-mcfaul> I want to start with the general solution
[18:23:56] <mhaberler> can I go back to requirements?
[18:24:18] <jmk-mcfaul> well, one of the requirements was "don't break existing configs", and that is the thing I had issue with
[18:24:32] <mhaberler> you really lock onto a perceived issue fast
[18:24:48] <mhaberler> (I have only part of it formulated as sentences partially; parts are still notes)
[18:25:01] <mhaberler> ok, I'll start.
[18:25:11] <jmk-mcfaul> I'm sure I'm not getting the big picture
[18:25:28] <jmk-mcfaul> what worrys me is that if I have trouble getting the big picture, others will too
[18:25:51] <mhaberler> would you just give me a bit of time to explain?
[18:26:06] <mhaberler> before jumping to the conclusion 'this is too complex'?
[18:26:07] <jmk-mcfaul> ok, I'll shut up and listen :-)
[18:26:18] <mhaberler> I appreciate it
[18:27:03] Cylly is now known as Loetmichel
[18:27:32] <mhaberler> (explanatory: The connection of name spaces will come through an exchange of messages, structs if you will, and based on actions thereof; the sum of state, messages and actions I will call 'protocol')
[18:28:11] <mhaberler> there are MUST, MUST NOT, SHOULD, MAY, OR MAY NOT to define hard or soft requirements
[18:28:26] <mhaberler> 1. The protocol SHOULD be symmetrical, and enable symmetric mirroring of an arbitrary number of HAL namespaces
[18:28:34] <mhaberler> 2. The protocol MUST NOT rely on a specific startup order of parties.
[18:28:48] <mhaberler> 3. The protocol MUST deal with parties vanishing and restarting, as well as temporary and permanent link failures.
[18:29:12] <mhaberler> (1 really means there is no reuired master/slave relationship).
[18:30:04] <jmk-mcfaul> is 1-3 the complete list, or are you still typing?
[18:30:29] <mhaberler> 4. The protocol is based on message exchanges between peers. A peer can be a bona-fide HAL namespace with comps, or just a program like *VCP.
[18:30:59] <mhaberler> (that covers the 'linking of machines' case as well as the UI simple scenario).
[18:31:08] <mhaberler> sorry, slow typer
[18:31:25] <jmk-mcfaul> no rush
[18:32:06] <mhaberler> 5. Partial implementations should be possible (meaning it is ok to use a subset of the protocol for simple cases like *VCP, and it is not required each party requires the full monty to be implemented).
[18:32:56] <mhaberler> 6. The protocol MUST support strong type, direction and -number-of-writer-semantics type checking.
[18:33:12] <mhaberler> (means: please no accidential links of two writers for instance)
[18:34:18] <mhaberler> 7. The protocol MUST be able to deal with link loss, and session loss/reestablishment in a defined way. (simple example: link to HAL goes away - UI widgets are greyed out)
[18:36:02] <mhaberler> 8. The protocol MUST support strong linking semantics as per 6) in the face of peers going away, and restarting. The MUST be NO dangling references (meaning: within bounded time, either a 'remote wire' is visibly broken, or identically reestablished).
[18:37:18] <mhaberler> 9. The protocol MUST NOT assume any specifc transport mechanism (like TCP; could well be CANbus or whatever; this means the identification of peers and interactions MUST NOT exclude transports).
[18:37:37] <jmk-mcfaul> I apologize for my earlier interruptions - this list will be an excellent basis for discussion
[18:37:52] <mhaberler> yes, this is why I am writing it up ;)
[18:38:12] <jmk-mcfaul> I am copying the points to a text file so I don't have to scroll later
[18:38:22] <mhaberler> there is a log
[18:38:31] <mhaberler> of this channel, so we'll have a URI
[18:40:13] <mhaberler> 10. Usability. The protocol SHOULD to the largest extent possible avoid the need to pre-configure the linke/peer/naming structure. (this means two things: name DISCOVERY should be fully automatic; interaction like binding of pins/signals MUST follow a clearly defined consequence of user configuration)
[18:40:25] <mhaberler> that was probably a tad fuzzy. what I mean to say:
[18:41:50] <mhaberler> The is no 'oops, this pin is suddenly linked because a matching name appeared in a peer'. The linking MUST ONLY happen if both parties agree on the linking criteria (for the latter, there are several options to explore; I will propose one).
[18:42:59] <mhaberler> 11. Protocol version support: (practical consideration): Upgrades of the protocol, or extensions of message formats SHOULD NOT impact earlier implementations.
[18:43:16] <mhaberler> (that's something the Internet industry learned the hard way).
[18:44:08] <mhaberler> let me see for requirements (note they are abstract, and intentionally so); it seems that covers what I've written up so far
[18:44:19] <mhaberler> (doesnt say there's not a gaping hole)
[18:45:26] <jmk-mcfaul> copied and saved
[18:45:29] <mhaberler> lets talk requirements first; did I say this understandable/clear (this spec is not for Joe Chipcutter)
[18:45:40] <mhaberler> this is a directive to an implementer
[18:45:49] <jmk-mcfaul> I had several thoughts as they went by, in no particular order or logic
[18:46:06] <mhaberler> go ahead
[18:46:09] <jmk-mcfaul> there are certainly things that need to be clarified for me
[18:46:45] <jmk-mcfaul> define "parties" as used in 2 and 3. Is it computers, or processes on computers, or HAL components or?
[18:47:19] <mhaberler> good point; I need definitions. I mean this:
[18:48:11] <mhaberler> a HAL namespace, however small, identified by a communication endpoint (URI if you will) and an instance ID (eg UUID)
[18:48:45] <mhaberler> the instance ID enables checking for restarted parties
[18:48:57] <mhaberler> (I mixed up peer and party. It does need work)
[18:49:22] <jmk-mcfaul> is a "HAL namespace" more or less what I am used to seeing when I type "halcmd show all" ?
[18:49:41] <mhaberler> yes
[18:50:17] <mhaberler> logger[mah]: ping
[18:50:17] <logger[mah]> mhaberler: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc3/2013-02-16.html
[18:50:22] <jmk-mcfaul> didn't you say something about there not being a master/slave relationship? I don't see that in the riles
[18:50:31] <jmk-mcfaul> rules
[18:50:36] <jmk-mcfaul> although 4 says peer to peer
[18:50:42] <mhaberler> which rules, mine?
[18:50:50] <jmk-mcfaul> yes, the requirements that you lited
[18:50:51] <mhaberler> ah I see
[18:50:52] <jmk-mcfaul> listed
[18:51:19] <jmk-mcfaul> maybe the master/slave comment was before you started listing numbered requirements
[18:51:24] <mhaberler> yes. I think the _protocol_ should be p2p even if certain use cases look a bit like m/s
[18:51:37] <jmk-mcfaul> understood
[18:51:53] <jmk-mcfaul> there are certainly mechanics that will make many use cases look like m/s
[18:51:54] <mhaberler> this means:
[18:52:55] <mhaberler> any party must be prepared to accept, and deal with in a predefined manner, all of the protocol messages, even if some do not cause any action per se (really a robustness criterium)
[18:53:20] <jmk-mcfaul> ok, now you are confusing me again
[18:53:29] <jmk-mcfaul> wrt definition of party
[18:53:37] <jmk-mcfaul> you said a party is a HAL namespace
[18:53:56] <jmk-mcfaul> namespaces don't get messages, some process gets the message and acts on it
[18:53:58] <mhaberler> I use peer = party, the communication agent onto of the HAL namespace; it has a instance ID
[18:54:03] <jmk-mcfaul> said actions might affect the namespace
[18:54:24] <mhaberler> yes, by actions of a proxy agent which does the messaging and the protocol
[18:54:33] <mhaberler> lets look at 2 cases:
[18:55:08] <mhaberler> 1. assume linking multiple spindle machines to provide certain synchronisation mechanisms between the two
[18:55:14] <mhaberler> 2. the UI case
[18:55:51] <mhaberler> 1. this is likely a 'full' implementation of the protocol in a separate demon process which does the messaging job, and taps into HAL
[18:56:09] <mhaberler> 2. this will very likely just be some Python code in the HAL widget library
[18:56:21] <mhaberler> both are parties and implement the protocol
[18:56:31] <jmk-mcfaul> ok, let me digest that
[18:56:43] <jmk-mcfaul> I think you have hit on one of my objections
[18:58:24] <jmk-mcfaul> case 1 is "OK" - it looks like my datapipe concept, but with extra capabilitites. The point is that it has the same interface to HAL as any other component (I think, maybe you have something else in mind). Case 2 means that you have special messaging capabilities built into the components themselves. IOW, there are two kinds of comps, those that can message and those that can;t
[18:59:11] <mhaberler> let me say that in a different way.
[19:00:19] <mhaberler> IMO it is not required for a 'party' to actually 'own a HAL namespace' with hal_lib.c, rtapi & the works. It is sufficient it talks the protocol. Thats' what's called the 'duck test' criterium.
[19:01:05] <mhaberler> the reason is: in some cases hal_lib.c & friends might not be needed and just baggage; if it is a standalone gui that certainly is the case
[19:01:08] <jmk-mcfaul> that makes me more confused
[19:01:47] <mhaberler> it isnt. The semantics is defined by the protocol. Some _actions_ based on the protocol may be implentation options
[19:01:55] <jmk-mcfaul> I _still_ don't understand whether you are really talking about multiple namespaces or just one
[19:02:03] <mhaberler> for instance, visibility of local 'HAL-like objects'
[19:02:19] <mhaberler> the difference comes from here:
[19:02:33] <jmk-mcfaul> if I an on computer 1, and I type "halcmd show sig", what do I see? If I am on computer 2 and I type "halcmd show sig", what do I see?
[19:02:36] <mhaberler> maybe you view 'the namespace' as the sum of names visible over all parties
[19:02:56] <mhaberler> in scenario 1) you will see the following:
[19:03:07] <mhaberler> a) all local HAL objects as always
[19:03:48] <mhaberler> b) those objects which are linked to remote objects, clearly tagged as such, and given state (connected or loose)
[19:04:04] <mhaberler> this is true for both parties
[19:04:37] <mhaberler> let's call those 'wires', maybe this is a useful term
[19:04:51] <mhaberler> a wire can be loose or connected
[19:05:24] <mhaberler> btw: it can have several connections (several remote observers are possible, as are local r/o pins)
[19:06:19] <jmk-mcfaul> b) needs some clarification (I hate the word object - it is too generic)
[19:06:35] <mhaberler> like HAL object - pin or signal
[19:06:36] <jmk-mcfaul> a means local signals and the local pins they connect to
[19:06:43] -!- jpk has quit [Ping timeout: 248 seconds]
[19:06:44] <mhaberler> yes, exactly
[19:07:04] <mhaberler> plus comps etc, which isnt part of what we talk about here
[19:07:05] <jmk-mcfaul> b means what? local signals and the remote pins they connect to? Or are signals that connect to some remote pin a unique kind of signal>
[19:07:17] <jmk-mcfaul> right, thats why I said "hal show sig"
[19:07:26] <mhaberler> ah, sorry
[19:08:06] <mhaberler> ok, to be honest I havent full made up my mind if the subject of wiring is a pin, or a signal - there are several pros and cons to that question
[19:08:15] <mhaberler> assume it is pins
[19:08:18] <jmk-mcfaul> heh
[19:08:42] <jmk-mcfaul> to me, that is a key concept and important to whether or not I understand things
[19:08:53] <jmk-mcfaul> no wonder I don't understand, you haven't decided yet :0
[19:09:04] <mhaberler> hey, slow with shooting down, please
[19:09:11] <jmk-mcfaul> not shooting
[19:09:19] <mhaberler> ok
[19:09:22] <jmk-mcfaul> just explaining why I don't understand - too abstract
[19:09:39] <jmk-mcfaul> I want to be able to imagine what halcmd show will show me, and what actions I would take to set things up
[19:09:45] <mhaberler> let me pull by you the tradeoffs either way
[19:09:58] <mhaberler> this is why propose to discuss this now.
[19:10:03] <jmk-mcfaul> OK
[19:10:22] <mhaberler> assume we link pins. The consequences are:
[19:11:16] <mhaberler> pins might not be connected, which has certain runtime consequences on the updating side (minor, but they exist)
[19:11:42] <mhaberler> since pins and signals relate N:1 updates might not be minimal (minor but possible)
[19:12:26] <mhaberler> the question really is: where is the signal -> pin mapping done (in which party, reporter or observer)
[19:13:00] <mhaberler> it can happen only once, but there are 2 options
[19:13:21] <mhaberler> your proposal was 'pins' at the originating side
[19:13:28] <mhaberler> (sending side of an update)
[19:13:35] <jmk-mcfaul> actually, my proposal was pins on both sides
[19:13:48] <mhaberler> right, but thats not what is the unit of _reporting_
[19:13:54] <mhaberler> (sending an update)
[19:14:01] <mhaberler> the remote end the source could care less
[19:14:15] <jmk-mcfaul> the users mental model cares a lot
[19:14:19] <mhaberler> sure
[19:14:29] <jmk-mcfaul> right now I'm looking at this from a users point of view
[19:14:52] <jmk-mcfaul> in fact, let me try to explain where my confusion is coming from
[19:14:56] <mhaberler> all I am saying: since there are now 2 parties involved, the question arises on which side the linking is done, and what is the unit of reporting
[19:15:09] <mhaberler> in reality _only_ signals can be reported
[19:15:22] <mhaberler> pins are just names for signals
[19:15:33] <mhaberler> maybe a default signal if not connected
[19:15:43] <jmk-mcfaul> pins are not names for signals
[19:15:49] <jmk-mcfaul> pins are the endpoints of signals
[19:16:11] <mhaberler> so why do they point to a default signal if they are not linked
[19:16:34] <jmk-mcfaul> because an unconnected pin must still have a value '
[19:16:35] <mhaberler> they _report_ a signal, wherever that comes from
[19:16:39] <mhaberler> well yes
[19:16:53] <mhaberler> and that is a signal in nature, it does have storage, doesnt it?
[19:17:25] <jmk-mcfaul> a signal has storage, yes
[19:17:32] <mhaberler> the duck test criterium for a signal is: does it have a memory address
[19:17:41] <jmk-mcfaul> I disagree
[19:17:54] <jmk-mcfaul> the duck test for a signal is "does it have a name"
[19:18:09] <mhaberler> no, because pins have one, too
[19:18:12] <jmk-mcfaul> on a electronic breadboard, you can leave pins unconnected.
[19:18:21] <jmk-mcfaul> that doesn't mean there isn't a voltage on those pins
[19:18:34] <jmk-mcfaul> output pins have voltages because they are driven by the component
[19:18:40] <mhaberler> oh I get the analogy, of course
[19:18:47] <mhaberler> the 'has a name' criterium doesnt hold water
[19:18:48] <jmk-mcfaul> input pins may have random voltages, but they still have voltages
[19:18:56] <mhaberler> sure
[19:18:59] <mhaberler> I buy all that
[19:19:31] <jmk-mcfaul> the dummy signal is just a mechanism to ensure that a pin can have a voltage even when disconnected
[19:19:32] -!- sumpfralle has quit [Quit: Leaving.]
[19:19:42] <mhaberler> (btw it is no wonder we are dscussing exactly that them when remotifying the whole thing)
[19:19:48] <mhaberler> yes, it could even be /dev/random
[19:20:03] <jmk-mcfaul> for input pins, yes
[19:20:25] <jmk-mcfaul> although it is convenient to be able to set a voltage on an input pin even though it doesn't have a connected signal
[19:20:32] <mhaberler> step back: both have a name, and a value (the latter might not make sense, i.e. noise)
[19:20:46] <jmk-mcfaul> that is only a convenience, we could be pedantic and make you put a signal there first
[19:20:52] <mhaberler> ah! a setsig behind the scenes
[19:20:59] <mhaberler> sure, makes sense
[19:21:29] <jmk-mcfaul> setp originally meant "set parameter", but at some point, it was extended
[19:21:45] <jmk-mcfaul> if no matching parameter is found, it searches for a matching pin
[19:21:46] <mhaberler> well the gist of this is: both have a name, and _some_ value, and hence could be subject to inclusion in a message
[19:21:58] <jmk-mcfaul> if found, and not connected, it sets the value (of the dummy storage)
[19:22:31] <mhaberler> that is implementation mechanics now, and for messaging we need to look at the observable behavior
[19:22:51] <jmk-mcfaul> agreed
[19:23:25] <mhaberler> all I am saying is: the decision is not as obvious to make as it looks at first
[19:23:48] <jmk-mcfaul> nothing about this is obvious to me, unfortunately
[19:24:18] <mhaberler> let me divert for a moment to a related use case, which is not part of that protocol but important; the question comes in there again
[19:24:48] <mhaberler> it is the case when you report HAL state to a non-HAL entitity, for instance motion status to task
[19:25:06] <mhaberler> there is no HAL namespace at the receiving end
[19:25:21] <jmk-mcfaul> task knows nothing about HAL (and shouldn't)
[19:25:21] <mhaberler> it will wind up in some task internal struct
[19:25:27] <mhaberler> yes, exactly
[19:25:41] <mhaberler> and it should remain that way. Now let me finish that case ;)
[19:26:13] <mhaberler> you can cover that with a HAL group and the HAL reporter nicely. The key question is: what are the group members?
[19:26:31] <mhaberler> signals or pins?
[19:26:35] <jmk-mcfaul> uh, what?
[19:26:39] <mhaberler> the view I took was
[19:26:45] <mhaberler> ok, rewind
[19:27:02] <jmk-mcfaul> "you can cover that" - what exactly is "that"? The HAL information that task isn't supposed to know about?
[19:27:10] <mhaberler> assume for a moment motion is rewritten as follows
[19:27:44] <jmk-mcfaul> today, motion decides what HAL things task needs to know about - based on the fixed functionality of task and motion
[19:27:50] <mhaberler> a) there is no EMC_MOT_STAT somehow funneled throw 2 shmem hoops into task; all that exists is motion has a bunch of pins
[19:28:19] <mhaberler> can I finish the scenario before you jump on it
[19:28:26] <jmk-mcfaul> lol, OK
[19:29:03] <mhaberler> if we remotify HAL+comps+motion, we need to consider how: a) commands go into motion b) status updates come out of motion
[19:29:09] <mhaberler> do you agree with this?
[19:29:42] <mhaberler> the reason why this needed: it makes no sense forcing interp and task into the realtime part
[19:29:44] <mhaberler> this is a bad strcuturing decision
[19:29:49] <jmk-mcfaul> wait a sec
[19:30:07] <jmk-mcfaul> I agree that interp and task don't belong in realtime
[19:30:27] <mhaberler> yes, and thats all the agreement we need to continuze
[19:30:29] <jmk-mcfaul> motion <--> task communication will have to go over the network, task remains on the non-RT side
[19:30:37] <mhaberler> yes
[19:30:43] <mhaberler> yes, yes and yes
[19:30:45] <mhaberler> ;)
[19:30:46] <jmk-mcfaul> but I fail to see how motion <--> task communication has anything at all to do with HAL
[19:31:09] <jmk-mcfaul> it is at a completely different layer of the overall architecture
[19:31:27] <mhaberler> that is a good question, the answer is nothing in the task->motion direction, and a lot in the other
[19:31:37] <jmk-mcfaul> why?
[19:32:47] <mhaberler> give a single good reason why motion reporting should not follow the update protocol we are talking about here
[19:32:59] <mhaberler> (other than task aint a HAL comp=
[19:33:04] <mhaberler> )
[19:33:22] <jmk-mcfaul> you mean the 11 rules you listed?
[19:33:22] <mhaberler> what I am suggesting is:
[19:33:26] -!- plushy has quit [Quit: Leaving.]
[19:34:04] <jmk-mcfaul> sure, motion <--> task should probably follow those 11 rules. But that doesn't make it HAL communication
[19:34:22] <jmk-mcfaul> email client <--> server comms should follow those rules too, but email isn't HAL
[19:34:24] <mhaberler> when we design the HAL messaging part, we *include* the view that *all* status reporting from RT goes through the same mechanism; I do not see any rational justification to have two different mechanisms here
[19:34:57] <mhaberler> one for HAL to HAL, and a different for HAL - to - task: why?
[19:35:17] <jmk-mcfaul> there is no hal to task
[19:35:22] <mhaberler> not now
[19:35:49] <jmk-mcfaul> motion + task is a thing - an application program. It happens to have HAL pins so that it can communicate low-level things to HAL
[19:36:11] <mhaberler> all I am saying is: if we have the HAL reporting proto in place, there will be no more reason left for a separate proto (NML or that shm special-purpose thing)
[19:36:15] <jmk-mcfaul> the motion<-->task comms are a private matter within that thing, not a part of HAL
[19:37:09] <jmk-mcfaul> poor use of the word thing on my part
[19:37:15] <mhaberler> what you call 'private' I call a duplication of effort (long term) including all disadvantages of early binding which I am hard pressed to find a justification for
[19:37:21] <jmk-mcfaul> I mean that task+motion is a distinct entity
[19:37:56] <mhaberler> exactly how distinct?
[19:38:06] <mhaberler> there is a command channel into motion, yes
[19:38:23] <mhaberler> (btw why is that a single purpose mechanism?)
[19:38:48] <jmk-mcfaul> right - a channel that cannot be mapped onto HAL - HAL deals very well with scalars, but not at all well with commands that consist of multiple values that must be passed as a group
[19:38:57] <mhaberler> the reporting of motion state is not anything different from the rest of HAL update messagig
[19:39:05] <mhaberler> stop here:
[19:39:06] <jmk-mcfaul> HAL does very well with scalars that are being updated at a constant rate, not with commands that are being passed intermittently
[19:39:24] <mhaberler> where did you get that from?
[19:39:37] <jmk-mcfaul> what?
[19:39:42] <mhaberler> you mean _into_ HAL=
[19:39:43] <mhaberler> ?
[19:40:05] <jmk-mcfaul> either way - but yes, mostly the motion commands going from task to motion
[19:40:05] <mhaberler> if you mean commands into a halcomp: I agree, there is no abstraction for that
[19:40:15] <jmk-mcfaul> they are intermittent
[19:40:37] <mhaberler> so?
[19:40:47] <mhaberler> you saw the HAL groups proposal
[19:41:06] <jmk-mcfaul> I clearly didn't see it the same way you see it
[19:41:14] <mhaberler> it explicitly allows for change detect on members, and report-on-change-detect
[19:41:15] <mhaberler> yes
[19:41:31] <jmk-mcfaul> IMO, the task --> motion comms should be a fifo, rather than shared memory
[19:42:02] <mhaberler> yes, it will, but thats out of scope for the messaging discussion because no HAL pins/sigs either end
[19:42:12] <mhaberler> very easy to remotify
[19:42:15] <jmk-mcfaul> right now, task can only place one command into shmem, then it has to sleep until motion extracts that command and puts it into an internal fifo (only once per mS), then task can wake up and put another command, etc
[19:42:29] <mhaberler> I have read this code a lot
[19:43:14] <mhaberler> I have worked with Pavel on the networked replacement already; again, its out of scope here IMO
[19:43:44] <jmk-mcfaul> the existing arrangment is bad, because task is a user space process,and would like to put lots of commands into the fifo in less than one mS,then sleep for a long time while motion extracts them
[19:43:46] -!- racycle has quit [Quit: racycle]
[19:44:04] <jmk-mcfaul> that is even farther away from the HAL approach to doing things, so why try to use HAL for that comm link>
[19:44:06] <jmk-mcfaul> ?
[19:44:45] -!- norbert has quit [Quit: Verlassend]
[19:45:11] <mhaberler> I have never proposed to use HAL in any way for the purpose of passing motion commands FROM TASK TO MOTION
[19:45:25] <jmk-mcfaul> so why use it the other way?
[19:46:08] <jmk-mcfaul> you need a dedicated link for task->motion. So why not make it bidirectional, and avoid the need for task to deal with HAL in any form at all?
[19:46:12] <mhaberler> because you can drop special-purpose code, and generalize it a form such that other comps could do likewise?
[19:46:41] <mhaberler> you seem to love this special purpose vehicles
[19:46:44] <mhaberler> I dont
[19:47:02] <jmk-mcfaul> I think the difference is how we view the com link
[19:47:09] <mhaberler> yes
[19:47:28] <jmk-mcfaul> you view task->motion and motion->task as two different things, so you don;t mind making ONE of them HAL
[19:47:50] <jmk-mcfaul> I view task <--> motion as a single bidirectional link, so it seems bizarre to make half of it HAL
[19:49:07] <mhaberler> let us be cautios with value judgements like 'bizarre' here, I would have some comments going 180 degrees against that; there is no point in doing that
[19:49:41] <mhaberler> let me run a few questions by you:
[19:49:48] <jmk-mcfaul> the value judgement is a function of how you see things. If you think of them as two separate links, then it isn't bizarre at all
[19:50:13] <mhaberler> I assume you agree HAL remote updating can transport a given set of scalars in an update message ?
[19:50:21] <jmk-mcfaul> yes
[19:50:36] <mhaberler> in an atomic fashion, since it is a message
[19:51:17] <jmk-mcfaul> yes, with caveats.
[19:51:53] <jmk-mcfaul> the message is atomic, but the code that reads the pins from RT shmem can be interrupted, so the collection of data that goes into the message might not be an atomic snapshot of HAL pins
[19:51:53] <mhaberler> 2) where is a motion status update different from a set of scalars sent as a message?
[19:52:15] <mhaberler> (other that 2) is a compiled straightjacket)
[19:52:39] <mhaberler> 3) where is the justification for having different vehicles for 1) and 2)
[19:52:53] <jmk-mcfaul> yes, motion status is a set of scalars sent as a message. Most of which initial inside motion and are never visible in HAL
[19:53:08] <jmk-mcfaul> s/initial/initiate
[19:53:30] <mhaberler> you seem to believe motion is somethng very very special
[19:53:32] <mhaberler> I dont
[19:53:47] <jmk-mcfaul> motion and task are partners
[19:53:53] <mhaberler> the only thing 'special' about is: it takes commands, and it is some huge blob
[19:53:53] <jmk-mcfaul> one without the other is meaningless
[19:54:57] <mhaberler> what you say about reads being interrupted is a deficit of the vehicle implementation, not a conceptual problem
[19:55:00] -!- snkashis has quit [Quit: Leaving.]
[19:55:41] <jmk-mcfaul> right - the existing task->motion link has to deal with that same problem
[19:55:47] <mhaberler> see
[19:56:04] <jmk-mcfaul> you are the one who mentioned that it would be atomic
[19:56:13] <jmk-mcfaul> ;-)
[19:56:39] <mhaberler> it _should_ be atomic, a message is, and I lack proper words for the 'synchronisation' in usrmotif.cc
[19:56:55] <mhaberler> they'd not be nice ;), so dont ask
[19:57:12] <jmk-mcfaul> I think the words are "crufty, but it works"
[19:57:22] <mhaberler> yes
[19:57:30] <mhaberler> that is common ground
[19:57:51] <mhaberler> but lets stand back for a sec, because this is important.
[19:58:39] <mhaberler> do you agree - despite gruftyness - that the current messaging between motion and task should be atomic in nature ?
[19:58:51] <mhaberler> (conceptually, that is)
[19:59:31] <jmk-mcfaul> since motion->task contains commands that must be received in their entirety or not at all, yes. I'm not so sure about motion->task
[19:59:51] <jmk-mcfaul> to be honest, I know almost nothing about task, and not so much about the higher level parts of motion
[20:00:00] <jmk-mcfaul> HAL and low-level motion are my thing
[20:00:43] <mhaberler> atomic in the context of messaging means: it is considered sent, or not sent; after it is sent it is not accessible anymore.
[20:01:08] <mhaberler> (for modification that is - it becomes a local struct in the recipient)
[20:01:09] <jmk-mcfaul> never heard that definition before
[20:02:29] <jmk-mcfaul> that sort of maps to my definition of atomic. The "entity that I see is either an old version, or a new version, but not some mix of old and new"
[20:05:52] -!- mhaberler has quit [Read error: Operation timed out]
[20:09:56] -!- Adventsparky has quit [Client Quit]
[20:10:24] -!- nOStahl has quit [Quit: nOStahl]
[20:25:27] -!- L84Supper has quit [Quit: <puff of smoke>]
[20:27:19] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc3
[20:29:22] <mhaberler> sorry - my ISP vanished
[20:29:32] <mhaberler> config night..
[20:29:32] <jmk-mcfaul> not very nice of them
[20:31:11] <jmk-mcfaul> I'm afraid this discussion has been rather frustrating on both sides
[20:31:28] <jmk-mcfaul> I'm not even sure how we got from HAL to motion <--> task stuff
[20:35:01] <jmk-mcfaul> vanished again?
[20:35:55] <mhaberler> jmk-mcfaul: still out?
[20:36:04] <jmk-mcfaul> I'm here
[20:36:24] <mhaberler> Ah!
[20:36:44] <mhaberler> I think he's done fiddling routers (or so I hope)
[20:37:08] <mhaberler> I didnt find it frustrating at all; it is very helpful to clarify concepts and harden ideas
[20:37:52] <mhaberler> how we got from hal to motion/task is my profound dislike for arbitrary special-purpose vehicles which can be abstracted and subsumed into a common mechanism
[20:38:05] <mhaberler> I acknowledge tastes vary here
[20:38:22] -!- holgi has quit [Quit: Bye]
[20:38:52] <mhaberler> ok, where were we.. atomicity of commands and responses.
[20:39:21] <jmk-mcfaul> I was wondering if we could go back to the 11 rules and talk about their implications
[20:39:31] <mhaberler> well the way I read the code that seems to be an assumption, and we hope it always holds
[20:39:32] <mhaberler> fine
[20:39:42] <mhaberler> it is a diversion, you are right
[20:40:06] <mhaberler> I was writing definitions to use the unplugged time ;)
[20:40:24] <jmk-mcfaul> I'm having trouble following the more abstract parts of the topic, so talking about concrete stuff might help
[20:40:32] <jmk-mcfaul> do you have things you want to paste?
[20:40:44] <mhaberler> ?
[20:40:52] <mhaberler> example?
[20:40:56] <jmk-mcfaul> you said you were writing definitions...
[20:41:01] <mhaberler> oh I see
[20:41:21] <jmk-mcfaul> rule #12 maybe :-)
[20:41:54] <jmk-mcfaul> anyway, rule #1 - I agree, and see no problems implied by it
[20:42:07] <mhaberler> A Peer is a local HAL namespace (as show by halcmd), associated with a
[20:42:07] <mhaberler> communications endpoint (eg a URI).
[20:42:09] <mhaberler> A Peer Instance is a Peer identified by a unique session id. At any
[20:42:10] <mhaberler> one time there is a single instance associated with a HAL namespace.
[20:42:11] <mhaberler> A Binding is an association of HAL objects, like pins or signals,
[20:42:12] <mhaberler> which are linked through a stream of value updates.
[20:42:14] <mhaberler> paging back..
[20:42:28] <mhaberler> ok, fine
[20:43:09] <jmk-mcfaul> #2 - again I agree in principle. It brings up some only loosely related topics that might help me understand
[20:43:16] <mhaberler> ok
[20:43:28] <mhaberler> (give example?)
[20:43:28] <jmk-mcfaul> there is some file or set of files that defines the machine config
[20:43:36] <jmk-mcfaul> on a single PC, we know where they are
[20:44:20] <jmk-mcfaul> on a multiple PC machine, where do they live? are they duplicated on both? does each have a subset that defines local stuff? or is there a mechanism to get the info from one PC to another?>
[20:44:22] -!- micges has quit [Quit: Leaving]
[20:44:26] <mhaberler> that has a bearing how a namespace is configured; it has no bearing on the protocol which takes the namespace as observed
[20:44:29] -!- motioncontrol has quit [Quit: Sto andando via]
[20:44:36] <mhaberler> you mean configs?
[20:44:40] <jmk-mcfaul> yes
[20:45:00] <jmk-mcfaul> I'm coming at this as if I was a user trying to understand how this system looks to me
[20:45:04] <mhaberler> ok
[20:45:32] <jmk-mcfaul> where do I edit config files, how do I do halcmd on the remote machine, etc
[20:45:55] <jmk-mcfaul> these are all very low level details, far from protocol definition
[20:46:01] <mhaberler> there is no change implied by any what I said
[20:46:21] <mhaberler> (that doesnt say this is bright, it only says : no change here)
[20:46:36] <jmk-mcfaul> there has to be some change
[20:47:01] <mhaberler> you asked 'where do i edit configs', not 'how do I change configs'
[20:47:22] <mhaberler> as for where: locally as ever
[20:47:39] <mhaberler> as for how: that depends a bit on the convergence of the discussion,
[20:47:40] <jmk-mcfaul> do I sit at the UI PC and edit files that live on that box? or do I ssh into the headless PC and edit files there>
[20:48:42] <mhaberler> I dont see why the way configuring HAL has anything to do with the view of the message exchange; that is out of scope
[20:48:55] <mhaberler> the only thing in scope are changes which afffect binding and updates
[20:49:06] <mhaberler> is that what you mean?
[20:49:37] <jmk-mcfaul> I guess I have a problem with the scope
[20:49:40] <mhaberler> I mean google cares less if you locally config a static ip, a dynamic ip, or are behind a firewall or not
[20:49:50] <mhaberler> we are talking about:
[20:50:08] <mhaberler> a) how peer instances above communicate
[20:50:17] <jmk-mcfaul> there are many issues to resolve before you can run a headless PC (well, actually you can do it today, just run everything on it and ssh -X)
[20:50:29] <mhaberler> b) how their exchanges should be reflect in a HAL namespace
[20:50:45] <jmk-mcfaul> but we are spending lots of time talking about only one small aspect of it, I'm trying to understand the big picture
[20:51:21] <mhaberler> you are taking a way too lowlevel view here - it is completely irrelevant how the configuration part works; we need to clarify the concepts with bindings, and updates
[20:51:45] <jmk-mcfaul> or maybe I'm taking a way too high level view
[20:51:54] <mhaberler> the only relevant part of config is: which parts of halcmd change to enable binding, and verify binding status
[20:52:09] <jmk-mcfaul> if the problem is "how to run LCNC on a headless computer", perhaps the answer is "ssh -X" and all this isn't needed?
[20:52:10] <mhaberler> (binding being the 'twist loose wires together' part of the job)
[20:52:42] <jmk-mcfaul> thats why I ask about other aspects of running headless, such as where the config files live
[20:52:48] <mhaberler> that wasnt the question, so that cant be the answer
[20:52:59] <mhaberler> the question was:
[20:53:38] <mhaberler> how do we remove the shared memory requirement for ALL parts of linuxcnc; and while at it, enable some other stuff, like syncing machines
[20:54:29] <jmk-mcfaul> that isn't want I thought the questions was
[20:54:39] <jmk-mcfaul> no wonder we are having trouble agreeing on the answers
[20:54:49] <mhaberler> probably yes,
[20:55:28] <mhaberler> have a look at support and platform issues as they appear on IRC,lists, wiki
[20:55:34] <mhaberler> where do they come from?
[20:56:05] <jmk-mcfaul> PCs that don't do realtime well
[20:56:53] <mhaberler> EXACTLY
[20:57:06] <mhaberler> the whole crowd tries to navigate a space of rather hard restrictions - does graphics card x work on RTAI, does Lucid fall out of support
[20:57:23] <mhaberler> why does this package still have bug X
[20:57:24] <mhaberler> why?
[20:58:03] <mhaberler> why dont we have an ipad or an android controlling linuxcnc?
[20:58:14] <mhaberler> because the shared memory restriction forces this
[20:58:29] <mhaberler> btw: this was not the NIST design - it crept in
[20:58:45] <jmk-mcfaul> right - NIST used NML, and the GUI could work over a network
[20:58:53] <mhaberler> I dont say it was premeditated, it just happend because nobody cared to cry wolf
[20:58:59] <mhaberler> exactly
[20:59:21] <mhaberler> the _design_ was fully networked. And where are we?
[20:59:24] <jmk-mcfaul> VCP came later, and broke the NIST design. NIST design was elegant, but unconfigurable. VCP is crude, but easy to make work (locally)
[20:59:30] <mhaberler> ah.
[20:59:53] <mhaberler> So why didnt you guys say: hey, this totally breaks the model - stop it now
[21:00:06] <jmk-mcfaul> because elegance is not the only criteria
[21:00:29] <jmk-mcfaul> when 99% of the user base is local, they matter too, and VCP does things they want, easily
[21:00:41] <mhaberler> the proper answer would have been: sorry, you will have to go that extra mile and make it networked, the downsides are way too large
[21:01:10] <jmk-mcfaul> we are going to have to agree to disagree there
[21:01:23] <jmk-mcfaul> I prefer a simple easy to use toolset
[21:01:30] <jmk-mcfaul> and VCP is exactly that
[21:02:37] <mhaberler> dont you see this whole thing is ready to fall of the cliff due to this absurd backwards orientation?
[21:02:51] <mhaberler> RTAI: going nowhere
[21:02:56] <mhaberler> lucid: going nowhere
[21:03:02] <jmk-mcfaul> I see the risk'
[21:03:09] <mhaberler> mixture of RT and UI: going nowhere
[21:03:16] <mhaberler> I mean: what else does it take?
[21:03:20] <jmk-mcfaul> I look at things differently (probably because I work in the industrial control world)
[21:03:35] <jmk-mcfaul> the problem isn't that things are going nowhere, it is that things keep changing
[21:04:03] <jmk-mcfaul> I work with customers who expect a product to last 20 years
[21:04:31] <jmk-mcfaul> I work for a company who has customers that are incredibly loyal BECAUSE we don't change our products every 5 years
[21:04:35] <mhaberler> that is a constant in life, no point bitching about that
[21:05:31] <mhaberler> well please face the facts: if this isnt fixed, and it werent for the Xenomai efforts - three years down the road you'd have to rummage the wastebins to find suitable hardware
[21:06:08] <jmk-mcfaul> so - PCs are changing, and the RT operating system that let us treat a PC as the worlds fastest microcontroller is fading
[21:06:31] <mhaberler> the line between the understandable wish for stability, and outright petrification of a code base is narrow, and one shouldnt have to many illusions on which side one actually is
[21:06:49] <jmk-mcfaul> oh, I know damn well I'm on the petrified side
[21:07:07] <mhaberler> I propose to fend off the RT part so it becomes a controlled risk
[21:07:23] <jmk-mcfaul> you mean split it off?
[21:07:26] <mhaberler> this is right now an uncontrolled risk - too many variables and dependencies
[21:07:50] <mhaberler> yes, behind messaging - as we are discussing here
[21:08:12] <mhaberler> if you can farm out the RT part, you gain complete freedom in the non-RT part
[21:08:15] <jmk-mcfaul> we are coming at it from different directions in many ways
[21:08:22] <jmk-mcfaul> to me, the RT part is the cool part
[21:08:23] <mhaberler> the foundations need fixing a bit
[21:08:31] <jmk-mcfaul> I can't get excited about UIs
[21:08:49] <jmk-mcfaul> I love the fact that HAL lets me treat a PC like a microcontroller and do cool RT stuff with it
[21:09:08] <jmk-mcfaul> I do worry that the evolution of the PC and Linux will break that
[21:09:14] <mhaberler> well yes, I agree, unfortunately there are these 'users', and the 80ies concept of a PC is fading real fast
[21:09:53] <mhaberler> the whole effort better unplugs from that 1:1 bindng onto the PC platform
[21:10:24] <jmk-mcfaul> so, the real problem is what will be use as a replacement RT platform
[21:10:29] <mhaberler> the PC evolutes into *pads and phones and microcontroller boards
[21:10:41] <mhaberler> the beige steel box is extinct
[21:10:49] <jmk-mcfaul> if the answer to that is "something that is headless", then (and only then) do we need remote UIs
[21:11:09] <mhaberler> well why do you think I have two beaglebones sitting 40cm from my keyboard?
[21:11:30] <mhaberler> and a raspberry to make sure which platform doesnt cut it
[21:12:01] <jmk-mcfaul> OK, so when you play HAL on your beagleboard, how are you running halcmd? is it running on the beagle, and you ssh to it?
[21:12:04] <mhaberler> no, we have to fix the foundations so UI's become remote, without having big bang day
[21:12:16] <mhaberler> right now: ssh into it, run halcmd
[21:13:10] <jmk-mcfaul> and later?
[21:13:24] <mhaberler> you mean down the road?
[21:13:27] <jmk-mcfaul> yes
[21:13:58] <jmk-mcfaul> I'm trying to figure out how this specific HAL messaging things ties into all the other things that you need to run LCNC
[21:14:01] <mhaberler> I think the only thing really worth considering re configuration is whether you rely on local files like halcmd or ini files
[21:14:12] <jmk-mcfaul> like where the ini files and hal files live, and how you tune (halscope), etc
[21:14:15] -!- nOStahl has quit [Ping timeout: 252 seconds]
[21:14:22] <mhaberler> redis would be a perfect replacement to take that out of say remote RT boards
[21:14:28] <mhaberler> exactly
[21:14:42] <mhaberler> lets do these in turn:
[21:14:47] <mhaberler> ini files:
[21:15:43] <mhaberler> inis are key/value stores with iterator. that matches 1:1 on redis data structures. what I am saying: it is ver easy to replace a local ini by a redis access, and avoid local inis
[21:16:15] <mhaberler> halcmd: needs though, but there is no reason to not keep those in redis either
[21:16:20] <mhaberler> why am I saying this?
[21:16:32] <jmk-mcfaul> google sez: Redis is an open source, BSD licensed, advanced key-value store.
[21:16:34] <mhaberler> because you could have a config-free RT outboard
[21:16:46] <jmk-mcfaul> how does a key-value store replace halcmd?
[21:17:01] <jmk-mcfaul> ok, that last statement really confuses me
[21:17:21] <mhaberler> I'd retain the language as is, and just replace the files by redis blobs
[21:17:41] <mhaberler> but thats really optional: you would do this if you want a plug-and-play outboard
[21:17:56] <mhaberler> which pulls _all_ configs remotely
[21:18:00] <mhaberler> btw:
[21:18:20] <mhaberler> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=tree;f=src/redis;h=3dbcc242b0a78573c1e53de90230ac1499dd8530;hb=7bef9f22940618fd3052694db878cfd206e46d1d
[21:18:45] <mhaberler> it is in master already, I just got diverted by the xenomai/rtapi effort
[21:19:14] <jmk-mcfaul> that doesn't mean anything to me (I'm not set up to do a git pull, or build, or anything else on this machine)
[21:19:42] <mhaberler> ok, what it means is: master has a redis server, and some code is starting to use it
[21:19:48] <jmk-mcfaul> your part about pulling configs remotely - now maybe at long last I'm starting to grasp what you are going at
[21:20:04] <mhaberler> great
[21:20:09] <jmk-mcfaul> the fact that redis is a mechanism behind it is totally irrelevant for my understanding
[21:20:10] <mhaberler> I know I assume much
[21:20:16] <mhaberler> exactly
[21:20:30] <jmk-mcfaul> it could be pixies getting the data from point A to point B
[21:20:39] <mhaberler> It just happened to fit the bill, and with blazing performance at it
[21:21:03] <jmk-mcfaul> the high level part that I haven't understood (probably because you assume I know already) is that your goal is to have the config on the UI box, and have the RT box pull it
[21:21:09] <jmk-mcfaul> (one of your goals anyway)
[21:21:28] <mhaberler> hm, thart I dont understand
[21:21:47] <mhaberler> RT and UI/task/interp must be able to startup and find each other
[21:22:01] <mhaberler> ah I see
[21:22:13] <jmk-mcfaul> you wrote a minute ago "you would do this if you want a plug-and-play outboard which pulls _all_ configs remotely"
[21:22:41] <mhaberler> well you'd keep the config on the most stable part, and the one which is most suitable
[21:22:55] <jmk-mcfaul> by "outboard" I think you mean "the box that does the RT stuff", whether it is a PC or a beagle or a rasberry or whatever
[21:23:02] <mhaberler> yes
[21:23:17] <mhaberler> in theory you could keep all config in the beaglebone flash filesystem, but I dont think thats the right place
[21:23:19] -!- bedah has quit [Quit: bye]
[21:23:42] <jmk-mcfaul> I think I agree
[21:23:43] <mhaberler> shoudl be at the command/control level, but doesnt have to be where the UI lives
[21:24:21] <mhaberler> at the end it boils down to passing a URI and say: please learn from <URI> what you are supposed to do
[21:24:56] <mhaberler> in the case of a beaglebone, which is my prototypical 'RT outboard', that could even come via DHCP
[21:25:06] <mhaberler> board broken, replace, run
[21:25:16] <mhaberler> no local configs
[21:25:25] <jmk-mcfaul> yes
[21:25:32] <jmk-mcfaul> it becomes a "HAL engine"
[21:25:35] <mhaberler> Peter Wallace doesnt do it either, and for good reasons
[21:25:38] <mhaberler> exactly
[21:25:57] <mhaberler> that sums it up what I'm about
[21:26:41] <jmk-mcfaul> so perhaps the real question becomes "what problems need to be solved to give us a HAL engine?"
[21:27:16] <jmk-mcfaul> whether that engine is one core of the PC, or an outboard beagle is irrelevant if it is architected right
[21:27:21] <mhaberler> the conceptual issues we talked about here, really
[21:27:32] <mhaberler> exactly
[21:27:54] -!- psha has quit [Quit: Lost terminal]
[21:27:58] <jmk-mcfaul> I guess I don't deal well with high level concepts
[21:28:09] <jmk-mcfaul> the issues I want to understand are mechanics
[21:29:03] <jmk-mcfaul> for example, if I want to play with this hal engine interactively, how do I do it? do I run halcmd by ssh, or do I use something on the UI side that replaces halcmd, such that the activity happens in the RT engine
[21:29:11] <mhaberler> well I must say boiling all this high level fluff into something working and understandable I find an interesting challenge
[21:29:23] <mhaberler> I just refuse to do more 'ad-hack'
[21:29:42] <jmk-mcfaul> I guess I'm saying "how should it look to the user", then let the design follow from that
[21:29:51] <mhaberler> well, I just talked to Ken about that today
[21:30:06] <mhaberler> the reason was because it was about encoding
[21:30:18] <mhaberler> you mean the API user?
[21:30:39] <mhaberler> because the HAL engine needs an API (a messaging api..)
[21:31:06] <mhaberler> want me to run you through a Python and an interactive example ?
[21:31:17] <jmk-mcfaul> no, the guy sitting at his keyboard configuring LinuxCNC (or using HAL an VCP and halscope to make a robot work, or generate 50mS long pulses for some test)
[21:31:36] <mhaberler> I would think the impact there is limited
[21:31:54] <mhaberler> what she'd likely see is a bunch of URI's in the ini which glues things together
[21:32:23] <mhaberler> I have no intent to touch halcmd for instance, except as talked through here
[21:32:40] <jmk-mcfaul> today I can sit down and type "halrun -I", and I get a halcmd prompt
[21:32:41] <mhaberler> (as impacted by messaging)
[21:32:49] <mhaberler> you will retain that
[21:33:07] <mhaberler> however, you get a remote api on top which looks like so:
[21:33:18] <jmk-mcfaul> in the brave new world, I would do something like "halcmd <URI-of-hal-engine> -I and get the same prompt?
[21:34:00] <mhaberler> a zmq socket to talk to say motion (well only game in town now), and the plumbing to encode a message *all the way from an editor editable format to binary* (NB we dont have that with NML)
[21:34:25] <mhaberler> and a zmq subscriber which gets a stream of value updates
[21:34:43] <mhaberler> that would be the future api task uses to talk to that puppy remotely
[21:34:53] <jmk-mcfaul> this is still all API stuff, not user stuff
[21:35:24] <mhaberler> well yes, we fix the infrastrucure first to decoupe RT from nonRT
[21:35:41] <mhaberler> and wham, you are free to run the UI wherevery you want
[21:35:48] <mhaberler> if that is gladevcp/axis: fine
[21:36:01] <mhaberler> but you arent limited to it
[21:36:09] <jmk-mcfaul> nowhere is it written that you even need a UI
[21:36:16] <mhaberler> you can do zmq/protobufs messages perfectly fine on an Android
[21:36:29] <mhaberler> well sure it is optional
[21:36:53] <jmk-mcfaul> I keep coming back to "what will it look like to a user"
[21:36:58] <mhaberler> actually the purpose of a Python API is to enable scripting of nonUI apps too
[21:37:21] <jmk-mcfaul> I sit down at my ipad or android or laptop and type "halcmd <URI-of-hal-engine> -I
[21:37:22] <mhaberler> Linuxcnc: unchanged
[21:37:23] <mhaberler> APIs: internally changed
[21:37:29] <jmk-mcfaul> then I type "loadrt some stuff"
[21:37:32] <jmk-mcfaul> addf some stuff
[21:37:34] <jmk-mcfaul> net some stuff
[21:37:34] <mhaberler> NML: wiped - all 36k locs of it
[21:37:52] <mhaberler> you ssh into the RT outboard
[21:37:55] <jmk-mcfaul> all this results in things being connected in a memory space on the RT engine
[21:38:19] <jmk-mcfaul> ok, so the halcmd is not running on the android or whatever, it is running on the engine
[21:38:22] <mhaberler> NB: I can ssh into the beaglebone from an ipad just fine
[21:38:27] <mhaberler> sure
[21:38:44] <mhaberler> phones make lousy outboards; nothing to plug into
[21:38:49] <jmk-mcfaul> ok, so now I'm running halcmd on the engine, from my ipad
[21:38:55] <mhaberler> yes
[21:39:05] <jmk-mcfaul> I can type commands if I want to (halcmd -I)
[21:39:10] <mhaberler> yes
[21:39:29] <mhaberler> the shell interface remains if you want that (not sure if you call that a UI)
[21:39:40] <mhaberler> for Joe Chipcutter, that is
[21:39:42] <jmk-mcfaul> if I want to use a hal file instead, how does it get from the ipad (where I was editing it) to the instance of halcmd on the RT engine
[21:39:44] <mhaberler> rather integrator
[21:40:24] <mhaberler> are we talking a finished application and fixing something in it?
[21:40:35] <jmk-mcfaul> yes, no, maybe :-)
[21:40:37] <mhaberler> or do you want to edit a halcmd file
[21:40:42] <mhaberler> ah I see, in that order
[21:40:48] <jmk-mcfaul> lol
[21:40:50] <mhaberler> now assume the most complex case
[21:40:56] <jmk-mcfaul> I see HAL as a sequence of levels
[21:41:04] <mhaberler> redis keeps inis and halcmd blobs
[21:41:33] <mhaberler> now these come from somewhere. the way I would do it to start with is to load these into redis once
[21:41:37] <jmk-mcfaul> simplest - manual entry of hal commands from halcmd, building a system (and quite possibly operating it - I've built a pulse generator and operated it by doing "sets width 0.01", "sets trigger 1"
[21:41:57] <jmk-mcfaul> next level, you build the system (or part of it) by executing a hal script
[21:42:08] <mhaberler> I would think ssh is the best ui for that for quite a while
[21:42:09] <jmk-mcfaul> just saves retyping a lot of shit
[21:42:35] <mhaberler> so you mean where does the halcmd save go?
[21:43:00] <jmk-mcfaul> next level, you build the system by executing a hal script, and one of the last things loaded is a program that provides a more sophisticated UI such as VCP or axis
[21:43:04] <mhaberler> why not back into its redis blob? btw once it is in redis it is trivial to edit it from a web app
[21:43:25] <jmk-mcfaul> wait, I think we are confusing things
[21:43:29] <mhaberler> that isnt going to happen in the RT outboard
[21:43:38] <jmk-mcfaul> I haven't mentioned hal save at all
[21:43:50] <mhaberler> I'm trying to figure
[21:43:57] <mhaberler> anyway: re UI
[21:44:56] <jmk-mcfaul> I don't understand this redis blob. Are you using it to replace a HAL file, or does it represent the actual live state of the HAL system
[21:44:59] <mhaberler> in the future, you will not load a UI like gladevcp in the RT ourboard halcmd file. You will likely load the HAL messaging peer component
[21:45:22] <mhaberler> forget redis, this isnt relevant here, we are talking UI startup
[21:45:28] <jmk-mcfaul> ok
[21:45:43] <mhaberler> assume the following:
[21:46:04] <mhaberler> you talk to haldcmd from ipad via ssh
[21:46:31] <mhaberler> you have some supercool ipad app called gladevcp-on-steroids
[21:46:47] <mhaberler> you start the HAL messaging peer client in halcmd
[21:47:22] <mhaberler> you start your supercool ipad UI (having given her a URI how to find its peer)
[21:47:24] <mhaberler> bang, UI on ipad
[21:47:28] <mhaberler> this is _not_ loaded in halcmd
[21:47:33] <mhaberler> thats the whole point
[21:48:17] <mhaberler> because that contradicts the 'we will break the shared memory limitation' plan to start with
[21:49:13] <mhaberler> Joe Chipcutter need not talk ssh to RT outboard
[21:49:31] <mhaberler> he glues ipad to lathe, configures wifi, HAL URI, done
[21:49:43] <mhaberler> see what I mean?
[21:49:53] <jmk-mcfaul> I follow parts of it.
[21:50:09] <jmk-mcfaul> joe chipcutter still uses halcmd under the hood
[21:50:29] <jmk-mcfaul> something must set up his PID blocks, etc, on the RT engine, and load the messaging peer client
[21:50:30] <mhaberler> yes, and there must be a store for these blos
[21:50:47] <mhaberler> blobs - a filesystem, or redis
[21:51:03] <mhaberler> So Joe is an integrator
[21:51:10] <jmk-mcfaul> so the halcmd running on ssh alone isn't enough
[21:51:19] <jmk-mcfaul> it works if I type the hal commands into the ssh tunnel
[21:51:31] <jmk-mcfaul> but if I want the hal commands to come from a file on the ipad, we need something else
[21:51:33] <mhaberler> is Joe an operator or an integrator?
[21:51:42] <jmk-mcfaul> yes
[21:51:50] <jmk-mcfaul> meaning, I want to talk about both cases
[21:51:52] <mhaberler> that is not a valid answer
[21:51:59] <mhaberler> ok
[21:52:20] <jmk-mcfaul> operator invokes something (taps an icon probably) on the ipad, and everything starts by magic
[21:52:30] <jmk-mcfaul> but we must understand the magic
[21:52:52] <jmk-mcfaul> integrator must understand where the config files live and how to modify them, even if he doesn't undersand all the magic
[21:53:01] <mhaberler> if Joe feels like integrating, he connects with ssh, fiddles the halcmd file, saves it (to filesystem or redis), and continues
[21:53:20] <jmk-mcfaul> ok, so the halcmd file _does_ live on the RT engine? I thought you didn't want that
[21:53:38] <mhaberler> could you drop your fad for files for a minute?
[21:53:49] <mhaberler> what is important is:
[21:54:04] <jmk-mcfaul> hey - I write hal scripts with a text editor dammit ;-)
[21:54:17] <mhaberler> a) they exist somewhere, have a name, and an access method
[21:54:41] <mhaberler> b) halcmd will know how to get at them, like loading or storing one
[21:55:12] <mhaberler> that could be a file, or a blob somewhere which is better edited over a web ui instead of breaking fingers with ssh
[21:55:44] <mhaberler> but in the most simple case (RT outboard aint plug and play) it will be on the local flash filesystem
[21:55:45] <jmk-mcfaul> well, until a minute ago I thought it was stored on the ipad.
[21:55:48] <mhaberler> and your editor too
[21:55:55] <mhaberler> no I NEVER said that
[21:56:23] <mhaberler> I said: the supercool gladevcp-on-steroids runs there, and it needs a UR
[21:56:25] <mhaberler> URI
[21:56:41] <mhaberler> I did not say the ipad stores any files for RT
[21:57:08] <jmk-mcfaul> a while back you said "you would do this if you want a plug-and-play outboard
[21:57:09] <jmk-mcfaul> which pulls _all_ configs remotely"
[21:57:33] <jmk-mcfaul> I misinterpreted "pulls" as "configs are stored on ipad (or whatever) and pulled to the RT engine
[21:57:39] <mhaberler> yes but I did not say 'remotely equals ipad'
[21:57:55] <mhaberler> there must be storage somewhere, yes
[21:57:59] <jmk-mcfaul> well, we have only the ipad and the engine, unless there is a third piece you haven't mentioned
[21:58:46] <jmk-mcfaul> anyway, I misunderstood. No big deal
[21:58:47] <mhaberler> well if its only the two, I would use the RT flash filesystem for halcmd stuff, and on the ipad I'd really only have the URI; maybe some UI descrtipion
[21:59:41] <jmk-mcfaul> so when you want to start it from an icon (joe chipcutter), that icon would follow the URI and tell the engine "use locally stored hal config <foo>"
[22:00:04] <mhaberler> thats a good point; likely answer: yes
[22:00:24] <jmk-mcfaul> seems like it could also follow the URI to the engine and say "here, use this hal config" (that originally was stored on the ipad for easier editing)
[22:00:27] <mhaberler> assuming 'UI' also implies task, interp etc
[22:00:43] <mhaberler> that is possible if optional, yes
[22:00:49] <mhaberler> actually a good idea
[22:00:53] <mhaberler> I like it
[22:01:32] <jmk-mcfaul> yes, the icon would invoke a script (as today) which loads RT and UI parts, the only difference is that the RT part of the script tells a remote engine what to do, instead of initializing and configuring a local engine
[22:01:40] <mhaberler> yes
[22:05:11] -!- DJ9DJ has quit [Quit: bye]
[22:08:07] <jmk-mcfaul> I"m back
[22:08:16] <mhaberler> ok
[22:08:47] <jmk-mcfaul> if the hal config is stored on the rt engine, then today's halcmd would do the job
[22:08:53] <mhaberler> yes
[22:09:09] <mhaberler> everything else is icing on the cake if you really need it
[22:09:13] <mhaberler> not sure you do
[22:09:29] <jmk-mcfaul> well, it would be nice to have the config stored on the ipad
[22:09:45] <mhaberler> 'everything' meaning 'replicate halcmd to work some other way'
[22:09:53] <jmk-mcfaul> you mentioned earlier that you don't like config in the engine, I agree, it lets you replace the engine with another generic one
[22:10:19] <mhaberler> it has to be somewhere, and it better be one place; which suggests the HAL URI idea is a good one
[22:10:27] -!- nOStahl has quit [Quit: nOStahl]
[22:10:29] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[22:10:53] <jmk-mcfaul> in a much wilder dream, the engine doesn't even need to run linux at all
[22:10:59] <mhaberler> no+
[22:11:04] <mhaberler> why?
[22:11:27] <jmk-mcfaul> all it needs is to be able to accept and execute hal commands to build a RT system
[22:11:33] <mhaberler> yes
[22:11:46] <mhaberler> some blob access needed like comps
[22:12:09] <mhaberler> but if that is a local file, or say a http URI is a detail
[22:12:09] <jmk-mcfaul> if the comps are cross-compiled on a linux system, the binaries could be sent down as part of the loadrt command
[22:12:21] <jmk-mcfaul> "load this binary as a component"
[22:12:33] <mhaberler> "load this webpage"
[22:12:39] <mhaberler> difference?
[22:13:04] <jmk-mcfaul> push vs pull? I guess my mind works the one way, but I can see the other as well
[22:13:36] <jmk-mcfaul> the latter would require more intelligence at the engine
[22:13:54] <mhaberler> as needed; I would think post getting the 'eat this config' command its mostly pull
[22:14:20] <jmk-mcfaul> "here is a binary blob compiled for ARM, load it" requires less intellitence to interpret than "here is a URI on the interweb, go find it and load what you find"
[22:14:37] <mhaberler> sure?
[22:14:50] <mhaberler> it is '-lcurl' in the makefile
[22:15:10] <mhaberler> the rest is naming _in the URI_
[22:15:20] <jmk-mcfaul> you totally lost me
[22:15:24] <mhaberler> not different from german vs english websites
[22:15:25] -!- zzolo has quit [Quit: zzolo]
[22:15:26] <jmk-mcfaul> (googling lcurl)
[22:15:39] <mhaberler> a URL handling library
[22:15:47] <mhaberler> doesnt matter
[22:15:51] <jmk-mcfaul> assume that the RT engine is an 8051 :-)
[22:16:10] <mhaberler> what you are talking about is the static config naming (build constants really)
[22:16:45] <mhaberler> male that a directory on the webserver: http:://hal.com/8051/abs.so
[22:16:56] <mhaberler> (with SSL please;)
[22:17:11] <jmk-mcfaul> that means the 8051 needs to understand what "http" means
[22:17:22] <mhaberler> but we're going astray
[22:17:25] <mhaberler> well thats what that library provides
[22:17:27] <jmk-mcfaul> sorry, this is a huge diversion
[22:17:42] <mhaberler> sometimes that is a good thing
[22:17:57] <mhaberler> it's been quite an exchange tonight
[22:18:46] <jmk-mcfaul> what we are talking about is an RT engine (which might be on a completely different piece of hardware, or might be on the local PC)
[22:18:53] <mhaberler> yes
[22:19:04] <jmk-mcfaul> we send it a series of hal commands to build a system
[22:19:04] <mhaberler> and a way to talk to it
[22:19:15] <mhaberler> yes
[22:19:45] <jmk-mcfaul> again, either ssh and typing, or tell it to fetch from local storage, or send from the UI box storage
[22:19:54] <mhaberler> yes
[22:20:13] <jmk-mcfaul> once built, we still need messaging to let UI components see what is going on, and control it
[22:20:19] <mhaberler> yes
[22:20:36] <jmk-mcfaul> (and for this I still like the datapipe concept), but that is a discussion for later
[22:20:43] <mhaberler> yes
[22:20:57] <mhaberler> I think we violently agree ;)
[22:21:31] <mhaberler> the bigger picture is spot-on
[22:21:37] <jmk-mcfaul> in the specific case of LCNC, motion is one of the comps in the engine
[22:21:50] <mhaberler> yes
[22:22:03] <mhaberler> other applications, probably other comps
[22:22:03] <jmk-mcfaul> we need a command based task->motion link (I'm assuming task is on the "ipad")
[22:22:10] <mhaberler> amen
[22:22:16] <mhaberler> yes and yes
[22:22:26] <mhaberler> thats what I've been working with Pavel
[22:23:03] <mhaberler> how that link will plug into motion, or others
[22:23:12] <jmk-mcfaul> and we need a motion -> task link, which might be hal based, if I everything currently moving from motion -> task is suitable (scalars rather than commands, for example)
[22:23:40] <mhaberler> I am trying to convince you to consider that route, yes
[22:24:04] <jmk-mcfaul> I am trying to open my mind to it
[22:24:13] <mhaberler> _messages made out of scalars_, not _scalars_
[22:24:20] <mhaberler> messages are atomic
[22:24:23] <jmk-mcfaul> the assymetry bothers me though - HAL for motion->task, pavel messaging for task->motion
[22:24:31] <mhaberler> isolated scalar updates arent
[22:24:52] <mhaberler> theres a dataype mismatch
[22:25:21] <jmk-mcfaul> if motion is sending the message, yes, but if the message contains values from arbitrary HAL pins, they might be updated by a faster thread while the message is being assembled
[22:25:24] <mhaberler> it wouldnt be a good idea, and not needed IMO, to force task->motion data into the HAL model (why?)
[22:25:29] <jmk-mcfaul> nitpicking, and irrelevant I think
[22:25:49] <mhaberler> and how is that different from the current situation?
[22:26:17] <jmk-mcfaul> it isn't - you are the one who made the distinction about messages being atomic ;-)
[22:26:42] <jmk-mcfaul> I agree that HAL is a horrible model for task->motion comms
[22:26:47] <mhaberler> we'll be able to resolve that
[22:27:19] <jmk-mcfaul> I just don't like the assymetry on esthetic grounds. why not pavel messaging both ways?
[22:27:32] <mhaberler> look - everything where it fits best. HAL is perfect to construct ad-hoc messaging with scalars out of HAL elswehere
[22:27:44] <mhaberler> it is lousy to do commands in
[22:28:30] <mhaberler> strike out the 'elswhere', made no sense
[22:28:50] <jmk-mcfaul> what about scalars into HAL?
[22:29:05] <jmk-mcfaul> for example, a VCP panel might have a button that says "spindle drawbar unclamp"
[22:29:09] <mhaberler> that isnt a problem to start with
[22:29:39] <jmk-mcfaul> when pressed, it goes down to HAL and activates a hardware output (or even a whole sequence of stuff, via classicladder)
[22:29:41] <mhaberler> I'm happy to give you the rundown, but ramming that through the HAL type system doesnt buy you anything afaict
[22:30:02] <mhaberler> NB: what goes in and out is messages with scalars
[22:30:30] <mhaberler> one might be tagged 'I am a HAL scalar' when it comes out
[22:30:33] <jmk-mcfaul> damn I wish I could draw a picture to make sure I understand you
[22:30:41] <mhaberler> but 3.14 is still 3.14
[22:30:50] <jmk-mcfaul> I think we have this: task -> motion is by pavel messaging
[22:30:55] <mhaberler> yes
[22:31:04] <jmk-mcfaul> vcp -> rt engine hal is by hal messaging
[22:31:10] <mhaberler> yes
[22:31:15] <jmk-mcfaul> rt engine hal -> vcp ditto
[22:31:22] <mhaberler> yes
[22:31:36] <jmk-mcfaul> and motion -> task is the same
[22:32:16] <mhaberler> you're bothering too much about that 'HAL' word in the message, Pi doesn look and feel any different if its a float or a HAL float
[22:32:55] <jmk-mcfaul> to me hal messaging means "at the rt engine end, the scalar appears on a hal pin"
[22:33:12] <mhaberler> that is really funny: I'm trying to unify a few concepts here which havent been touched in years, and bang, I'm driven over on cenceptual grounds;)
[22:33:30] <mhaberler> yes, before the are assembled into a message
[22:33:51] <jmk-mcfaul> or after they are disassembled, in the case of VCP -> rt engine
[22:34:01] <mhaberler> right
[22:34:23] <jmk-mcfaul> for motion->task status...
[22:34:25] <mhaberler> HAL scalars are just a subset of the possible message contents type universe
[22:34:56] <jmk-mcfaul> would the values from motion become HAL pins, then go into the messaging component? or would they be invisible to HAL at the rt engine end?
[22:35:09] <mhaberler> exactly
[22:35:18] -!- wildbilldonovan has quit [Quit: EOT]
[22:35:19] <mhaberler> they become HAL namespace
[22:35:26] <jmk-mcfaul> exactly which?
[22:35:29] <jmk-mcfaul> the latter then?
[22:35:37] <mhaberler> the former
[22:35:42] <jmk-mcfaul> seems like that will make a messy hal namespace
[22:35:47] <mhaberler> all mutated into hal pins
[22:35:56] <jmk-mcfaul> aren't there hundreds of status values?
[22:36:03] <mhaberler> that poor memory in that poor computer
[22:36:30] <mhaberler> yes, that is an issue.
[22:36:34] <jmk-mcfaul> not worried about that, I'm worried about the human attempting to read through halcmd show pin for the stuff he really cares about
[22:37:00] <mhaberler> the standard way to deal with namespace bloat is subnamespaces. That is always possible but not needed conceptually
[22:37:32] <mhaberler> let me pull an analogy
[22:37:43] <mhaberler> you compile a program and run it
[22:38:16] <mhaberler> how many names did you spell out, and what does 'nm <mybinary>' say?
[22:38:30] <mhaberler> now what does that say against the concept of libraries?
[22:38:46] <mhaberler> well nothing, you look at different namespaces in the source and in 'nm'
[22:38:59] <jmk-mcfaul> humans (even programmers) don't often need nm
[22:39:12] <jmk-mcfaul> I had to do man nm to find out what it was, I've never used it
[22:39:20] <jmk-mcfaul> halcmd show is a common tool
[22:39:24] <mhaberler> then we will find a way to deal with that issue which doesnt break the conceptual model
[22:39:47] <mhaberler> for instance, a default scope of visibility helps
[22:40:00] <jmk-mcfaul> the hal messaging component - is it neccessary that it be a singleton?
[22:40:09] <mhaberler> like (motion has 527 pins, to view them all do X)
[22:40:15] <mhaberler> no
[22:40:27] <mhaberler> the message is atomic, not the comp
[22:40:59] <mhaberler> any number of groups dealt with by any number of comps as makes sense
[22:41:05] <jmk-mcfaul> hiding the pins from show is only part of the problem.
[22:41:25] <mhaberler> you are rearranging deckchairs
[22:41:32] <jmk-mcfaul> there is also the task of connecting them all in the first place (unless that is the auto-linking that you have talked about, and I didn't understand without a larger context)
[22:41:46] <jmk-mcfaul> anyway, the reason I asked about singleton
[22:42:14] <mhaberler> thats going to be library halcmd files, like motion.hal deals with those
[22:42:59] <mhaberler> motion.hal will be the replacement definition of emc_mot_stat contents
[22:43:19] <mhaberler> the corresponding HAL group will make that into an update message
[22:43:24] <jmk-mcfaul> so motion.hal would loadrt motion, and an instance of the messanger, and it would interconnect all those pins
[22:43:58] <mhaberler> it could do its own messenger, or not; thats really a performance question vs isolation
[22:44:21] <mhaberler> note the current reporter doesnt have a clue _what_ it is reporting - on purpose
[22:44:41] <jmk-mcfaul> I like the idea of the user being able to have his own messenger for the few pins he wants, just to simplify his live
[22:44:48] <jmk-mcfaul> but as you say, these are details
[22:45:00] <jmk-mcfaul> I think I have a better idea of the big picture
[22:45:18] <jmk-mcfaul> there are other big picture details we haven't discussed: classicladder and halscope for two
[22:45:18] <mhaberler> whether you isolate at group or reporter level is a detail, yes
[22:45:55] <jmk-mcfaul> the ladder engine must reside on the RT box, the ladder program (at least in some "compiled" form) must reside there too
[22:45:59] <mhaberler> in fact its possible now, the reporter comp name is configurable; it just happens to report all groups it sees which is a bit dumb
[22:46:05] <jmk-mcfaul> the GUI that lets you view and edit the ladder is on the ipad
[22:46:10] <mhaberler> I thought so, yes
[22:46:21] <mhaberler> need to look more closely at ladder
[22:46:46] -!- nOStahl has quit [Quit: nOStahl]
[22:47:08] <jmk-mcfaul> and with halscope, the part that captures data in realtime must of course be on the engine, then the entire captured buffer (64K I think) must be sent up to the GUI for display
[22:47:22] <mhaberler> halscope:aj.
[22:47:23] <mhaberler> ah
[22:47:25] <mhaberler> thats going to be reverse Pavel messaging.
[22:47:27] <mhaberler> been there.
[22:47:33] <jmk-mcfaul> hopefully pavel';s work is general enough to do that
[22:47:34] <jmk-mcfaul> yes
[22:48:08] <mhaberler> it is actually just 100 lines or so, but supersharp
[22:48:41] <jmk-mcfaul> so classicladder and halscope will also have to evolve to use URIs to find their "other half:
[22:48:48] <mhaberler> yes
[22:49:19] <mhaberler> the compiled-in binding between rt and userland will go away and be replaced by a uri
[22:49:27] <mhaberler> which covers local and remote
[22:49:48] <jmk-mcfaul> and in the process allows for multiple HALs on one computer - bonus
[22:49:50] <mhaberler> NB: all this can be done incrementally
[22:50:00] <mhaberler> (uhum..)
[22:50:33] <mhaberler> first time I asked you about HAL instances, you said: WTF! now you're all gung-ho about it ;)
[22:50:47] <jmk-mcfaul> are you sure?
[22:51:01] <mhaberler> I wil pull out that mail, just for a laugh
[22:51:12] <jmk-mcfaul> I don't think I was ever really opposed to the concept, just aware that it would be difficult to implement in the existing environment
[22:51:25] <mhaberler> its not relevant
[22:51:41] <jmk-mcfaul> when I was first talking about the datapipe, I started seeing it as a way to do encapsulation
[22:52:11] <mhaberler> oh, I fully understand - it is the way to do it given the current model
[22:52:25] <jmk-mcfaul> have a HAL instance, with a huge mess of comps and signals and what all in there. Then define a data pipe that brings only certain signals out - presto - HAL mega-component!
[22:53:16] <mhaberler> (mhaberler tries to figure who will do the 'presto' part of the last sentence ;)
[22:53:26] <jmk-mcfaul> I like the datapipe for that specifically because the two namespaces are isolated
[22:53:54] <jmk-mcfaul> well, if we have independent hal instances (aka RT engines), then creating a mega-component is just a hal file
[22:54:36] <jmk-mcfaul> so the person who wants a custom component is the one who would do it
[22:54:41] <mhaberler> the difference between my and your concept is: your way of 'isolation' forces a renaming when doing local vs remote; thats all
[22:55:02] <jmk-mcfaul> yes - and depending on your goal that is either a feature or a bug
[22:55:12] <jmk-mcfaul> for megacomponents, you want the namespaces to be isolated
[22:55:12] <mhaberler> my idea would be to come up with a more flexible way of joining namespaces, but I think we're running out of steam for today
[22:55:24] <jmk-mcfaul> yes
[22:55:43] <mhaberler> whew, that was quite a session
[22:55:54] <jmk-mcfaul> indeed
[22:56:53] <jmk-mcfaul> I understand much better when thinking from the users point of view. How do I do <x>, what do I type, and where? Then figure out implementation from that
[22:56:59] <mhaberler> I think in the minimum we have made good progress towards an overall picture, a vision if you will, and where the messaging parts fit int o those; thats quite something
[22:57:18] <jmk-mcfaul> agreed
[22:57:37] <mhaberler> shall we leave it at that for the day?
[22:57:39] <jmk-mcfaul> yuck - just looked out the window, it is snowing
[22:57:44] <jmk-mcfaul> yes :-)
[22:57:56] <mhaberler> I looked out the window, and it is pitch black
[22:58:10] <jmk-mcfaul> midnight there? or later?
[22:58:13] <jmk-mcfaul> 6pm here
[22:58:19] <mhaberler> yes, midnight
[22:58:28] <jmk-mcfaul> go to sleep!
[22:58:41] <mhaberler> anyway - have a good one; I really appreciated it
[22:58:59] <jmk-mcfaul> thanks, you do the same.
[23:10:22] -!- jmk-mcfaul has quit [Quit: Ex-Chat]
[23:17:15] -!- mhaberler has quit [Quit: mhaberler]
[23:22:04] cevad is now known as davec
[23:35:28] -!- heyapple has quit [Ping timeout: 245 seconds]