Am 10.09.2012 um 14:30 schrieb Kenneth Lerman: > The notion of statically created HAL pins being used to represent sync > points seems to cause a problem if sync points are within loops. > > They could no longer be reached monotonically.
I wrote the below, but 'undecidable' might have to be replaced by 'broken' for that case ;) >> 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. -m > > Regards, > > Ken > > On 9/10/2012 2:05 AM, Michael Haberler wrote: >> Actually I can think of a much simpler solution which is doable right now >> (multiple LinuxCNC2 instances) with a Python HAL user component. >> >> The difference to what I laid out in my previous mail is: synchronisation is >> achieved at the HAL pin level, not at the 'precondition for issuing a >> message' level. >> >> This would work as follows: >> >> - beast ID's and sync point ID's are represented as HAL say S32 values, say >> 1...4 and 1..n respectively. >> - the userland component creates a syncpoint pin for each beast ID, so if we >> have beasts 1..4 there would be pins syncpoint1..syncpoint4 >> - there is a pin representing the 'self beast id' >> - the syncpoint1 pin (aka 'self syncpoint') is watched for change by the >> userland component, a change is broadcast to its peers. >> - the syncpoint2..syncpoint4 pins are driven by the userland component, >> which collects change messages from its peer components. >> - sync points shall be set in a monotonically ascending order by some >> language construct, eg, M66 for now >> >> This doesnt synchronize just yet, but it is a completely generic sync point >> value exchange vehicle. >> >> Actual synchronization could happen at the G code level for now, or in a >> separate HAL component: >> >> reach(syncpoint=5) means setting the 'self' syncpoint pin value. The >> userland component will pick it a change and broadcast it eventually. >> >> waitfor(beast=2,syncpoint=42) would retrieve the syncpoint2 value and loop >> until >= 42, which is the asymmetric case if done in a single thread. >> >> waitfor(beasts=3,4,syncpoint=42) could be executed in several threads and >> would represent the rendezvous case. >> >> >> --- >> >> this isnt as elegant and general as the message precondition route, but it >> gets the job done >> >> I guess I will do a proof-of-concept with a Python HAL/zeromq messaging >> component, if just to accelerate fixing of our licensing issues;) >> >> other folks than might back-port this to Modbus if they so like >> >> -Michael >> >> Am 10.09.2012 um 07:25 schrieb Michael Haberler: >> >>> Am 10.09.2012 um 04:56 schrieb EBo: >>> >>>> On Sat, 8 Sep 2012 14:10:27 +0200, Michael Haberler wrote: >>>>> Am 08.09.2012 um 12:46 schrieb Dave Caroline: >>>>> >>>>>> While people are dreaming of new things for a version 3 >>>>>> I thought I would throw in a few items. >>>>>> I was staring at the sliding head thinking of the "right thing to >>>>>> do" >>>>>> and realised that the machine has interleaving of motion as well as >>>>>> coordinated motion >>>>>> >>>>>> While you could approximate that in the current system with effort >>>>>> in >>>>>> perhaps a special cam software system >>>>>> it would be better if it became built in somehow >>>>>> >>>>>> The way it currently works is a camshaft rotates once per part this >>>>>> drives cams for all slides, collets >>>>>> and accessory movement. >>>>>> >>>>>> this means while turning a dia another tool can be on a fast move >>>>>> into/out of position ready to start/finish cutting >>>>>> one tool could be cutting a dia while another cutting a taper >>>>>> >>>>>> That type of machine was "programmed" as starting/finishing an >>>>>> operation/move at an angle(time/number or revs of the total >>>>>> operation) >>>>>> of the cam >>>>>> just have to avoid crashes :) >>>>>> >>>>>> The machine also has mechanical gain(ratio) and offset so a class of >>>>>> parts can be made without remaking cams >>>>>> this also helps adjust tool wear/settings during production. >>>>>> >>>>>> I have seen other mentions on the list of machines that have >>>>>> multiple >>>>>> milling heads, I think this is the same problem >>>>>> normally the answer has been run multiple pcs and coordinate, this >>>>>> would be wrong on a single spindle sliding head lathe >>>>>> >>>>>> I found a working example on youtube >>>>>> http://www.youtube.com/watch?v=TDxvBHXklJo >>>>>> >>>>>> The rocker has two tools one being the cutting off tool so you can >>>>>> see >>>>>> the cycle time achievable with the method. >>>>>> shame about the flood lubricant and shaky camera work. >>>>>> >>>>>> Found a brochure for a later version on a forum >>>>>> >>>>>> http://www.practicalmachinist.com/vb/general/bechler-10-lathe-243337/ >>>>>> >>>>>> There have been a number of machines where a lot of axes are the >>>>>> same >>>>>> but just hold a different tool like this, there is a need to address >>>>>> their multiple axes in a consistent manner my machine has 4 X axes >>>>>> and >>>>>> a Z, not counting anything mounted on the front accessory block >>>>>> >>>>>> I have a couple of accessories one has three drills that can be >>>>>> brought into line with the spindle and the other has saws (screw >>>>>> head >>>>>> production probably) >>>>>> >>>>>> Dave Caroline >>>>> I'm currently gathering what could be LinuxCNC3 requirements, and see >>>>> how that can be folded into a plan and a time axis. Anyway. >>>>> >>>>> (what is actually the proper term for such a setup? multiple-spindle >>>>> might be a bit narrow in focus) >>>>> >>>>> from the above I derive: >>>>> >>>>> - assuming Linuxcnc runs on single machine: >>>>> Some key components which are currently singletons must become fully >>>>> instantiable. >>>>> >>>>> These are: task, the interpreter embedded in task, the motion module, >>>>> and the motion/task interface; iocontrol as long as it exists in its >>>>> current form (this is a minimum list; probably I forgot some). >>>>> Usrmotif probably could be coerced into supporting multiple motion >>>>> instances, but the motion module per se isnt there AFAICT. >>>>> >>>>> Other than motion, most of the HAL components are instantiable >>>>> multiple times (any other troubling exceptions?) >>>>> >>>>> As long as all instances live in a single memory space, HAL could be >>>>> used to synchronize instances; a bit low-level but workable >>>>> >>>>> - assuming LinuxCNC, or at least the RT control part, runs on >>>>> separate machines: >>>>> >>>>> then synchronization will have to move to messaging, and that will be >>>>> whatever replaces NML (btw methodically syncing be message exchange >>>>> is >>>>> a lot easier to get right than in a shared memory model). >>>>> >>>>> In both cases, synchronization will happen in or near HAL, but must >>>>> be represented as language constructs at the RS274NGC level, and >>>>> probably task has to involved to synchronize multiple interpreters >>>>> ("forking" and "joining" of "Gcode threads", omigawd); this could be >>>>> fudged with Python oword procedures as a stopgap measure. >>>>> >>>>> And then, a UI or multiple UI's which can deal with it. That's all.. >>>>> >>>>> --- >>>>> >>>>> related: one of the drawbacks of the current architecture - which I'd >>>>> like to remove in LinuxCNC3 - is: >>>>> >>>>> while within HAL one can create and link pretty much arbitrary >>>>> component instances as needed, this is not the case for modules which >>>>> take command messages, and deliver response messages (message meaning >>>>> 'a compound of more than one HAL signal, to be interpreted by a given >>>>> module atomically once it gets around to it'). Actually the plural is >>>>> nonsense, there's only the motion module which can do this. >>>>> >>>>> The consequence: motion sucks in ALL functionality and code which >>>>> necessarily relies on messaging to/from task - motion control proper, >>>>> spindle on/fwd/rev/orient support, homing..) since there is no way to >>>>> split and interface HAL components as soon as they interface by >>>>> messaging; this only works with pins and signals. We currently cannot >>>>> do a separate spindle, or spindle orient, or homing component, and >>>>> have them more easily replaceable than code currently within motion. >>>>> And consequently no one ever ventured to do another message-based >>>>> component (probably fended off by weighing the motion code ;) >>>>> >>>>> Enabling this would in essence mean "layering" of message-based >>>>> components: for instance, "homing" could generate feed move commands, >>>>> and motion picks them up and executes them. Or "spindle orient" could >>>>> pretty much run in isolation, except for synchronizing with >>>>> feed-hold. >>>>> >>>>> To support this, what is now the task/motion interface needs to be >>>>> abstracted and generalized so multiple components 'can have one' >>>>> without jumping hoops, and the scheduling of commands needs a bit >>>>> more >>>>> thought; I (currently) think it is relatively straightforward to do >>>>> by >>>>> creating a generic interface of this per module command/response >>>>> message interface and hook it into the scheduling layer which will be >>>>> exclusively message-based to start with. >>>>> >>>>> -- >>>>> >>>>> these are early thoughts in the paper scribblings stage; next thing >>>>> is to validate this with a Python mockup - a few threads >>>>> (representing >>>>> HALcomps with messaging) which communicate through ZeroMQ sockets. >>>>> When that looks feasible, the necessary HAL adaptations can be >>>>> derived. >>>>> >>> 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 > > > ------------------------------------------------------------------------------ > 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
