Stephen Wille Padnos wrote: > 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. Yes, clearly you take a certain risk if you tie the ethernet segment to the rest of the local net. Even with a router in between, there is a risk that an outside node could flood the EMC machine with packets and bog down the ethernet controller or rtnet. 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. Maybe the above is all still relevant, but my reading of the rtnet docs a few months ago were that rtnet routed the non-RT net traffic through rtnet (to serialize access to the ethernet port), so that you could still use one port to access the local net. A "hub" would be really bad, as it provides no isolation of traffic. A router is pretty necessary, and you make a good point that some may be awfully slow, or just non-deterministic. I'm not sure the important data are easily available, either.
Quoting from the rtnet home page : > but RTnet also includes a mechanism to tunnel non real-time traffic like > TCP/IP over RTmac, thus allowing a "single-cable" solution for connecting > control systems. I may have misinterpreted what this means. > 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. > Yes, that seems like a perfectly reasonable restriction. > >> > > 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. Some people HAVE gotten it to work, but I am not too clear on how they arranged to do it. I'm pretty sure that the servo model we use in EMC2 is not possible. Obviously, buffering up a bunch of movements and performing them in the USB device solves it if your model is different. Jon ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
