Hi Gents,


I've tried to look up some topics around the net regarding controlling the speed of a mobile plant running on tracks.The speed is to be controlled by a proportional valve which in turn controls the swashplates of a hydraulic powerpack driven by a diesel engine.
I have a 2000 pulses / rev encoder installed on the machine and wired back to to the High Speed inputs of the Micrologix 1400.I've built some code to simulate the process of controlling the speed with a PID loop.Instead of incrementing the HSC counts from the encoder itself on the machine I just add a constant value into F8:0 every time code is scanned.I fire a program file every 300 ms and subtract the value of the actual F8:0 from the value of F8:1 which is F8:0 300MS earlier which will give me the number of "pulses" the machine travelled in 300 ms so I can easily calculate the speed.Doing it this way I will always have a positive speed as the add instruction adds pulses.However the difference between F8:0 and F8:1 is not a constant.I believe this is a scantime issue.
Simulating montion by incrementing the value of F8:0 with a constant number will give us a constant speed as the number of pulses /time is a constant.Derivative of distance is speed where I consider pulses as k*distance.
When I chnage the number of which I increment F8:0 then I'll have acceleration as the number of pulses accumulated on the previous scan will be smaller than in the scan where the constant increased.Which is kool.
If I put another instruction in "ADD" to increment the number which I increment F8:0 with and trend it I will have the acceleration value jumping all over the place.Which comes down to scanning issues I think.Unfortunately I can't even attempt to apply a PID on the acceleration under this conditions.I really don't know how to cut the scantime out of it without using physicall hadware.
With the physicall plant the limitation imposed by the customer is that the Acceleration has to be less than or equal with 1.4m/s2 and maximum speed is 16km/h.I did simulate controlling the speed with a PID and that looks quite ok but when I try to simulate controlling the acceleration I just can't without having a stable value for it which I cannot obtain in my simulation.
To summarize I apply pressure on a pedal which is a 0-10v DC Analog input to the Micrologix.That dictates the speed to with I have to accelerate (max speed is 16Km/h = 10V) so I simply scale this input.The problem is that I have to limit the acceleration to 1.4 m/s2.I was told that the hydraulics can achieve more than 1.4 m/s2 (specially if there is no load).Could you please give some feedback whether I should use a PID at all or not and if yes whom should I controll with the PID the acceleration orthe speed .
Thank you for your time.

Hi Guys,

This is driving me nuts.I've made another file using the code posted here by someone called Ken Roach or similar which uses the free running timer to calculate the HZ from the encoder counts.Cool.If I have the frequency [Hz] I have the speed.
Since I have a micrologix 1100 but I have no encoder I thought I use the PTO function of the PLC.So when HSC reaches the preset value of 10 it executes the STI and I attempt to calculate the speed.Which is ok.However if you graph that speed the bloody speed will not be constant even after I do the first 1000 pulses of the PTO which I configured as acceleration.
I simply can't understand why I the PTO is asynchronous to the scan and I am using the S:4 TIME why the speed is not constant when the pulses generated by the PTO will be picked up by the HSC ??????????????? The HSC function operates asynchroniusly to the scan and since I wired O:2/0 straight to I:0.0 I should have the same number of pulses (after acc) between two consecutive HSC High Preset = 10 .Really simple.
Please help and point me out of here.Have a look in the attached file.Connect DC+ to O:2/0 COM then THE WIRE FROM O:2/0 goes to I/0 I/0 com goes to DC -.

If it is indeed scan time related, the standard way of doing this is to put your code inside an STI which gives you a consistent scan rate. You can trigger an STI easily at a 300 ms increment which gives you exactly what you desire. This is the most desirable and standard way of doing it. You also need to use this exact same method or the alternate below when your timer preset is less than 10 times the typical scan rate that you are seeing and well past the maximum scan rate for firing a PID instruction. A PID should NEVER be used directly without conditioning it based on some sort of timing control, preferably off a consistent time base. If you don't, then your PID gains will be scan time dependent. Even if everything is working well today, as the program gets developed/maintained over time, all your gains will slowly drift, which is definitely not a good thing.

