Real-Time is never defined as "now" you can't have that. Even if I place a pulse in a wire it takes time to come out the other end. Yes, seriously the speed of light delay through a cable is easy to measure with modest equipment. I have an application here at home were I measure and account for the time it takes for a signal to move down 50 feet of coax cable. There is always delay.
A better definition of real time is that events at happen on a schedule and the system is designed so the schedule is not violated. Or not violated in a manner that would hurt the application. This is very different from just being fast. You can define a real-tine system as one that is always "on time". Being on time is not the same as being fast. In fact one good way to make sure you are on time is to make good use of buffers and queues. An example from real life is that you can be on time for an appointment be getting to the address a few minute early then waiting at the curb until a few seconds before the appointment time. In this case the curb is a kind of queue where you wait. Reclocking is a common technique where data are sent across a cable to be buffered at the far end then clocked out of the buffer. If you look at any real time operating system (RTOS) one of the primitive functions is always a queue of some kind. You can't get much done inside of any complex system without queues. Without reading the VHDL source code we don't know what is happening inside the Mesa card but I strongly suspect the data in those UDP packets is getting re-clocked and the exact time when a packet arrives hardly matters. As long as they arrive at the curb BEFORE the appointed time so to speak we are OK. LinuxCNC seems to be designed around tasks that get executed on a fixed periodic schedule. In these kinds of systems as long as the data "gets there" before the net execution cycle it does not mater when it arrived. Scanning the VHDL source I see many times where the system waits for a"raising edge" before going on and doing something. That "waiting at the cub analogy might apply. If so then minor jitter in arrival time would not matter at all. Need to read the source code to know for sure. 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 > -- Chris Albertson Redondo Beach, California ------------------------------------------------------------------------------ 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
