Really struggling understanding some Rockwell Automation programming instructions.

Cydog

Member
Join Date
Feb 2018
Location
Maryland
Posts
313
Good Morning ,

I've taken on a job that is truly over my head with a engineering group. The standards of Rockwell programming is much more detailed than I have ever been exposed to before. I'm 58 , and for 32 years I have programmed Rockwell PLC's the way that i felt was best understood by me , and could be understood by others , especially younger maintenance technicians . I truly understand the purpose for this higher level , but I'm struggling and at my age , I'm scared LOL. I gave up a great position , to pursue an opportunity to help manufacturing and for the love of manufacturing.

Below is a list of instructions that I would like understand the "real world" uses for . Still struggling with UDT's and AOI's , also . I have been watching some YouTube videos , and they have helped .

SIZE instruction - Why would you use this instruction ?

CPS - I understand this is somewhat of a copy instruction , but what is the
difference in simple terms , and what situations would you use this ?

STOD - I understand this is a String to Dint instruction. How would the DINT
be represented , after conversion ?

GSV - What is the purpose of this instruction , and why would this be used ?

Thanks so much always for your help.,

Sleepless in Maryland , LOL.
 
Ron's answers will be better, but here is a quick summary; some of it may even be correct ;).

SIZE - you mention struggling with AOIs; let me try to ignore the details, while saying that an AOI can be a user-defined instruction. That is, it's a self-contained chunk of code that can be used multiple times in a program, with different set of inputs each time. So the same way you use an ADD instruction on say two INTs to assign a value, the inputs' sum, to an output, you can write an AOI to perform arbitrary, but user-defined, operations on inputs and write results to outputs. For example, say you wanted the average of all the values in an array. I expect you could write self-contained code, i.e. an AOI, that, given a one-hundred element array as the first and only input, would sum those 100 elements of the input array, then divide that sum by 100 to calculate the average and write that average to an output. But what if later you had to average the values in a fifty-element array? You would have to write a second AOI, with essentially identical code to the first AOI, but that second AOI would use 50 as the number to step through the array and as the divisor at the end. Instead of writing two AOIs, the SIZE instruction allows you to write only one generic AOI that does not "know" a priori the number of elements in its input array. That generic AOI would use the SIZE instruction to determine, **INSIDE** each "instance" (occurrence) of the AOI, the number of elements in the array input for that instance, which number the PLC "knows" because that number is declared as part of each array tag declaration e.g. temperatures[100] or flows[50].
 
CPS vs. COP - at the lowest level, they both copy bits from one source memory location to another destination memory location. However, with COP it is possible for a higher priority task, e.g. a periodic task or an I/O scan, to interrupt the COP while it has copied some, but not all of the data from the source location, and overwrite the source data with different data. Then, at the end of the interrupt, control is returned to the COP, which does not know that the source data have changed, and copies the rest of the source location data to the destination location, even though the data copied from before the interrupt may be inconsistent with the data copied after. The CPS does the same transfer but cannot be interrupted, so the data copied to the destination is always self-consistent.

E.g. say there are two 16-bit INTs coming from a MODBUS transfer that contain the bits for one 32-bit DINT. Say the initial value of the DINT is 65535 i.e. 0000FFFFh, so the first INT is FFFFh and the second is 0000h. The COP copies the FFFFh to the lower half of the target DINT, and is interrupted by a periodic task that happens to detect that next MODBUS transfer has completed with a DINT value of 65536 I.e. 00010000h, so now the first INT is 0000h and the second INT is 0001h. The interrupt ends and the COP instruction finishes by copying the second INT, now 0001h, to the upper half of the DINT, which now contains 0001FFFFH or 131071 decimal instead of 65535 or 65536.
 
STOD - the DINT will be the binary representation of the ASCII decimal representation, i.e. as if you keyed in the same decimal digits in the tag list for the DINT's value.

So a string "324" as the STOD input would put a value into the DINT of decimal 324 =144h = (1x256 + 4x16 + 4x1)
 
STOD:

"

The RSLogix5000 help file will answer your last question:

