I work in an environment at work where we do a lot of video broadcast over IP. That is all UDP multicast. Luckily, it is an environment where single dropped packet only corrupts that frame and section and is recovered the next base frame (ie, anywhere from 1 to 16 frames).
The reason we use UDP instead of other protocols is that UDP has no handshake. It is unilateral. Other protocols would require some sort of variation of a handshake to verify packet integrity. But, we also have an inherent safety check in that a lost packet only affects the individual frame. It does not propagate past that. In a RT situation with no check within the data itself, I would go with the most streamlined an uncluttered port and network path. I was not part of the discussion, so I do not know how the 7i92H works or what sort of data you would send over the network. But, if this is a protocol you are writing or coding around, it is possible to go the video concept were every x number of packets is a reference frame, which could sanity check the machine's path. So, for instance, if you were doing some sort of trajectory plan for something going from X1 Y1 to X2 Y2 in CAD, the g-code generated could include reference points along that line, then broadcast the entire path to the machine. If you drop a frame, it is not the end of the world. You should not crash the machine in most instances. (You could trash the part if you drop the boundary points). Personally, I think it is probably a lot of worry about a side issue. We broadcast gigs of video via UDP internally where I work every minute and alarms sound if we drop 3 frames. We rarely see packet drops. On Tue, Oct 25, 2016 at 10:54 AM, Mark <wendt.m...@gmail.com> wrote: > On 10/25/2016 12:16 PM, Nicklas Karlsson wrote: > >> True dat. But why take the chance and not use a direct connection with > >> a cross-over cable? Typical UDP traffic in a switched LAN is fairly > >> fast but not necessarily totally reliable. And over the years I've seen > >> plenty of collisions on a switched network for both TCP and UDP. The > >> difference being TCP has error correction and will resend the packet. > > The most usual in real time systems is packets are sent periodically and > receiver know it will receive packets. If bandwidth should be used to the > limit UDP is a better choice but with plenty of bandwidth left over TCP > might be a better choice. > > > > Then I do real time systems usually I tolerate some lost packets. > Usually the old value is not useful then new value is received but if there > is enough time request resend would be good. > > > > > > I guess the answer is it depend on available bandwidth and delay. You > also need a mechanism to queue up old data no more needed. > > > > In real time systems a queue is usually not good because if there is not > enough time it will start grow. If newest available data is used perfomance > may degrade but software will continue to run. > > > > > > Nicklas Karlsson > Under UDP, the receiver will receive packets, however under the protocol > it doesn't know if it receives "all" the packets. UDP is kind of a send > and forget protocol. If you want to make sure that all packets are > received, the only way to go is TCP. UDP uses less bandwidth than TCP, > though in reality the difference is quite small. > > A queue is not real time. Real time is *now* not when the queue decides > to send. Losing packets in a critical environment is not a good thing. > Let's suppose a limit is hit and the controller calls for a stop in one > packet. Oops, that packet got dropped. And the machine bangs into the > physical stops. Not a good thing. If you are going to use UDP for > critical situations, you're best off using a direct connect, getting rid > of the latency of the LAN and talking directly to the Mesa card. > > Mark > > ------------------------------------------------------------ > ------------------ > 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 > ------------------------------------------------------------------------------ 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