Free running timers equal the timer amount plus part of a scan time, and depending on I/O speeds and code execution, throw a lot of randomness into the process. At best, you can use the more complicated alternative form of a "free running timer" if you can tolerate some jitter but need actual consistent timing signals that you can run totalizers and such off of:

Create a timer which has roughly double the length of your intended time preset such as a 600 ms timer if you actually needed only 300 ms. The exact number doesn't matter so long as it's much longer than the intended time preset because you want it to never expire.

When executing your code, check manually to see if the timer accumulator exceeds your required timer preset. For instance if you wanted 300 ms and the timer has a 0.001 second time base (1 ms), then check if it exceeds a count of 1000 (GRT Txx:yy.ACC 1000). If so, then subtract the intended timer preset from the accumulator and set a trigger bit that serves the exact same purpose as the .DN bit with a free running timer. This utilizes the fractional timing information in the PLC and the timer to achieve a consistent number of pulses per unit of time. This timer will still experience some jitter which is based on the jitter of the scan rate itself but eliminates the random length of timing that you get from a free running timer. An STI is even better (eliminates scan-dependent jitter), but when you just need consistent pulsing for say a totalizer, this method works just as good as the STI.

Note: There is one possible exception with PID firing only. It is possible on some PLC models to get access to the high resolution timer that the PLC uses internally (ControlLogix and SLC I believe can do this), which can be utilized to update the PID instruction's time base on the fly. I don't really recommend this approach but it's just as valid as providing a consistent time base in the first place.

Hi Paul,


