On Wed, 2011-02-16 at 11:18 -0600, Jon Elson wrote: > John L. Craddock wrote: > > > > The most common way of establishing real time determinism is to > eliminate the collisions inherent in ethernet. This is done by > establising a master / slave strategy with the master calling the ... snip > as there is ONE master and one or several slaves. > But, the slaves would never initiate a transfer. If the master were > set to address each slave and wait for the response before addressing ... snip
(a little bit of a rant) I'm not sure fixating on Ethernet (and USB, and laptops, and ...) is the most efficient way to approach this. When you peel away all of the fluff in Ethernet (or any other buzzword automation protocol), I suspect you'll get something like SPI or I2C. I tend to agree with Jon, in that you should have one master, that slaves can pull information from by either a broadcast or point to point. If I were King of the World, I would set up a broadcast of a sequence of bytes, lets say 0 to 100. 0 would always be something like X velocity, 1 = Y velocity, etcetera. This would be a synchronous steam and each slave could pull the data that applies to their function. The only issues are to have enough bandwidth and broadcast in real-time. I believe this is the way that the parallel port FPGA controllers work (but too many wires), and similar to Modbus (but too slow). SPI hardware is cheap enough even in custom DIY form, to compete with the economy-of-scale cost of Ethernet. Write the spec first then, see what technology fits. With open source one can invent whatever standard you want (EMC2bus?), so one doesn't need to follow anyone else's lead, including mine of course. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