The STOD instruction converts the Source to an integer and places the result in the Destination.

§ The instruction converts positive and negative numbers.

§ If the Source string contains non-numeric characters, the STOD converts the first set of contiguous numbers:

The instruction skips any initial control or non-numeric characters (except the minus sign in front of a number).
If the string contains multiple groups of numbers that are separated by delimiters (e.g., /), the instruction converts only the first group of numbers."

I found it in an old post.
 
GSV - this instruction provides an interface to system functions. System functions are independent of, and external to, any user-defined program and the process being controlled and monitored. The most common system function is probably the real time clock. For example, the program might save the accumulated product for the past week to a register for hmi or scada to check, and reset the accumulator, on Mondays at 4am. Or the process might be put into a special mode near shift changes. Detecting those events, which are based on clock time and not on the process, requires access to the system's "wall clock" object, which is accessed via the GSV instruction.
 
UDT are indispensable for a well structured program.
User Defined Datatype, where you can group datatypes together in one structure to re-use.
For example:
UdtMotor:
Motor_ID :Int
RPM: Int
Current_Rating: Real
Enabled: Bool

You would then have an array of udtMotors and use the as udtMotors[index].Motor_ID

I don't know about RSlogix but other platforms allow UDTs within UDT:

UdtMotor_Config:
Motor_ID: Int
Enabled: Bool
RPM: Int

UdtMotor_Status:
IsRuning:Bool
IsFaulted:Bool
RPM:Int

udtMotor_Control
Start:Bool
Speed:Int

And group all three UDTs in one:

udtMotor:
Config:udtMotor_Config
Status:udtMotor_Status
Control:udtMotor_Control

And an array of udtMotors would be addressed as:
udtMotors[index].Config.Motor_ID
 
Thanks so much for your help. My goodness , if I was 20-30 years old again what a career I would of had :). You guys have a good , and safe week.
 
You've already got some great answers, but let me throw in one more about why you might use SIZE.

Let's say you have an array of some sort.

Maybe it's an array of 30 recipes.
Maybe it's an array of the last 20 test results.
Maybe it's an array of pressure readings over the last 10 seconds.

And now, let's say you're going to search your array of recipes for one called "WidgetTypeC", so you can load it for production.
Or maybe you're going to count the number of failed tests in the last 20, and if there have been more than 5, shut the line down.
Or maybe you're going to average the last 10 seconds worth of pressure readings to display a stabilised reading on an OIT.

Maybe you'll use an FSC instruction to find your recipe.
Or a loop with indirect addressing to count the number of faults.
Or an AVE instruction to average your pressure readings.

A common feature of all these things is that if you inadvertently tell the FSC or the indirect addressing or the AVE instruction to look at an array element that doesn't exist, your processor will immediately crash.

So, obviously, you don't do that. You hard code your array size, and move on with your life.

But then the R&D guys come along and tell you they've developed a whizz-bang new recipe, but there are no more slots for it in your array.
Or your QC manager comes along and says that now they want to monitor the last 50 faults.
Or the operators complain that the pressure reading is too filtered, and can they just get a 5 second average instead of a 10 second?

So now, the size of your array is changing. Easy. Change the size of your array, download to the PLC, and go for lunch. And then, just as the microwave goes "ding!" your phone rings, because the PLC has crashed and the plant floor is in chaos. Looks like you missed somewhere that you had hardcoded your array size, and it went past the end of the array and crashed your PLC.

