Jon Elson wrote: >Kirk Wallace wrote: > > >>There is some discussion on another thread about using Ethernet for EMC >>I/O. I can see that there is the appeal of plentiful and cheap hardware >>available with Ethernet, but there seems to be a fair amount of hacking >>needed to make it work. For my education, why not use a communication >>standard designed, from the start, for machine control? Can Ethernet >>overcome it drawbacks to become a full-fledged method for machine >>control communication? >> >> >Well, all the stuff we are doing requires a fair amount of >"hacking" the first time. Once you have figured out how to do >it, and put the required drivers, etc. into the CVS repository, >then there is much less hacking required the next time. I use >the parallel port because it WAS ubiquitous, fast, and quite >simple to control hardware with it. So much for what WAS true! > >What are Ethernet's "drawbacks"? The 100 Mbit/sec version is >fast, it is DAMN robust both electrically and protocol-wise, >modern Ethernet controllers handle a HUGE amount of the overhead >so the CPU has the minimum work to do, it is inter-operable with >other equipment, etc. etc. As I understand rtnet, it makes a >socket at user-level so that regular (non-real time) Tcp/Ip I/O >can be routed through the hardware that is under the rtnet >control. So, you can use the same Ethernet port for both >regular net traffic and the real-time control, at the same time. >That was too much for me to even ASK for, but they have already >done that. (Obviously, you want to use a router or something to >keep excess net traffic off the segment that has the real-time >trafic going on.) > > An ethernet segment must be either RT or not RT. If you connect a non-RTnet device to a hub/switch with RT devices on it, all bets are off. I think there were even restrictions on the number of hubs you can have, and they may say no switches at all. You can't use any old topology with RTNet. RTNet is a TDMA scheme - each device gets a time slot in which it may transmit. This eliminates collisions, which are the main cause of timing jitter on ethernet. I think the segment length calculations count a hub as 92 bit times. A switch could be many more, especially if it's a consumer-level device with a relatively slow processor. Also, the input to output time could be dependent on traffic on other switched ports that aren't related to the RT segment. You'd have to know a fair amount about the hub and its timing characteristics before using one. The way the "non-RT' traffic is handled is by sticking the data into unused time slots when necessary. You need the RTNet system to be up and running (with any time-slot negotiation done) before you can enable the regular traffic.
>USB has a bunch of restrictions that are the reason I have not >used it for this purpose. It uses low-level signals that are >NOT electrically isolated, it has insane requirements for >real-time access, such as the controller (in this case meaning >the PC or hub at the command end of the USB) can DEMAND the user >device power down, and if the user device fails to, the >coltroller will cut power to it, there is a timer built into the >controller that limits any device to 1000 messages a second. If >you want to send a message, get a reply, and send another >message, that would take either 2 or 3 ms, I never quite figured >that out. That just won't work for the way the hal_ppmc.c >driver handles communications with the Pico Systems boards. > > Yeah - for some reason, everyone and their brother is asking about USB motion controllers right now. I've just about gotten carpal tunnel trying to explain why it doesn't work, and yet the questions keep coming. Oh well - Steve ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
