Modicon M221 function scaling

[Bennyboi]

Hi all,

i am trying to scale a 0 - 1000 analogue input to a -10000 to 10000 output with
0-500 been -10000 to 0 and 501-1000 to 0-1000 is there a simple way of doing this?

ideally want a single 10k Pot on the input, then the output is to a DC Drive, -10000 to 0 is backwards and 0 to 10000 is forwards.

thanks in advanced.
Ben.

 

[Lare]

0 *20 - 10000 = -10000
1000*20 - 10000 = 10000

 

[Bennyboi]

0 *20 - 10000 = -10000
1000*20 - 10000 = 10000

Thanks, i was trying to over complicate things.

 

[Lare]

Thanks, i was trying to over complicate things.

Linear scaling is allways equation y= mx + b. Now m and b are easy to calculate and reals or double integer isn't needed as if numbers would be fractionals or bigger.



If you have additional analog card, then you can scale to -10000..10000 on card settings.


I assume that you usePLC inbuild analogs as range is 0..1000.

 

[ganutenator]

My two cents:
I used to love the scp function when I used rs logix.
Unfort., none of the other software that I have used have this function block built in.
So, I rolled my own using the Allen Bradley help file from the RsLogix.

In the help for the scaling block function (not the scp one) it showed the formula.
While yes, it is simply y= mx + b, it is amazing how many engineers I have seen write code for this that fails when calculating m (rate). (I forget, but I think it was when the input raw was negative or the min was larger than the max. I forget).

 

[Corsair]

Watch the data types! (again)

When doing this sort of work you need to know what data types you are working with and their allowable ranges.

In this case things appear to be OK since 20 * 1000 gives you 20000 which is in the -32768 to +32767 range of a 16-bit signed integer.

In other cases Y=MX+B can get you in trouble. The X and Y may fit into the integer but the intermediate result (MX) may overflow. The programmer needs to know how (or if) the PLC can handle that. Some PLCs may convert everything 'inside' the equation to floating-point ('reals'), do the math, and then do round-off to get the integer result.

With some PLCs you have to specify the data types for all math so you may need to convert the inputs to reals or double integers. This takes more code but it gives you more control over what the PLC is doing.

Those of us with long memories remember how challenging it was to get an integer remainder from an integer division in a AB PLC-5. Or the Square D Model 300 which may have been the first machine to allow expression editing similar to the Allen Bradley CPT instruction - except the math blew up if intermediate results went over 32767. They took care of that in their later Model 400 CPUs.

A modern temptation is to dismiss all this as old-man rambling and just do everything in floating point. That's OK most of the time - until you start doing EQU and NEQ comparisons or some other things.

The point of this sermon (or rant if you see it that way) is that some thought needs to be given to what is going on in the PLCs head before doing math in it. Be aware of the size limitations of each datatype that you are using.

I've mentioned before on this forum a couple of examples of botched numeric programming. Search the internet for them. There was the French rocket that blew up 47 seconds after it left the ground - trying to overflow a signed 16-bit register. And the patriot missile that missed the SCUD and several people killed - using floating point for a totalization that should have been done with a long integer.

As a profession - and for our customers - we need to do due diligence when programming math.

 

[Corsair]

Failsafe

If the power supply to your potentiometer goes dead will the drive go full speed reverse? If your pot gets some dirt under the wiper will the same thing happen?

 

[ganutenator]

When doing this sort of work you need to know what data types you are working with and their allowable ranges.

In this case things appear to be OK since 20 * 1000 gives you 20000 which is in the -32768 to +32767 range of a 16-bit signed integer.

In other cases Y=MX+B can get you in trouble. The X and Y may fit into the integer but the intermediate result (MX) may overflow. The programmer needs to know how (or if) the PLC can handle that. Some PLCs may convert everything 'inside' the equation to floating-point ('reals'), do the math, and then do round-off to get the integer result.

With some PLCs you have to specify the data types for all math so you may need to convert the inputs to reals or double integers. This takes more code but it gives you more control over what the PLC is doing.

Those of us with long memories remember how challenging it was to get an integer remainder from an integer division in a AB PLC-5. Or the Square D Model 300 which may have been the first machine to allow expression editing similar to the Allen Bradley CPT instruction - except the math blew up if intermediate results went over 32767. They took care of that in their later Model 400 CPUs.

A modern temptation is to dismiss all this as old-man rambling and just do everything in floating point. That's OK most of the time - until you start doing EQU and NEQ comparisons or some other things.

The point of this sermon (or rant if you see it that way) is that some thought needs to be given to what is going on in the PLCs head before doing math in it. Be aware of the size limitations of each datatype that you are using.

I've mentioned before on this forum a couple of examples of botched numeric programming. Search the internet for them. There was the French rocket that blew up 47 seconds after it left the ground - trying to overflow a signed 16-bit register. And the patriot missile that missed the SCUD and several people killed - using floating point for a totalization that should have been done with a long integer.

As a profession - and for our customers - we need to do due diligence when programming math.

I think this comment might have just unzipped a .PTSD file in me head. lol