PID Loop and PLC Faulting

Hello,

Attached is my PID setup. I am trying to vary the speed of a pump to keep water in a tank at 70 inches.

Everything works, as long as my %output is not 90% when the output is commanded. When not commanded, I can freely set the high limit to 100% and watch the output integer go to max. As soon as the command to run at the CV%, and over 90%, I get a fault and the controller freezes (minor overflow bit S5).

I have an SCP block controlling a VFD.

Please see picture Attached.

Anyone know why I get a fault over 90%, please help me! I think it is like a div/0 issue here?

Thank You!

can you post the entire RSS file? ...

As Ron has pointed out, it is hard to give much help with so little information. Where is your Input Scaling, are you using one of the new Analog Input Cards that allows you to set the Scaling to PID in the Card Setup? Is it in fact set to PID Scaling for that Channel? Also, on you Output SCP it should be 0-16383 not 0-16484.

I have never had a PID Block on any PLC cause a fault just by going to 100%. My guess would be there is some math that we may not be seeing in the picture that is overflowing. If you post a copy of the program when the Processor is faulted, we might be able to extract the exact cause. However, the current RSS File at the very least would be a big help.

Stu...........

OK, Attached!

You should zip your .RSS file first then post it here.

sorry, just rename the extension to .rss

Yes, my problem lies with the SCP block, I am scaling incorrectly, causing an overflow. I think I got it now, Thanks! (long day)

OK, I found it.

I am trying to do something stupid to get things working.

Our flowmeter is not installed, so I am trying to take pump RPM and scale a metering pump to dose based on #RPM, which is not exact (~15%) but it gets our equipment running on schedule.

I am working with my VFD vendor to get actual flow out of one of the "Pump Smart" parameters. I am getting close to re-coding once I get the GPM value in.

I totally see my mistake. Thanks all! (I fixed the scaling in the meantime)

well, keep us posted on the final outcome ... theoretically your CV shouldn't go any higher than 16383 – so the output of the SCP shouldn't ever try to go beyond 32767 ... in other words, I'd bet more than pocket change that the SCP is not your only problem ...

edit:

you posted just before I did with the update ... what I posted (is that redundant?) was based on your previous screen shot ... once again, your SCP might not have been scaled "correctly" - but the scaling that you originally showed us should not have caused an overflow and fault condition ...

that's why we wanted to see the whole program ...

A couple more issues:
You need to set your input for "Scaled for PID" not raw/proportional for the PID's PV.

Also you have the time mode in your PID set for STI but have not set the STI function. If your are gioing to run the PID in the ladder file you have it in then set it for timed mode.

You also might want to put a limit instruction before the SCP instruction.
Set the limits to the input min and input max of your SCP. This will prevent to SCP instruction from causing a overflow if the input goes above or below the min or max settings.

See example

You may also want to set the math overflow bit to stop your CPU going into fault.

LH

Tim, just curious , why your CV limits are between 70 and 89.??

Mickey said:

You also might want to put a limit instruction before the SCP instruction.
Set the limits to the input min and input max of your SCP.

Click to expand...

This covers up the problem but doesn't fix it. The SCP itself should not cause the fault because the difference between the input min and the input max is not 0 so the problem is with the input value itself. The input value should be checked to see if it is a valid value and if the overflow coil is set the input value should be saved away.

The overflow bit should never be set as a result of a floating point operation. If it is you don't simply reset the coil you save away the input value AND the data that is used to generate the input value so you have the 'bread crumbs' that will allow you to find the true cause.

Rockwell should have had three bits where there is just one. An overflow on an integer operation is not a problem. It should be monitored but never cause a fault. An overflow error in floating point is a real problem. There should also be a divide by 0 fault.

When a real fault occurs don't simply reset it. Log it! Find what caused it!

This covers up the problem but doesn't fix it. The SCP itself should not cause the fault because the difference between the input min and the input max is not 0 so the problem is with the input value itself. The input value should be checked to see if it is a valid value and if the overflow coil is set the input value should be saved away.

Click to expand...

The SCP can cause the overflow if the input exceeds the input max value,
because the SCP instruction will just extend the line above the scaled max value if told to do so. The limit instruction in my example is used to check the input value for a valid number as you subjected.