Kenneth Lerman wrote: > Remember that the issue on ethernet will not be throughput; it will be > latency. I'm sure Jon can give you a profile of what he is doing. > > How many bytes in a send packet? > How many bytes is a receive packet? > Cycle time? > > OK, the current latency is VERY short per byte, reading sequential bytes takes about 800 ns.
I am guessing a request map might look like : length start addr length start addr zero So, that could be about 10 bytes, and the return packet could be maybe 15 bytes, for a 4-axis system. I would want to be able do this at a several KHz rate. I can do 2-5 KHz with parallel ports, depending on CPU, port and number of axes. With only 4 axes, PCI par port and a faster CPU, 10 KHz is feasible, but kind of pushing it by par port. I'd hope that this could be done with ample margin with 8 axes using an Ethernet system. The protocol would look something like this, with the way the current driver works : The first packet would write to a register to latch encoder count values, then read back the encoder counts and digital inputs. The Arm CPU would send back a response packet with these values. The PID servo calculation would be done and another packet would be sent with new velocities and digital outputs. So, each servo cycle would involve 3 short packets being transmitted. Hopefully, the latencies could be held down to 10 us or so, as each stage has to wait for the results from the other one. Jon ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
