PID Floating Point PV (PLC5)

Situation: I have created an application that uses an AB PLC5/40 and a PID control Loop. I have changed from the integer control block to PD because all my variables are floating point. All my inputs are already scaled 0.0-100.0% which is also the engineering units that I desire.

Problem: When I try to enter floating point values for SP & PV into the PID block I get an error of "Invalid Data Type". So I ended up having to send my PV and SP to integer values before I send them to the PID block.

Question: Is there a way that I may send the floating point values directly into the PID block?

I don´t know about PLC5, but with SLC you can scale your floating point data in integer data to be suitable to be processed by the PID instruction.

In PLC5 you can do the same however. Most of the items inside the PD block that are floating point can be written to directly with a MOV instruction or otherwise. The Set point and PV instructions are also stored as floating point in the PD file so I wanted to know if there was a way that I can write SP and PV directly as floating point into the PID block.

All data in slc PID instruction is based on integer, i guess the same must happens on PLC5 so scale float data into integer to be used with PID instruction and then scale results in integer into float.

Hi,

I have not done PID in a PLC-5 for a long time, but if I remember well, when you use PD block address, you use Unscaled value in the Process Value Parameter (From your analog module for ex.).

Then in the PID Configuration, you scale you Process Raw value using the Input Range Maximum/Minimum and Engineering Unit Maximum/Minimum.
Then the Analog Input Scaled Value is available (Read Only) through the PD11:0.PV address... You can use the PD11:0.SP to specify a Scaled setpoint (RW)...


Regards,

Yves

Greetings Kabir ...



you said:

I have changed from the integer control block to PD because all my variables are floating point.

Click to expand...

the first question is: from where are you getting those “floating point variables” - and specifically, your PV signal? ...



more specifically, what type of hardware are you using? ... for most PLC-5 systems, the answer to that question is USUALLY “from a 1771-IFE analog input module” ... for the sake of discussion, let’s just say that’s your answer ...



keep in mind that the 1771-IFE analog input modules were originally based on 12-bit resolution ... that means that the raw signal from that module USUALLY arrives in the processor’s memory as an integer number which ranges in value from 0 through 4095 ...



key point: scaling that raw integer value into a floating point format doesn’t give you any better “resolution” than the 4096 steps (0 through and including 4095) that you originally started out with ... yes, you might get decimal places that make it LOOK LIKE the signal is “chopped finer” - but if you’ll experiment with some manually entered signals (highly recommended) you’ll probably find that the floating point number still moves in chunky-style “steps” in perfect time with the raw input integer number ...



as an example, let’s use the common operation “divide the raw integer by 40.95” to get a signal which ranges from 0.0 to 100.0 in a floating point location ... you might be doing it some other way - but we can’t tell based on what you’ve posted so far ... anyway ...



just for random examples:



1234 from the IFE module “scales out” to 30.13431 ... and ...

1235 from the IFE module “scales out” to 30.15873 ...



now those decimal places might LOOK LIKE we’re getting “better than integer” resolution - but we’re not ... consider that there will NEVER be a resulting value between 30.13431 and 30.15873 ... as a specific example: you’ll never see a value of 30.14000 - simply because the 1771-IFE analog module can’t generate a signal between 1234 and 1235 ...



so where does that leave us? ... well, IF (big IF) you’re scaling your analog inputs to make things easier on the operators to work with their favorite engineering units, then that’s fine ... as long as you realize that you’re not really improving the operation of the PID ... but IF (another big IF) you’re trying to “slice the signal” into finer steps to improve the operation of the PID, then the “floating point” hoops that you’re (apparently) jumping through are probably more trouble than they’re worth ...



in the final analysis, the PID you’re working with isn’t likely to give you any better control by using those floating point values ... it was designed to work with 0 to 4095 input signals ... and that’s usually enough resolution for the types of processes that PLCs control ...



so getting back to that quote above - and making some assumptions (gosh I hate that word) ... it looks like you’ve done some type of math operation to “scale” the raw (0 to 4095 integer) input signal into a floating point value (0.0 to 100.0) somewhere along the line - and that you are (or might be?) trying to apply that value into your PID ...



then again, I might have completely misunderstood what you were asking ... if so, I apologize - and feel free to simply ignore this post ...



finally, if you can give us more details or (MUCH better yet) post your .RSP program file, then we can give you more detailed information about how to proceed ...



good luck with your project ...

Changing to the PD file block doesn't automatically make everything else floats. The PID instruction input parameters for Process Variable, Tieback, and output parameter for Control Variable are still integers and if you put a floating point address in there you will get the Invalid Data type error message.




They are integers because ultimately they are going to come from a IO point or go to an IO point.

Some of the elements inside the PD control block itself are floating point numbers, including the Setpoint. You could write a floating point number to the setpoint at PD13:0.SP shown here.





To use a setpoint in engineering units, like 0 to 100% like you indicated, you need to configure the PID to scale the unscaled process variable input. From the PID configuraiton screen you have to tell the instruction how to scale the Process Variable input parameter to the instruction.






After you do that the raw process variable is scaled by the PID instruction and the value is written to PD13:0.PV. Set up as shown, N7:0 would have the process variablbe ranged from 0 to 4095 in it. The PID setpoint is a float ragned from 0 to 100 and the PD13:0.PV is the process variable scaled by the PID instructin from 0 to 100 as a float.

Looking back over your post this seems to be the point of confusion. This is NOT the Process variable input to the PID. This is a read output word that contains the scaled value of process variable received from the input parameter (N7:0 in the picture at the top of this post). Your HMI could address this word to show the actual process variable scaled into meaninful units for an operator.







As my esteeemed collegue Ron has already explained, none of this improves the precision of the PID instruction but all of those floating point operations take a lot longer for the CPU to perform than integer operations do.

Thanks for the information it was most helpful.
My PV comes from a already scalled integer into floating point for % Motor loading from a few roller mill motors.

It would have been a good thing if I could have just inserted those floating point valves directly into the PID block however as it may seam the have to be inputed into the block as integer.

The PV for the PID is actually selected based upon the settings of the roller mills for a particular product to control the feeder into the rolls. The operator requires % LOADING so I scaled all the valves into float.

So for the PID I would just have to use the RAW data integer 12bit. And Yes I know that using floating point does not increase resolution I just used it for the ease of the decimal point.

You aren't limited to 12 bit. That's only because some of the IO modules use 12 bit A/D converters. You can actually use a full 16 bits. Or if you want to scale 100% into 10000 (two infered decimal places) and scale your setpoint accordingly and then don't define any engineering units in your PID configuraiton you can do that too.