On Tue, 25 Oct 2016, Stephen Dubovsky wrote: > Date: Tue, 25 Oct 2016 14:40:46 -0400 > From: Stephen Dubovsky <[email protected]> > Reply-To: "Enhanced Machine Controller (EMC)" > <[email protected]> > To: "Enhanced Machine Controller (EMC)" <[email protected]> > Subject: Re: [Emc-users] following along in my what if musings about ther new > oramge pi 2e > > All switches do at least store and forward today. Even the $20 cheap > ones. We use ethernet for real time control in some of our products. > Faster loop time than LinuxCNC. We use raw ethernet frames so that we > don't even need the ethernet stack (no DNS/etc needed either.) We also run > web services on the same products (ARM based) that run the IP stack and > coexist peacefully. > > Don't run ALL the computers in your office and the real-time network on the > same switch. real time stuff on one switch, rest of office on another, and > one cable between the switches. The real-time one will never see much > traffic (except broadcasts.) We do it. It works. We actualy have the > opposite problem. If we do even 1khz broadcast packets w/ real-time it > drives office wifi *NUTS* and crashes. FWIW, There is no way to do an > encrypted wifi broadcast. Everyone has different keys and this the access > port has a ton of encryption to do (plus it never lets your phones go to > sleep so the batteries die FAST.) VLAN tagging solves the broadcast/wifi > issue but thats no longer a $20 switch. > > Watchdog timeouts solve too many missing packet problems. IEEE1588v2 > solves most jitter problems if timing is critical. Embedded parts seem to > all support it now. We implemented it but have not needed to use the > actual correction factors yet as our control style is fairly robust against > jitter (but its there if we ever need it.) > > Stephen
Initiallly the hm2_eth driver provided no good recovery from dropped packets (it would hang for 100s of MS and cause a cascade of linuxcnc errors) but the errors occurred so seldomly that they were not a real problem (One test system had more than a year of uptime 24/7 at a 4 KHz update rate with no dropped packets before it was updated to a linuxcnc version with packket loss handling) This is in a benign electrical environment and of course packets can be corrupted by severe electrical noise so packet loss handling has been added to deal with lost read and write packets. Currently not all possible data loss situations are handled but I expect that they will be dealt with eventually. This requires separate handling (handshaking basically) of messages that change remote or linuxCNC state but are not continually retransmitted (by far most information sent back and for simply copies state info from linuxcnc to the remote or vice versa so occasional random packet loss causes very litte harm) Switches can be used with hm2_eth to allow (currently) up to 4 remote cards The remote hm2 cards are 100BT so a Gig switch works well as a concentrator/distributer with minimal host time usage (the driver separates the read and read request functions so there is a gain from overlaped operations) Typically there are store/forward delays when you change speed but it works quite well at 1 KHz and 4 cards Peter Wallace Mesa Electronics ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
