Rockwell PID AOI

mitch11

Member
Join Date
Mar 2017
Location
Ohio
Posts
26
Does anyone have there own PID AOI that they would like to share?

I understand that there are a few PID instructions offered by Rockwell, but I've had varying levels of success implementing those in projects I've been involved with.

Thanks,
🍺
 
I've never had issues with provided PID. I use a live gragh when tuning, maybe im missing something?
 
There are many different forms of PID. Some are better than other depending on what you want to do. Sometimes a full PID is not required. A PI or PD will do but other times a PID with second derivative gain is required. Then there is the problem on how integrator windup is handled.

I haven't played around with the PIDs on a Control Logix but the PIDs on SLCs and Micrologix leave much to be desired.

What someone should write is a Smith Predictor AOI.
 
Originally posted by Peter Nachtwey:

What someone should write is a Smith Predictor AOI.

If I ever get some time on my hands I will probably do this. But what i really want to do is get a Kalman filter implementation as an AOI. I just haven't done enough research to know what implications this will have on plc scan time.

I have also had my issues getting the AB PID to work for me. It isn't so much the heart of the control law. I think that works fine. It is more trying to get the instruction to perform as I want in the mode I want in the face of the 50 or so parameters there are to deal with. The biggest issue is if it isn't doing what you want you have very little to look at to figure out why it is or isn't doing what you want it to do. I think it is a case of trying to do everything for everyone in one instruction, which adds complexity to the implementation. Then again, I am not a patient man, which will tend to cloud my view in this case.

mitch11, PM me. I probably have something you can at least start with.

Keith
 
Last edited:
If I ever get some time on my hands I will probably do this. But what i really want to do is get a Kalman filter implementation as an AOI. I just haven't done enough research to know what implications this will have on plc scan time.
You should look into making a alpha-beta-gamma filter AOI. You would be a hero if you shared it.
https://en.wikipedia.org/wiki/Alpha_beta_filter
An alpha-beta-gamma filter is similar to a Kalman filter except the gains are chosen differently. Kalman filter gains can be updated dynamically. This requires a lot of CPU power. There is also the steady state Kalman filter where the heavy number crunching is done once. The goal of the Kalman filter is be optimal. However, to do this the user needs to know the system covariance and the measurement noise covariance. The Kalman filter use these two values or arrays to determine the proper weighting between the current estimate and the new inputs. There are two huge problems with this.
1 people do not know the system covariance or measurement covariance.
2. They do not have a model to estimate the next value.
In other engineering forums, I have yet to see someone find these values.
So
Use the easy to implement alpha-beta-gamma filter where you choose the gains until you get the desired frequency response.

Our new delta RMC200 uses an alpha-beta-gamma or alpha-beta-gamma-delta to filter out chain noise or other noise that the motion controller can be geared too. This allows us to generate a master position, velocity and acceleration that is use to compute feed forward gains for the slaves.
https://deltamotion.com/peter/Maxima/ABG.html
https://deltamotion.com/peter/Maxima/ABGD.html

I have also had my issues getting the AB PID to work for me. It isn't so much the heart of the control law. I think that works fine.
Actually it draws a perfect vacuum for hydraulic servo control.

It is more trying to get the instruction to perform as I want in the mode I want in the face of the 50 or so parameters there are to deal with.
You need some mathemagic

The biggest issue is if it isn't doing what you want you have very little to look at to figure out why it is or isn't doing what you want it to do.
and a good data recorder so that you can do system identification.

I think it is a case of trying to do everything for everyone in one instruction, which adds complexity to the implementation. Then again, I am not a patient man, which will tend to cloud my view in this case.
Being able to predict is huge.
 
Peter, in many cases I couldn't even get the function to the point where I need any of the stuff you are referring to. Just getting it to react to ANYTHING is sometimes a challenge regardless of what you do with the gains or the software output value. This is where i get frustrated and just roll my own. Right or wrong I know EXACTLY what my own function is doing and EXACTLY why it is doing it.

Much of this is based on expectation. If I put the function into auto I expect it to act like it is in auto. Oscillation is one of the expected things that can happen in auto mode and I would be OK with that. But it should do SOMETHING. If I put it in manual I just want to to be able to put the output where i want it without anything interfering with that act. So this is less about performance and simply about action. There are just too many things that can seemingly get in the way of the function doing what one would think it should.

Thanks for the tip on Kalman filter processing requirements. That is likely not something I want to task a PLC with given the stuff i do. Interestingly I was thinking about alpha-beta filters as an alternative to Kalman filters this morning. I remember reading some of the stuff you posted about them and thought that might be an easier way to go. I might dive into that.

Keith
 
Last edited:
Is the type of filter alpha beta gamma, something along the lines we use in Arduino for IMU integrating i.s Madgwick/Mahoney filter, of course we also use a Kalman, but as you rightly say it is CPU heavy.
 
Is the type of filter alpha beta gamma, something along the lines we use in Arduino for IMU integrating
Yes, however, the alpha-beta-gamma filter I used does not take into account gravity. It is one dimensional and meant to smooth out encoder data on feed chains and conveyors. There are a lot of question about this on this forum.

