SCP for Logix 5000

[AMarks95]

The annoyance is when I have 50+ SCPs that now take up a ridiculous amount of space in my Controller Tags window, which makes it more difficult to find the important tags. This wasn't an issue with 500 because I didn't need an instance for each one.

 

[Operaghost]

The SCP in the SLC 500 didn't require a control/instance tag, but in the 5000, because it is an AOI and not a baked-in instruction, it requires a control/instance tag. OK, I get that. To be fair, that would be pretty low on my list of annoyances, particularly when I could create an array so they aren't all cluttering up my tag window.

OG

 

[drbitboy]

An SCP requires two or fewer temporary tags and no persistent (static) tags: The scaling parameters (min/max in/out) and the input value are all inputs; the result is an output; all are specific to each instance.

That being the case, does it still require multiple instances to be deployed in multiple places?

I am asking from ignorance e.g. FFLs and FFUs can (and indeed have to) use the same Control structure; I would expect multiple CTUs could use the same Counter structure, though it would require some fiddling with the .EN bit.

One could also implement SCP as a CPT instruction and skip the AOI route altogether.

 

[AMarks95]

That's a great question. Would have to do some testing to verify, but since the AOI logic is called with the parameters each time the AOI is used, I would imagine that if you used the same SCP instance multiple times with a different output address, it should still work.

 

[nyanpasu]

That's usually how I do it when I do 500 conversions. I instantiate a single scaling/SCP AOI and use it throughout the program to mimic the SCP instruction.

It's just a repeated AOI call with different arguments. It's not too different from repeatedly calling the same subroutine with different I/O parameters.

I call it repeatedly because I think it's clearer, but another way I've seen it done is to use an index to scroll through sets of inputs, parameters and outputs on the same scaling instruction (using say a scaling I/O UDT).

I think any time you tell yourself "I wish Rockwell had functions" you can probably do this instead. You still need to instantiate once but it's better than the alternative of having dozens of instantiated AOIs.

 

[cruzc]

How'd you do the math?

Do the math..

(((Scaled Max-Scaled Min)/(Max Raw Input-Min Raw Input))*(Raw Input-Min Raw Input))+Scaled Min = Scaled Value

I am new to plc programming and I don't understand scp that well. If you could explain how you got that formula I would appreciate it.

 

[plvlce]

I am new to plc programming and I don't understand scp that well.

As Mickey notes, this is just math. It is a standard formala for rate conversions, not in any way specific to PLCs. You can use it for anything from degrees Celsius to Fahrenheit or miles to kilometers or anything else.

It is the same as the basic rate conversion (Scaled Max - Scaled Min)/(Max Raw Input - Min Raw Input) = (Scaled Value - Scaled Min)/(Raw Input - Min Raw Input).

Essentially, if you know two points of a line, then given the x-coordinate of any point on the line you can calculate the y-coordinate of that point. The points (Max Raw, Max Scaled) and (Min Raw, Min Scaled) can generally be expected to be known from documentation and suffice.

 

[drbitboy]

I am new to plc programming and I don't understand scp that well. If you could explain how you got that formula I would appreciate it.

An SCP instruction models a linear relationship between two numerical quantities' values, which values typically have different units.

TL;DR

Expanding on what @plvlce wrote, do you understand what a "linear" numerical relationship is?

E.g. the relationship between °F and °C is linear:

• a temperature of 32°F is the same as a temperature of 0°C*
• a temperature of 212°F is the same as a temperature of 100°C**

A linear relationship between the °F and °C temperature scales means that halfway (122°F), or a third of the way (92°F), or 200% of the way (392°F), from the lower 32°F to the higher 212°F temperatures of those two points on the Fahrenheit scale are the same temperatures as halfway (50°), or a third of the way (33°C+), or 200% of the way (200°C), respectively, from the lower 0°C to the higher 100°C temperatures of those two points on the Celsius scale.

Actually, that is a circular explanation, because if you understand what "halfway," "a third of the way," "or 200% of the way" mean, then you already understand linear numerical relationships, even if the term "linear" is foreign to you.


* the freezing point of water under certain conditions
** the boiling point of water under certain conditions (e.g. 1atm absolute pressure)

 

[drbitboy]

if you use the [Search the forum using Google] widget above using the terms "multiply by unity" you will get a few hits where a linear model is explained in some detail e.g. see here.

 