I perfectly understand what you are saying.Put the code which does the speed calculation inside an STI routine which will guarantee that I am executing that calculus every 300ms.Beautiful and easy.What is not easy is the fact that Rockwell say that PTO and the HSC are scantime independent.HSC is a hardware counter running ASYNCHRONOUS to the scan.The same applies to PTO.Then in this case please explain to me how is it possible that the speed calculatedin the STI routine is not consistent? The value on one execution of the STI can be let's say 19 ,next STI 21 ,next 18,etc.How can I calculate acceleration on the run in these conditions when the speed is not consistent???
Ok.What I have done is this: I wired the PTO physical output O:2/0 into the I:0/0 (High Speed).I made up a PTO which will give me 10000 pulses out of which 1000 pulses will be used as acc/decc so we'll have a nice trapezoidal profile if you like.I set up the HSC to mode 0 so it pick up the pulses coming from the PTO.aFTER THE FIRST 1000 pulses the PTO should give consistent pulses example pulse number 2786 will be up for x microseconds then will go off for y microseconds ,pulse with number 2787 so the next one should be on for the same amount of x and then off for same y and so on until I reach the last 1000 when their frequency will change.Very simple.
Yet when I do the calculation inside the STI my speed jitters a bit.I do accumulate the PTO given puses into the HSC then on the STI I copy the HSC.ACC into F8:0 and then subratct the previous value of the HSC.ACC (300 ms earlier) from the actual value (all inside the STI) but when I grapfh the speed itis all over the place.The only explanation id that the PTO is not giving consistent pulses so the rate of change between two STI's is not constant.
Could someone help please? and explain this to me? All I really wnat is to calculate speed (accurately) using pulses from an encoder(my case for testing I usethePTO which souldbe good enough.

You are using the wrong tool for the job.
Even if your PLC could do the job perfectly what is the minimum acceleration that you can detect?
a(n)=(s(n)-2*s(n-1)+s(n-2))/∆t²
This assumes the period between the times are equal.
The calculation for acceleration if the times between the readings are unequal is more complicated

There are multiple ways to skin a cat.One of which would be using the simple statement that the acceleration is the derivative of the speed.a = dv/dt .Very simple how muchthe speed is changing with over a period of time.In my case the time between the readings is perfectly equal as Iam doing the calculation inside an STI routine which is triggered every 300 ms.So I check how much the speed changed in that 300 ms with.Or you can use Galilei's equation v2 = v02 +2a(x-x0) where we eliminate the time all together however I can execute this calculation every 300 ms or 30 ms depending on how often I trigger my STI.You are right however that I will not be able to detect fast changes in acceleration so I won't be able to calculate the true derivative for the speed continuously as it happens using a PLC I am afraid.So I just gave up trying to calculate the acceleration.If I can't calculate it I will not be able to control it.I am going to control the speeed instead not thatis much easier to do exactly as you need the derivative of the distance so we are on the same boat.In any case I am going to limit the aceleration by controlling the increments /decrements per time with which the proportional valve will open or close that gives me the limit for acc or decceleration.Ijustcan't see a better way.Micrologix is not too good.

This "cogging" effect is common with ALL motion control loops and there are ways to solve it. The most obvious way is to move the motion control loop out into the hardware. Also, you need to make sure that you have sufficient resolution and it sounds to me like you don't. Typically I see quotes of shooting from somewhere around 8-10 times the desired resolution MINIMUM. For instance if you are looking at speed and you expect to control RPM to say +/-1 RPM (at maximum speed allowed), then make sure to set your system up to be able to measure at a resolution of 0.01 RPM, realizing that this may push you into a much higher resolution encoder. In your case, you have a tradeoff. You can look at pulses per unit of time, or alternatively look at the time between pulses in order to make a measurement.

The second problem has to do with filtering/smoothing. Quite often for derivative-type measurements (acceleration and velocity), the methods that I've seen used tend to be say using linear prediction. An example would be to store the last 3-5 measurements and to calculate a 2nd order polynomial fit to those points. Then using the parametric curve that you generated gives you an estimator of speed an acceleration. The curve fit operation acts as a filter on the necessarily noisy input data. Consider looking at the motion control literature for ideas on solving this problem, since what you are doing is in effect building your own motion controller.

It's not the limits of the PLC by the way that are biting you. It's the overall system design. If you are willing to accept some fairly low system bandwidth limitations for control and you are willing to do a lot of engineering and programming mostly involving the higher level math involved in motion control, you can indeed do it. In fact I have actually done it but after spending weeks getting it all tuned right and writing lots of algorithms and trials to get it all working correctly, given a chance to do it all over, I would not do it 100% in a PLC. This isn't an easy task for a beginner. Even the motion control gurus usually will start with a prepackaged motion controller rather than build their own. You may want to back off and consider buying a true motion control system to handle the details for you. Allen Bradley sells single axis standalone motion controllers under the "Ultraware" name, but there are others out there such as Delta Systems (Peter reads and responds regularly to motion questions posted on this forum), G&L, and many others. Many of these include logic as well so you can either have the PLC do logic and communicate to the motion controller, or simply put all your motion control functions in the motion controller and eliminate the PLC altogether. A third much more expensive option would be to use the integrated motion system in a CompactLogix PLC but for a single axis of control and without knowing the scope of the rest of your project, this would seem to be prohibitively expensive from the beginning.

Get the right tool


It is good, just not for doing what you are trying to do.


Not all. it is caused by a lack of resolution and update rate.

I made this pdf years ago for Chackorules when he was having troubles getting his system for go with a 300 count per revolution encode. That was way to low. Now I show the difference between a high resolution encoder 523288 counts per rev and at 4000 counts per revolution encoder.

I should do this again just changing the update rate.

The point is that I know how all the different hardware change will affect the system.
So start adding your time to the cost of the motion controller. The money is piling up rapidly and no matter what you do it will not be good. You could have been done shortly after wiring was complete. You could have auto tuning, smooth ramps etc.

I see this all the time. Look at the plcs.net. There is a person over there that is trying to do a hydraulic test system in a S7 plc. No way and the weeks are ticking by. Whereas I can set that up easily.

It's looking good gents.I just had to spend some time on it.I cannot control stil the acceleration however I can measure it with a 300 ms accuracy in my case can be lowered.I've got smooth ramps both acceleration and decceleration.When I finish completely the code I'll post it.
A few of you who said that the control loop should be taken away from the PLC but what I am trying to control is not the "Hadron Collider" so it will be ok with more then enough resolution.'Will post the code soon.