4
\$\begingroup\$

I have been having some good success with my first PID controller. It seems it needs just a little bit more work. Below is a picture of a sample run with my controller implemented. Currently I only have the proportional term correcting the signal and I am just graphing the integral term to see where is lies. My first question is, does the integral line seem to be "right"? It doesn't seem to be related to the other values in the way I would think. Mind you this is my first experience with closed loop controls, so I guess I probably shouldn't know what it should look like.

Legend:

  • Red - Commanded value (psi; this is the command prior to the correction)
  • Purple - Actual Value (psi; this is the actual output with only the proportional correction)
  • Yellow - Proportional correction (This value is added to the commanded value to produce the actual value)
  • Orange - Integral correction (This is simply being graphed to see where it would lie)

enter image description here

It just seems that the drop-off in the middle of the graph of the integral term is just random. I think it might have to do with a overflow condition with an Integer I am using, but then again I'm pretty sure the value should shoot to +-INF if thats the case.

Also, where the integral term is about constant (on the left side), should it not be around zero instead of 25? Because at those points in the graph (again on the left) the commanded and actual values are almost the same, why would the integral term command more to the signal if the signal is already where is should be?

The one other thing to mind is also, I only have the proportional term correcting. I have not added the integral term into the correction. This might effect how this graph would look, though I do not want to put the correction in and have the system react badly, thus why I am graphing it first and asking questions!

\$\endgroup\$
  • \$\begingroup\$ Just being suspicious here, but is that integral value starting to drop when some counter hits 32767 and overflows, i.e. is there a counter that counts at 0.1 msec intervals? \$\endgroup\$ – Anindo Ghosh Jun 4 '13 at 17:00
  • \$\begingroup\$ I thought that might be the issue, but it is not. It had to do with when I was resetting my accumulated integral term back to zero. The integral term was signed too, so if there was an overflow I think the line would shoot to ±Infinity \$\endgroup\$ – KDecker Jun 5 '13 at 17:22
5
\$\begingroup\$

Without the integral term being used within the feedback it could be nonsense - any error will accumulate in the integral term and just appear illogical. However it could show something useful....

For instance, at the start of your graph the integral term develops a value because there is a small error between demand and actual. As you approach t=2500 it seems to be drifting down slightly as the actual psi drifts slightly up - this makes sense.

When demand changes about t=2500, the integral ramps up (as you'd expect) and keeps ramping because actual isn't attaining demand.

This tells me it is working, however at 3200 something goes wrong - I'd expect integral to keep ramping up but it appears to flat-line then disappear about 4000.

I'd be suspicious of what happens after about 3200.

Hope this helps.

\$\endgroup\$
  • \$\begingroup\$ Yes, my suspicions exactly. I just wanted a sanity check. Let me see what I can do and I'll post back. Thanks @Andy aka \$\endgroup\$ – KDecker Jun 4 '13 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.