i.s Madgwick/Mahoney filter, of course we also use a Kalman, but as you rightly say it is CPU heavy.
I don't know about Madgwick/Mahoney filters. It looks like they are somewhat related just like the alpha-beta-gamma filter is somewhat like a Luenberg Observer or Kalman filter.

The Madgwick/Mahoney filter look like they are specifically designed for computing the orientation of a IMU which is a little more complicated than a one dimensional alpha-beta-gamma filter.

The main advantage of a alpha-beta-gamma filter is that you get 95% of the performance with only 5% of the effort compared to a Kalman filter.
 
Thanks for the info Peter, re the CPU usage, until a few years ago their has been limited process power in Arduino hence madgwick/mahoney filters, but now with 32 bit processors that has now changed and kalman are common. I have found though that the kalman filtered IMU's tend to run away badly when quickly tilted (lots of over shoot i.e 15+ degrees) and returned to there previous position (probable not tuned for a rapid tilt?). Where as the Madg/mahoney don't display this issue. In testing 8+ different IMU's l haven't seen any advantage over the madg/mahoney from the kalman, if anything the opposite.
The Madgwick filter is a little more processor hungry than the Mahoney (say on a 8 bit Arduino), but in my testing gives a far better results and most Arduino now are 16 bit minimum, so running the Madgwick filter isn't a problem
 
To get thing rolling l offer what l use as a PID loop, so Peter will most probably be able to confirm that l really don't have any idea what l'm doing.
There is a bit of dribble about sailing so you understand what l’m up to and it might be an insight into your own process.
There is a lot of other code removed for clarity, but the main PID concept is here.
I must admit l couldn’t believe how basic a PID block is (mine anyway), just a very small amount of basic maths.
This PID is written in C/C++ as it is coded for Arduino (but of course you could write a AOI very easily) and controls an auto pilot for a Yacht.
So the error component is how many degrees the “Boat Heading” ( PV) is from the heading we wish to go to “Heading to Steer” (setpoint).
The only thing that is different about this loop, that maybe very relevant to process control, is that l made the CMD (Control Output CV) for the control of the rudder drive motor non linear. Maybe some PID algorithms’ have this? The need for non linear (NL) CMD isn’t required all the time, but as it really costs nothing to use and really adds little to the CMD (CV) until it is needed, it seems foolish not to have it at all times IMHO.
I did this to correct when l was under spinnaker and the boat broached because there wasn’t enough rudder applied (CV) for the amount of error to correct the drive of the spinnaker, so the boat stayed broached until something happened to make it apply more CMD (a little bit more heading error) or the wind eased and the amount of helm was enough to bring the boat back on course. I could have lifted up the overall gain, but then there is too much CMD when it mostly isn’t needed (and when you are solo, broached by a spinnaker in 15knts of wind, you don't want to be playing with your AP, l will give you that tip for free).
The Compass is an IMU so hence were the madgwick/Mahoney filter question came from, which is integrating at 400hz. The Filtering and PID block are scanned at 50hz
Below is an example of basic filtering to the output of the Pots used to adjust the gains.

float Kcmd = 0.05; // 0.05 = 1/50 = 1 second smoothing
PID_Ks[1] = array for the 4 x Pots used to adjust the gains. Ks [0,1,2,3] 0= overall gain, 1= proportional gain, 2= derivative, 3=integral

integral_smoothed_1 = (1 - Kcmd ) * integral_smoothed_1 + Kcmd * PID_Ks[1];
PID_Ks[1] = integral_smoothed_1;

Below is the PD controller l use. Integral isn’t require, but when it is used it tends to wreck things.
ROT= rate of turn = how many degrees the boat is turning in 1 second ( change in PV). This gives counter rudder i.e. removes overshoot.
In my case l get this from a rated gyro, process would use something like, PV rate of change = PV - PV_old, over a time frame.
ROT is filtered like above.
Heading_error = Heading to steer – heading (setpoint- PV)
Rudder_offset = how much helm is required to correct for weather/lee helm when boat is going straight = set point offset

PID_output = PID_Ks[0] * (PID_Ks[1] * heading_error - PID_Ks[2] * ROT);
PID_output = PID_output + PID_output * abs(PID_output) / 70; // to increase rudder disproportionately to errors X= X + X* ABS(X)/70
rudder_command = PID_output + Rudder_Offset; // rudder offset set when AP key is pressed when on desired course.
CMD = rudder command

Just to show the full PID.
Integral error = 0.001;// or what ever you want
integral_error = integral_error + PID_Ks[3] * heading_error; //integral error is changing and adding back on itself.

PID_output = PID_Ks[0] * (PID_Ks[1] * heading_error - PID_Ks[2] * ROT + (Ks[3] * integral_error));
rudder_command = PID_output;
CMD= rudder_command

Unlike process, tuning is very easy, just dependent on boat speed. Set speed (say 6 knts) set P_Overall = 2, P= 0.5, D=1, get AP to do 90 degree turn and see whether there is over/under shoot. Alter Ks[2] until there is no fish tailing. Have different settings for different speeds. Normally lower Ks[0] (overall gain), unless weather conditions require more rudder, so there is less drive action, saving battery power

Hopefully Peter can see something that's maybe incorrect and then l will get a better PID for my auto pilot and we all learn something more.
But l will add that this AP steers better than any pleasure craft bought unit can and IMHO would equal a NKE (commonly used by the world solo guys). But this is really due to the compass, as the heading error (PV) is the critical component.
 
To get thing rolling l offer what l use as a PID loop, so Peter will most probably be able to confirm that l really don't have any idea what l'm doing.
There is a bit of dribble about sailing so you understand what l’m up to and it might be an insight into your own process.
Yes, I have done some ocean sailing. Two of the crew members were "yanmar" and "ray" or "raytheon" :)

