PLC 5 Scaling raw to Engineering units

[chelton]

No-no, limit the HMI to doing what it MUST do. PLCs are much faster than HMI's, and what if another system needs to read the data ?

PLC's are designed to run code deterministically a PLC does not care about engineering units. Conversions and math add time to the processing time.
PLC's have become much faster and have more memory to allow this to be done in the PLC. It makes for easier understanding while looking at the program, but actually doesn't have any effect on the operation.

HMI's should be a window into the PLC, not an interpretation of the data therein
just 2c from me

HMI's on the other hand are designed to present the PLC data in a human readable format.
If you scale in a PLC5, most likely you are going to scale to a floating point number ( 32 Bit ) otherwise you would be scaling to another Integer, either loosing precision or scaling to a value that would require scaling in the HMI anyway.
If you scaled to a floating point value you have doubled the number of bytes that need to be transmitted to the HMI for what benefit? To make the PLC code more readable? Who is going to see this? The End user won't.

 

[EICS]

Since there is a HMI attached do you really need to scale in the PLC?
why not work with RAW data in the PLC and use the HMI to do the scaling?

Hi Chelton,


i do have a HMI on the system but i need to drive this "Scaled" value into an Analog output module for an I/P converter for some process control.

 

[robertmee]

PLC's are designed to run code deterministically a PLC does not care about engineering units. Conversions and math add time to the processing time.
PLC's have become much faster and have more memory to allow this to be done in the PLC. It makes for easier understanding while looking at the program, but actually doesn't have any effect on the operation.


HMI's on the other hand are designed to present the PLC data in a human readable format.
If you scale in a PLC5, most likely you are going to scale to a floating point number ( 32 Bit ) otherwise you would be scaling to another Integer, either loosing precision or scaling to a value that would require scaling in the HMI anyway.
If you scaled to a floating point value you have doubled the number of bytes that need to be transmitted to the HMI for what benefit? To make the PLC code more readable? Who is going to see this? The End user won't.

Going to agree with Daba and here is why. Rarely unless a very simple application, is the data used in simply displaying to an HMI. Usually, there are alarm limits, setpoints, comparative operations, other data math and manipulations that rely on an Analog Input. It is much easier and more straightforward to scale once to EU and then use EU's in the PLC everywhere applicable. As an example, let's say the raw value is 0 to 16384 to represent 0 to 100% level. It's much better to scale that once, and then have alarm limits or setpoints relative to that entered in the HMI as the same units. Otherwise, you scale 0 to 16384 as 0 to 100% at the HMI level, and now you want to add a refill setpoint. So you scale that 0 to 16384 also. But now in the PLC code you're dealing with raw values. I can't tell how many times I find logic that says level is > 8192 do something. That's worthless from a troubleshooting point of view as now I have to dig through the analog scaling math to find out what 8192 really represents. Much better to have level > 50% in the PLC logic.

 

[chelton]

I did mention in my post that PLC's have become much faster that allows this to be done in the PLC, and I do this also.
The OP was talking about PLC5's and high speed machine. In PLC5's scan time was in ms not µs like modern plc's. So in high speed machines you tried to limit the math / cpt instructions to keep scan time as quick as possible. With PLC5's prior to the enhanced you were limited to DH+ or DF1, in large facilities you were limited to 57k baud rate, it didn't take to many devices to have a big impact on speed.

 

[daba]

Going to agree with Daba and here is why. Rarely unless a very simple application, is the data used in simply displaying to an HMI. Usually, there are alarm limits, setpoints, comparative operations, other data math and manipulations that rely on an Analog Input. It is much easier and more straightforward to scale once to EU and then use EU's in the PLC everywhere applicable. As an example, let's say the raw value is 0 to 16384 to represent 0 to 100% level. It's much better to scale that once, and then have alarm limits or setpoints relative to that entered in the HMI as the same units. Otherwise, you scale 0 to 16384 as 0 to 100% at the HMI level, and now you want to add a refill setpoint. So you scale that 0 to 16384 also. But now in the PLC code you're dealing with raw values. I can't tell how many times I find logic that says level is > 8192 do something. That's worthless from a troubleshooting point of view as now I have to dig through the analog scaling math to find out what 8192 really represents. Much better to have level > 50% in the PLC logic.

You have hit the nail squarely on the head, getting input data into "human understandable" units as soon as possible just makes everything you do with that data so much clearer and understandable to anyone reading the code. Documenting the code becomes less important (if that is possible) so long as you have converted everything into, and from "Engineering Units". every GRT, every LES, and the numerical operands they entail, speak for themselves.

Life is so much easier when you do everything in your code in engineering units.

"Everything you see should relate to the application, not the constraints of the hardware". Dunno who said that, perhaps I can claim it as my own....

All hail the Logix5000 analog I/O modules that can do this for you, delivering (AI) data in floating-point format to your tags, or accepting (AO) your drive speed setpoint in ft/min or whatever units you use, to the analog output signal that controls the speed. True multiprocessing.....