Kenneth Lerman wrote: > Jon, > > You suggest that the PC would request the registers from the IO board and > the IO board would respond with the requested registers. How much delay, > jitter, latency,... is acceptable? > Darn good question. I know the jitter on when the current parport interface requests the encoder counter to be sampled is less than 5 us, almost all in rt scheduler task switch overhead. I have no idea what sort of latency or jitter one would get with the rtnet and ethernet hardware. > The processor could send a new command every servo cycle. On receipt of the > command, the IO board could then send the current registers to the PC AND > process the command. The PC would use those registers to compute the next > command. > Yes, this actually has some merit : hold back the next velocity update until the NEXT servo cycle, and update velocity as you ask for current position. The PPMC (analog 10 V interface) actually does this in hardware, the last output from the PID loop is sent to the DAC chip's registers as soon as it is ready, but the DAC does not update to the analog output until the next sampling of the encoder counters. This is also how my Allen-Bradley 7320 implemented the servo cycle.
And, it reduces the number of messages by 33%, which sounds good. > There will always be a delay between reading the registers and generating a > new command. Is the delay using this scheme too long? Can the software > compensate for the delay? Given the current velocity and the time delay, we > could compute a projected position. Given the velocity, acceleration, and > time delay, we could do even better. > By reducing to the 2-message scheme, then as long as the delay is less than a full servo cycle (minus network latency) there is no problem. > This approach would save one packet. More importantly, the PID calculation > could take more time. In fact, it could use the essentially the entire servo > cycle time. That would let us increase the servo rate. > Yes, that is part of the idea here is to be able to up the servo rate. I'm not sure it will actually accomplish that, though, depending on the network delays. Jon ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
