Michael, Not sure where to start or finish here. It will be interesting to see how HAL and Thread interact to deal with critical regions I can see it working. The question is how elegantly we can get this to work. I think it might be as simple as a semaphore (stretched between two user defined G codes -- g91/g92...)
Now I need to get back to work... I hope this all works out. EBo -- On Mon, 10 Sep 2012 07:25:53 +0200, Michael Haberler wrote: > > Ebo, > >> Michael, >> >> I agree. I wanted to add one thing to your modular abstraction that >> I >> hope will help. > > it's good to hear the idea isnt considered totally outlandish > >> >> Instead of thinking about separate machines, maybe we can think >> about >> named groups of actuators and sensors operating together. > > This would definitely be needed, yes > > Terminology: how do we name that? A good short term would be great. > (I'll use 'beast' for the rest of this message to encourage finding > of > a better term;) > > IMO it encompasses: a HAL+threads instance with a messaging interface > (in the CNC context: with some mechanical entity attached to it) > > Currently there is no name for it, and since it's a singleton now and > implicit, no data structure exists to support a reference to it. > > >> You could >> separate a spindle from an XYZA table if you do not threading. On >> the >> other hand, if you have a pick and place robot feeding a couple of >> routers, then each machine has a group of XYZ's (which may or may >> not) >> be driven by separate controllers, but are always handled by >> separate >> process threads. This way a router with a dual gantry could be >> abstracted to run independently, but with the added >> process/thread/group >> message communication. > > right, this would amount to sending different message streams to > different beasts, in an unsynchronized manner; just fire off some > rs274ngc scripts in different instances. > >> >> Brainstorming on controlling a 6 head tool screw machine (like in >> the >> video someone posted recently). Each axis/tool has a dependency >> graph. >> As soon as all depend operations are completed I can insert the new >> one >> in the queue. Now check against the different tools crashing >> against >> each other you can have them move basically independently if they do >> not >> overlap either spatially or temporally. > > syncing multiple beasts came up repeatedly > > I think any primitive supporting this must be at the beast level, as > the rs274ngc level is too macroscopic - a word may be decomposed into > many messages. > > --- > > Note that there is *some* implicit synchronization of motion commands > in place right now; there are two classes of commands: > > - sequenced: e.g. 2 feed moves a,b: b only starts with a complete (at > the message interface level; the fact that blending may happen is > irrelevant here) > - immediate: pause, abort, feed hold .. > > the term used in the code is 'issuing a command', and whether a > 'command can be issued' at a given point in time is determined by the > command *type*, and the sequencing decisions are based on serial > numbers and completion indications > the issuing logic is partly in task, and partly in motion (and > complex to understand) > > Now lets rename the expression 'OK to issue a command' to > 'precondition for execution of a command is true'; if we can > generalize this precondition for issuing a bit we might get the > multi-beast synchronization almost for free, as this is just another > messaging interaction (yeah, right, free code, sure ;) > > As for synchronization primitives, I can think of two forms: > > - beast A waits for beast B to reach a certain point in the > execution, meaning A blocks for B but not vice versa (asymmetric > sync) > - beast A and beast B join at a sync point. This is symmetric > synchronization, and basically the pthreads_join(), or the Ada > rendezvous for you DoD oldtimers;) > > Again: a good term is needed for sync point. > > I could think of the following language constructs: > > Asymmetric sync in 'named beast A' would require something like: > > reach(x) # the current beast A has reached sync point 'x'; this > is nonblocking and basically a broadcast or message of "reached(A,X)" > to all beasts > > in beast B we would have: > > waitfor(A,x) # B blocks until beast A has executed 'reach(x)' > > Symmetric multi-party rendezvous is the implicit combination of a > sync point and a list of waitfor's: > > join(y, B,C,D) # A blocks until B, C, and D also have reached > 'x' > > eg beast B would have: > > join(x, A,C,D) > > I'll see whether I can cook up some Petri net drawings, those are > great at describing such stuff concisely, FSM's dont cut it. Actually > I'll see how I can wire this into my Python mockup. > > Deadlock detection and prevention is another issue, which suggests > thinking about identification and ordering of sync points. > > If rs274ngc had no control structures, just a linear flow, it would > be possible to determine statically whether a given set of programs > using sync primitives is deadlock-free. With control structures, IMO > it is undecidable in the general case, but it might still be worth a > stab; an 80/20 static analysis and coding guidelines probably could > prevent most pitfalls. > > I think I need to look into runtime deadlock detection a bit. > --- > >> >> I just unpacked from a 21 hour drive, and am stupid tired. I'll try >> to >> think through this and see if I can come up with anything else that >> might help. I do not feel I did a good enough job at the >> response... >> >> EBo -- > > > ok, I might be getting a bit ahead of myself here, but I think giving > the 'precondition for issuing a command' some thought is a worthwhile > occupation for your next drive ;) > > - Michael > > >> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions >> will include endpoint security, mobile security and the latest in >> malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
