On Tue, 25 Oct 2016, Stephen Dubovsky wrote:

> Date: Tue, 25 Oct 2016 14:40:46 -0400
> From: Stephen Dubovsky <smdubov...@gmail.com>
> Reply-To: "Enhanced Machine Controller (EMC)"
>     <emc-users@lists.sourceforge.net>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> 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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to