In order to prevent your enchilada from having to be reheated (and they're never as good reheated), you can instead use the SIZE instruction to set up your FSC instruction, or your AVE instruction, or to limit your indirect addressing. I do this every single time I tell any sort of instruction to do anything to an array. Run a SIZE instruction against the array, and send the result to the FSC.LEN tag. I can change the array as much as I want, and I never have to think about whether there's anything else I need to change - it'll pick up the change automatically.
 
Add on instructions can be viewed like a prepackaged subroutine. You define all the inputs/info from the user you need, you process that info, and then you have defined outputs that the user can use. Its useful for saving lines of ladder that may be used multiple times. Say you needed to calculate the FPM of an object based on a sensor triggering and a motors rpm and sprocket size or something. You could make an AOI and put all the logic in there, then whenever you needed that logic in the future you just drop in the AOI into your rung and give it the parameters that are predefined to spit out your calculation to the defined output parameter.
 
Add on instructions can be viewed like a prepackaged subroutine. You define all the inputs/info from the user you need, you process that info, and then you have defined outputs that the user can use. Its useful for saving lines of ladder that may be used multiple times. Say you needed to calculate the FPM of an object based on a sensor triggering and a motors rpm and sprocket size or something. You could make an AOI and put all the logic in there, then whenever you needed that logic in the future you just drop in the AOI into your rung and give it the parameters that are predefined to spit out your calculation to the defined output parameter.


I would add that the AOI can do everything that a regular subroutine can do, but it also has local variables that are only used by that AOI. And it is also a UDT, so it can store information for the equipment.


The AOI does not access global array tags well. And you cannot - yet at least - edit an AOI on a running PLC. So you change the AOI offline then load the program into the PLC.


If you are not using a continuous process, AOI is the way to go. I use subroutines since stopping the process on purpose happens for 1 week per year.
 
You've already got some great answers, but let me throw in one more about why you might use SIZE.

Let's say you have an array of some sort.

Maybe it's an array of 30 recipes.
Maybe it's an array of the last 20 test results.
Maybe it's an array of pressure readings over the last 10 seconds.

And now, let's say you're going to search your array of recipes for one called "WidgetTypeC", so you can load it for production.
Or maybe you're going to count the number of failed tests in the last 20, and if there have been more than 5, shut the line down.
Or maybe you're going to average the last 10 seconds worth of pressure readings to display a stabilised reading on an OIT.

Maybe you'll use an FSC instruction to find your recipe.
Or a loop with indirect addressing to count the number of faults.
Or an AVE instruction to average your pressure readings.

A common feature of all these things is that if you inadvertently tell the FSC or the indirect addressing or the AVE instruction to look at an array element that doesn't exist, your processor will immediately crash.

So, obviously, you don't do that. You hard code your array size, and move on with your life.

But then the R&D guys come along and tell you they've developed a whizz-bang new recipe, but there are no more slots for it in your array.
Or your QC manager comes along and says that now they want to monitor the last 50 faults.
Or the operators complain that the pressure reading is too filtered, and can they just get a 5 second average instead of a 10 second?

So now, the size of your array is changing. Easy. Change the size of your array, download to the PLC, and go for lunch. And then, just as the microwave goes "ding!" your phone rings, because the PLC has crashed and the plant floor is in chaos. Looks like you missed somewhere that you had hardcoded your array size, and it went past the end of the array and crashed your PLC.

In order to prevent your enchilada from having to be reheated (and they're never as good reheated), you can instead use the SIZE instruction to set up your FSC instruction, or your AVE instruction, or to limit your indirect addressing. I do this every single time I tell any sort of instruction to do anything to an array. Run a SIZE instruction against the array, and send the result to the FSC.LEN tag. I can change the array as much as I want, and I never have to think about whether there's anything else I need to change - it'll pick up the change automatically.
Hi. Do you have an example of this or know of where I can find examples of the SIZE instruction? Thank you in advance.
 
Last edited:

Similar Topics

Local Rockwell distributor was in today. He says that the MicroLogix 1400 will likely be unavailable to purchase sometime around the end of this...
Replies
58
Views
16,409
I’ve been looking at buying a quantity of signal converters to take a type J or k thermocouple or RTD and convert it to a 4-20mA signal. In...
Replies
10
Views
2,959
Doing some consulting work using factorytalk view studio and RSLogix5000. We set up alarms for the system a while ago and they work fine, as do...
Replies
5
Views
3,566
I spent the entire day trying and failing to setup my 1783-NATR. It appeared, time and again, to be correct and happy but no matter what I did...
Replies
11
Views
4,930
Hello guys, 200 hp air compressure motor winding fail but over load really was not trip.Motor rated current 288 amps and over load setting is...
Replies
15
Views
7,443
Back
Top Bottom