You still need to be careful regarding Modbus equipment compatibility. There are still poorly implemented interfaces out there that do not meet the standards. But they are generally pretty easy to spot as Modbus is very popular, so a search on the devices Modbus interface will oftentimes show mention of incompatibilities. For a while there were a number of VFDs being produced that were not entirely Modbus compliant.
Regarding the semaphores, shared space, conflict avoidance problem; I was thinking that perhaps a custom M code could be executed prior entering a shared space, and the programming within that Mcode could check and see if the space is available (semaphore locked/set) and if not, then lock/set the semaphore to take control of the shared space/resource, otherwise wait for the space to become available. Some code to disengage from the workpiece just prior to the M code might be needed to prevent tool burning, etc but that would be particular to each machine. Dave On 9/2/2012 11:37 AM, EBo wrote: > My one foray into the modbus world did not go well. I bought some low > end gear that supposedly supported modbus -- only to find that the CPU > had it, but they had not gotten around to support it yet in the OS. > Playing with the opensource stuff was about as fun... That being said, > that all happened 4 or 5 years ago, and I would hope that things are > better now. > > Before we get going to far lets looks at a couple of thinks like > connectivity. There has been proposed TCP/IP (which implies a net or > possibly PPP connectivity), Modbus, (for other reasons) USB, P9 > distributed file system, and maybe even GPIO lines... > > Abstractly, we have critical regions of space which are equivalent to > the critical regions of the code that operate over that space. For any > given setup we can define these overlaps, but it will have to be done a > priori. Ideally, we would be able to analyze sections of the space and > the blocked machine will move on to other operations until the lock > yields. What is more realistic is that the machine goes into a wait > state until the yield. So, not only do we need to identify what areas > of the workspace is in the critical section, but also what we should do > in a wait state -- maybe it is OK to leave the router spinning in place, > but that can also burn the material... > > So this near stream of conscious speculation (that was interrupted 6 > times preparing for a party) I would want to abstract the interface so > that it would operate over at least a couple of different channels. > > On Sun, 2 Sep 2012 07:12:59 +0200, Roger Holmquist wrote: > >> Well Dave, as usual U got lost in all the links but the Wiki and >> this one >> --- http://www.modbus.org/tech.php --- >> might be useful? >> >> Here is some observations after some surfing: >> - There is obviously some different protocol versions available where >> the ascii-version might be suitable? >> - A "tcp"-version does also appear even if this feature is >> categorised on another level... >> - Source code is available for download with not so well figured-out >> content related to some chips... >> - Some vendors want to sell their HW/SW-combos connected to the >> protocol... >> >> Well, comments? >> >> / Roger >> >> >> >> >> 1 sep 2012 kl. 22:09 skrev >> [email protected]: >> >> >>> This makes a lot of sense, but I would also look at using Modbus >>> TCP and >>> ladder, plus some custom M codes to interlock the machines together >>> so >>> you can prevent collisions between machines. >>> Yes, it gets complicated but that is the nature of the beast. >>> >>> Dave >>> >> ****************************** >> 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 > > ------------------------------------------------------------------------------ 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