[mylespetro]

I am new to plc programming and I don't understand scp that well. If you could explain how you got that formula I would appreciate it.

To put this equation in terms that most people should understand, this is y=mx+b, where y is your scaled value, m is your slope (seen here as [scaled max-scaled min] / [raw max - raw min]), x is your current raw input data, and b is your y intercept, which should be -1/4 of your scaled range (NOT of your scaled max - for example if your scaled min/max was 20-100 instead of 0-100, your b value would be (-1/4)*(80)=-20).

So say you have a desired scaled range of 0-100 and your raw data min/max is 4000 for 4mA and 20000 for 20mA, you would have a b term of -25. Using this, we can solve the equation as follows if you're reading 12000 (12mA or 50%) in raw data:

y = mx + b
y = [(100 - 0) / (20000 - 4000)] * (12000) + (-25)
y = [100 / 16000] * (12000) - 25
y = 0.00625 * 12000 - 25
y = 75 - 25
y = 50

Your scaled min/max and raw data min/max will change between applications and PLC platforms, but you can just plug any of those numbers in there and it'll scale it correctly.

 

[JeremyM]

An SCP requires two or fewer temporary tags and no persistent (static) tags: The scaling parameters (min/max in/out) and the input value are all inputs; the result is an output; all are specific to each instance.

That being the case, does it still require multiple instances to be deployed in multiple places?

I am asking from ignorance e.g. FFLs and FFUs can (and indeed have to) use the same Control structure; I would expect multiple CTUs could use the same Counter structure, though it would require some fiddling with the .EN bit.

One could also implement SCP as a CPT instruction and skip the AOI route altogether.

That's a great question. Would have to do some testing to verify, but since the AOI logic is called with the parameters each time the AOI is used, I would imagine that if you used the same SCP instance multiple times with a different output address, it should still work.

The only potential (and real) problem is if the instance is shared across tasks. It becomes a race condition.

You could instantiate a single instance per program, name it the same as every other instance, and never worry about it.

 

[ndzied1]

I'm not an AB guy any more, that was long ago, but in IEC61131 systems you should be able to create a "FUNCTION" that is not a "FUNCTION BLOCK"

There is no reason SCP needs to be a FUNCTION BLOCK. It does not need to retain any data across calls. It is evaluated every time you call it with the parameters you send it.

In this way, there is only one definition of the FUNCTION and you just call it wherever you need it.

NO INSTANTIATION REQUIRED for a FUNCTION.

===========
After a cursory search of Rockwell docs available online it looks like they may not have implemented regular Functions, only Function Blocks.... But again, hopefully a Rockwell expert will chime in here...
===========

 

[JeremyM]

You are correct. The only functions available are the built-in ones.

Add-on instructions are function blocks by another name.

If, or when, Rockwell decides to implement IEC-61131 classes, that may change to open up the possibility of doing stuff like calling free functions from classes and more broadly being able to build frameworks and such.

 

[ndzied1]

You are correct. The only functions available are the built-in ones.

Add-on instructions are function blocks by another name.

Wow, seems short sighted. Seems like functions would be easier to implement than function blocks. Wonder why they made that decision?

 

[JeremyM]

The need for overloading would be my first guess. I don’t agree with it being a reason to hold out on the feature. If engineers are eager to learn and build interesting stuff, let them. For everyone else, the baked-in functions should suffice.

MOV, for example, is actually several distinct functions that are called depending on the types of parameters passed.

There’s code behind each of these that behave in different ways:
MOV(REAL, REAL);
MOV(INT literal, DINT);
MOV(DINT, SINT);
MOV(DINT, DINT);

… and so on. It’s also why MOV(BOOL, DINT) isn’t a thing - it just wasn’t defined. Could someone overload it to provide a working form? Sure.

What we have to settle for are creating or encountering AOIs like “DINT_to_REAL(…)” and on and on.

If one were to write their own version of ADD(), they’d have a bit of work ahead of them to handle type combinations, testing, etc. They would however also be to do neat stuff like ADD(UDT1, UDT1).

But then you’ve got the modern hotshot C++ programmer that wants to template every little thing and then they’d suddenly want template support for every little thing in Logix. I say that as a C++ engineer wanting more language features in Logix.