Roger,
top down, I think a clear synchronization model helps. A master/slave architecure is conceptually easier than peer synchronisation. Once that is clear, the sync primitives follow. I suggest to consider the following line of thinking: - the execution of the overall system is coordinated at numbered synchronisation points. - for the master this means the gcode program is divided into numbered sections, eg everything up to sync point 1 is 'region 1' - the master communicates its currently executing region number - any slave is permitted to go ahead autonomously up to a certain numbered synchronisation point, and then must block until the region is incremented. A good abstraction to model this kind of behaviour is a Petri net http://en.wikipedia.org/wiki/Petri_net . The synchronisation points correspond to transitions in Petri nets. The above scheme is, if you will, unidirectional synchronisation, and it is deadlock-free. In case you need bidirectional synchronisation (master may need to wait for certain slaves to reach a certain region), this can be done in principle but it needs some precaution so you dont create deadlocks. The principle is that the graph describing synchronisation relations may not have cycles, i.e. must be a DAG. For synchronisation between machines, I suggest looking into tying the HAL layers such that region numbers can be communicated through hal pins. Bool is not good enough, you need ints. Start simple - connect parports to communicate integers; when it works in principle, you can find a better way to communicate HAL values. As for the integration into G-code, the sync primitives (set current region, wait for peer to reach region) need to happen synchronized with execution flow in motion. One way to do this is through the M66/M67 codes. For HAL synchronisation, I think you'd need to cook up component which can do the HAL sync point I/O, or at least glue some components around motion.*in and motion*out pins (they are float and need int conversion). A way to pause execution is to have the 'must wait for sync point X' status set the feed override to zero until sync point reached. - Michael Am 01.09.2012 um 23:42 schrieb Roger Holmquist: > Well, syncronism is on the table, yes. > > I suppose a master node could be defined, taking care of the > semaphore management for the entire system. > This reminds me about Redis, couldn't that nice piece of SW be used? > > Like this: > > Init: > set sem1 1 > set sem2 1 > set sem3 1... > > Use: > if( get sem1) decr sem1 > get sem1 > if (sem1 < 0 ) incr sem1 > wait/timeout > else... > > and when finished: > incr sem1... > > Maybe it's overkill... > > > / Roger > > > > > ****************************** > Roger Holmquist > [email protected] > 0706-250123 > http://abcnc.se > ****************************** > > ------------------------------------------------------------------------------ > 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
