John Kasunich wrote: > Bas Laarhoven wrote: > >> A question for a guru who has in depth knowledge of the HAL scheduling >> mechanism: >> >> I'm developing a driver for a my servo motor controller. The interface >> is via a PC parallel port. Only one RT thread is used that processes the >> position feedback from the controller, and calculates the speed signal >> for the controller. The thread runs every 1 ms and does also contain the >> PID and motion controllers. >> >> I've written the HAL file so that all components are listed in order of >> the data flowing through. Expecting this to give the best results. Thus >> the thread starts with a call on the driver for feedback values and ends >> with another call setting the output. Due to some interference, the >> actual duration of the input and output calls varies a lot (e.g. >> +100us). If my assumptions are correct, this generates variation >> (jitter) on the exact moment that the motion controller gets called and >> this may be undesired behavior. >> >> Assumption 1. The components get processed on the RT thread in the order >> these are added to the thread (I think I read that somewhere and it >> seems logical). >> Assumption 2. The thread is scheduled with a fixed interval, so the >> first components starts with the least jitter regarding the thread >> frequency. >> Assumption 3. If one components has been processed, the processing of >> the next starts immediately and so on, until all components are done. >> >> > > All assumptions are correct. > > >> If all these assumptions are correct, the moment that the motion >> controller gets called will thus vary, depending on variations in >> processing time of the individual components. As mentioned above, in my >> situation there is a huge variation in duration of the driver call and >> I'm wondering if this is either bad, very bad, or not bad at all >> (because it's somehow compensated for). >> > > The timing of the motion controller call doesn't matter, what matters > are when the driver reads the feedback, and when the driver sends the > new command. The former is easy - as you pointed out the driver read is > the first thing in the thread. > > The motion controller is using data provided by the driver, so it's > perception of the "state of the world" is the state that existed when > the driver captured its inputs. It doesn't matter when the motion > controller actually runs. > > However, the end result of the controller and the PID is a command to > the hardware - the controller and PID are assuming that the output will > be applied "immediately" and be in effect for a full servo period before > then next run of the thread. That is never actually true - there is > always some delay, and there is always some jitter in that delay. > > In most cases, that delay (and jitter) has no meaningful effect on the > machine, especially if you are doing "normal" machining. If you are > working on the bleeding edge of servo performance (very high speeds, > very high accuracy, very fast acceleration, etc) you might see the effects. > > Regards, > > John Kasunich > > Ah, thanks John, you made it very clear! So in my situation the input sampling moment is fixed (at the start of the thread) and only the update of the output varies with the variations in processing time. You state this will probably have no noticeable effect, but as this variation is a significant part of the PID cycle time, wouldn't it be better to reduce the variation (noise) and work with a fixed although increased delay? Another option is to lower the loop update frequency as that reduces the noise in more than one way. Do you know of a rule of thumb for the cycle time in relation to the system response time ?
Regards, Bas > >> Do I need to work on the driver, so that it uses a fixed period of time >> (probably increasing the CPU load), or is this not an issue? >> >> -- Bas >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
