> -----Original Message----- > From: Dave [mailto:e...@dc9.tzo.com] > Sent: 16 February 2011 15:26 > To: emc-users@lists.sourceforge.net > Subject: Re: [Emc-users] Modbus TCP/IP response time [orig: > EMC2 and Ethernet] > > On 2/15/2011 10:43 PM, Yi-Shin Li wrote: > > On Sun, Feb 6, 2011 at 11:04 PM, Ralph Stirling< > > ralph.stirl...@wallawalla.edu> wrote: > > > > > >> I use a Wiznet hardware TCP/IP module (http://wiznet.co.kr) and a > >> Spartan3 FPGA with a Xilinx PicoBlaze softcore processor > to provide > >> the slave end communications. With a Dell GX620 and Ubuntu 10.04 > >> running Octave, I can do 1000Hz loop rates transferring > sixteen byte > >> packets (plus TCP overhead) each direction. In my > application I use > >> the FPGA to provide the timing, but there is no reason that RTAI > >> couldn't do that instead. The Wiznet module makes plain > TCP or UDP > >> communication absolutely trivial to implement, as the > entire stack is > >> contained in silicon. It is also blazingly fast for the > same reason. > >> The module costs ~$20, and the chip price is ~$7. I have > built some > >> boards with the FPGA and wiznet chip together, but haven't > finished > >> testing those. So far I've been using Digilent Spartan3 boards. > >> > >> So if EtherCAT looks to messy, you might consider > something simpler > >> like plain TCP or UDP. > >> > >> -- Ralph > >> > >> > > Hello Ralph, > > > > Are your running Ubuntu with RTAI kernel? > > Which communication protocol are you using for this project? > > What's the fastest response time you could get with Wiznet module? > > > > To EMC-list: > > > > I'm surveying how fast the response time could be for > typical Ethernet > > hardware with Modbus TCP/IP. The results I got are varying from > > 11.92us to 20ms. > > > > - 11.92us (slave turnaround time not included) > > - 250us (four bases could be updated in one > > millisecond)<http://www.modbus.org/faq.php> > > - 20ms (Modbus TCPIP Command/Response time to and from a > network slave > > device is typically > > > 20ms)<http://www.mynah.com/content/modbus-tcpip-ethernet-serial-bridge > > -performance> > > > > Please advise and share your experience regarding the > response time of > > Modbus TCP/IP. > > > > Thanks, > > > > Yishin Li > > > > > > A simple explanation of the differences between TCP and UDP. > http://www.skullbox.net/tcpudp.php > > TCP/IP has too much overhead for motion control type communication unless a great deal of intelligence is built into the slave processor. 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 shots in time-slots (TDMA). This requires an accurate distributed clock arrangement with a synchronising procedure. It is commonly referred to as isochronous transmission. The introduction of high resolution timers in Linux opened the way to achieving this strategy. The open source implementation is at www.rtnet.org . It works on fast ethernet (100mbps) and gigabit ethernet; so the possibilities already are in the underlying structure supporting EMC2 in RTAI, also Xenomai. The difficulty at present is that the system only works between a linux master and a linux slave whereas the commercial and other so-called open-source implementations have embeded the slave into asics or fpgas where the IP cores are proprietary. If someone with the know-how could port the slave functions of RTnet to something like a NXP LPC1768 see http://www.littlebirdelectronics.com/products/mbed-%252d-LPC1768-Development-Board.html then it is possible that a 200us cycle time could be achieved on 128 bits of IO on a fast ethernet connection pretty cheaply with the bonus of 300 feet transmission limit without a hub. Altenatively, porting to Ralph Stirling's setup might also be possible. Just my thoughts after a bit of research. Although I don't have the grey matter to do it myself. Regards John C
------------------------------------------------------------------------------ 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