duckman, you have an application that requires a little more thinking than just making a PID. At first I thought you had screwed up but I can see you are on the right track. You are right about scaling the PID by the inverse of the boat speed.

My question is do you have rudder feedback? What you should have is a control loop for the rudder and one for the heading. Without the heading loop is the outer loop and the rudder loop is the inner loop. If you don't have rudder feedback you need an integrator.

What about course feedback? Steering a heading is fine but sometimes there is a current that must be accounted for. That would be yet another outer loop.

The course loop would send heading set points to the heading loop. The heading will not always be the same as the course. The heading loop will send rudder set points to the rubber loop.

So what feedback do you have besides heading?

When I went ocean sailing we needed only about 12 to 13 way points to go from Astoria, Oregon, to Roach Harbor Washington. There was a long stretch going up the coast of Washington. Current wasn't too much of an issue in the ocean but in the Pudget Sound the current was 4 knots at times.
 
Hi Peter, yes have a feedback loop from a rudder reference as well as XTE from a chart plotter for course correction. Also set up for no rudder feedback, called "ghost rudder feed back" but you can't have as savage gain settings. H-Bridge variable speed motor controller for the rudder drive. As l said this steers beautifully and l have had it in some challenging conditions, surfing big waves at so far up to 14knts in an old 33ft, which is the hardest point of steering and were most pleasure craft (Raymarine) AP's can't handle.
I have so far never had to hand steer. The AP software side is easy, it's the motor drive system were most people under size and then have to hand steer when it gets rough.
Also have made a Man Over Board feature, that when the RF signal is lost from the device l wear around my neck, the boat will turn around and turn the motor off. Also 2 pots to give independent adjustment port/starboard dead band(sea sate/hysteresis) on course when it's really rough. The AP will start after reaching dead band, then bring the boat back to course (another hysteresis), before it resets, then won't come on until reaching dead band again. Commercial units only seen to have an equal dead band so the boat can swing along way off course port/starb before AP corrects.

Just given myself away here, as you will see l have 2 names. 2 different computers set up at 2 different times when l also swapped service providers.
I really sail down in the flat waters of the Southern Ocean and Bass Straight in Tasmania.
 
Last edited:
OK, so the is a course that must be followed. The heading must be adjusted to follow the course. Then the rudder must move to match the heading. An integrator will be necessary without rudder feedback. This will allow the rubber to keep moving until the SP heading is achieved.

Does this make sense?
The course loop only needs a simple PI control.
The same goes for the heading loop if using rudder feedback.
If not using rudder feedback then a PID might be in order.
BUT!!!!!!!!!!!
I would not use a normal PID or PI. These a prone to integrator windup. You have mentioned this is a problem.
I would use a I-P or I-PD control.
This means that only the integrator acts on the error. The P and D gains act on changes in the PV.
This method of control will not wind up the integrator and cause oscillation problems.
If you have questions about this then post again. I have good examples.

It would be fun to sail down there with you. I would like to do the CSN "Southern Cross" thing. I am 65 and have not sailed now for about 8 years. I don't know if my sea legs are still with me.

The man overboard feature you mentioned is great. We hand to be always connected to the boat when only one person was top side. I still think I would rather be tethered in rough weather.

I was sailing on a 38 ft Catalina with two other people so there were 5 of counting Yanmar and Ray.
We used Yanmar a lot when going from Astoria north around Cape Flatery because the wind was always against us. Going back we could set the sails wing and wing or put up the spinaker and not have to mess with the sails going back to Astoria because the wind was always behind us.
 

Similar Topics

I've got quite a few questions to fire. In the velocity form, why does the P term now act like the D term in the positional form? The D term...
Replies
2
Views
987
Hello all, A group I am involved with is just completing converting a Siemens APACS control system over to an RSLogix PLC. The subject came up of...
Replies
1
Views
1,153
Good morning, I have a Rockwell CompactLogix PLC which sits on the same panel Ethernet network as a Eurotherm PID controller, and I am trying to...
Replies
5
Views
3,313
Hi Guys, I have a requirement to contol a pump speed with a VSD to achieve a steady temperature in a process environment. Hot water is being...
Replies
6
Views
4,799
Hi, I'd like to ask does anyone come across the PID tuning software from Rockwell - RSTUNE (if not mistaken). What's the difference using RSTune...
Replies
10
Views
18,827
Back
Top Bottom