ControlLogix (RSLogix 5000): 'Junk' Values In Memory

Join Date
Dec 2016
Location
Southeast
Posts
134
... more PLC101 questions for you experience Ladder lovers:

Do these PLCs boot up with junk values in memory, and if so how do you typically clear out, say, an array? When I search the Instruction Manual for "loop" all I see is the FOR block for ladder, but that calls a routine repeatedly. For Structured Text, I see the more familiar constructs like FOR-DO, WHILE, REPEAT, etc, but this is an existing ladder program.

Is there any way in ladder to just loop through an array to clear it *without* using the FOR block to repeatedly call another routine?
 
No they do not. Junk came from somewhere. Most likely from program downloaded into processor but also possible from networked devices sending data to processor.
 
I have seen this "junk" on one occasion. I was never able to figure out the source of it, but my guess was WonderWare or a C-More panel because those were the external devices writing data into these tags.
 
When you first create a new array tag, it is possible that there will be junk in them. I saw this when creating a data for a sequencer and had to go in and poke my own junk in there. That was a long time ago (version 12 IIRC). I believe it was due to the PLC simply pointing the new tag to an area of memory that had previously been in use and still contained stale data.

In ladder, you can FLL a file with data and the source can be a constant or a tag value not necessarily equal to zero. The FLL (Fill File) instruction will execute in its entirety in a single scan and you set the length to the number of elements you want filled.
 
Last edited:
Do these PLCs boot up with junk values in memory?

Can't say for all, but generally, No. They boot up with the values that they had when they shut down, or they boot up with zeros if they lost memory.

and if so how do you typically clear out, say, an array?
Don't know about your PLC, but for ControlLogix, use COP or CPS.

When I search the Instruction Manual for "loop" all I see is the FOR block for ladder, but that calls a routine repeatedly.

You are asking a question specific the PLC you are using, but you haven't specified that PLC.

Is there any way in ladder to just loop through an array to clear it *without* using the FOR block to repeatedly call another routine?


In all the years that I have programmed, the only PLC code I have ever written with a FOR block was a test program. While there are instances where the For blocks are appropriate, they are seldom needed.

** A PLC program runs in a continuous loop! **

This is a fundamental principle you need to understand. In most programming languages, FOR loops are used to loop and count. But since the PLC code runs in a continuous loop, the looping is automatic. So when incrementing through an array, the code doesn't need to loop, it only needs to count. A COUNTER is used to count (or its done with ADDs).

Also, if you goal is to 'clear' the array, you don't need to loop through it. Just copy zero's to the array. Many PLC's have an instruction that does this.
 
Can't say for all, but generally, No. They boot up with the values that they had when they shut down, or they boot up with zeros if they lost memory.

How are you defining "shut down"? And how do you define "lost memory"? When a PLC is downloaded, the program gets written to a ROM, doesn't it? And then it gets automatically loaded into memory, no? I say this because I've found if you cycle power on a PLC, you don't have to reload it. It reloads from its on-board copy (as if it had a hard disk, but it doesn't). So, in my case, I don't know where these junk values are coming from. If the array is preset to all zeros in the app, *that's* what should be loaded into memory - regardless of *where* it gets loaded into memory (I would think).

But like I said - I'm a PLC novice. I've done quite a bit of DCS programming (which was *very* different than these PLCs), but I consider my *real* software work to be my experience with real-time military applications: mega-machines running multiple CPUs, multiple IOCs, hundreds of task level modules, in a multi-threaded environment with messaging, time-dependent, interrupt, and background thread capability. *Those* applications were very complicated, with about 100 people working on them doing software design, system test, system integration, specialized debug, etc. Really interesting stuff. These PLCs are kind of a micro version of that, but much simpler.

But I *still* need to understand how they work in order to write the best applications I can.

Don't know about your PLC, but for ControlLogix, use COP or CPS.

You are asking a question specific the PLC you are using, but you haven't specified that PLC.

My PLC type is in the title of my post. Do you need an actual *model* number? I thought "ControlLogix" was sufficient.

In all the years that I have programmed, the only PLC code I have ever written with a FOR block was a test program. While there are instances where the For blocks are appropriate, they are seldom needed.

** A PLC program runs in a continuous loop! **

This is a fundamental principle you need to understand. In most programming languages, FOR loops are used to loop and count. But since the PLC code runs in a continuous loop, the looping is automatic. So when incrementing through an array, the code doesn't need to loop, it only needs to count. A COUNTER is used to count (or its done with ADDs).

But if you do it the way you've described, you are constrained by the periodicity of your task. Let's say your task runs at 250 ms and you have to loop through 1000 array elements. You'd have to wait 250 seconds (over 4 minutes) to loop through your array! I don't see anything wrong with running a loop within a scan, as long as you don't MAX TIME your thread execution. With those military applications I mentioned above, a task had 25 ms to execute its thread, and if that time was exceeded, the OS would terminate the task and send it a WarmStart message (to re-start). Earlier versions would simply stop the processor, but this wasn't 'fault tolerant'.

What happens in a PLC when you exceed the MAX TIME for your thread execution? Does the PLC come to a screeching halt?

Also, if you goal is to 'clear' the array, you don't need to loop through it. Just copy zero's to the array. Many PLC's have an instruction that does this.

Looks like I can use a FLL (per OkiePC) or, as you suggested, a COP or CPS.

Thanks for your help!
 
How are you defining "shut down"? And how do you define "lost memory"? When a PLC is downloaded, the program gets written to a ROM, doesn't it? And then it gets automatically loaded into memory, no? I say this because I've found if you cycle power on a PLC, you don't have to reload it. It reloads from its on-board copy (as if it had a hard disk, but it doesn't). So, in my case, I don't know where these junk values are coming from. If the array is preset to all zeros in the app, *that's* what should be loaded into memory - regardless of *where* it gets loaded into memory (I would think).

"Lost Memory" usually occurs on older processors when the PLC is powered down for a long period of time, and the battery is depleted. In that case, program no longer exists, so neither does the array, and so any discussion of the values in it are moot. In modern Compact Logix PLC's there is an energy storage module that holds the power up for long enough to transfer the program - including the values of all tags - into non-volatile memory, so it's really a non-issue. The only other way a program might be lost is in the case of a Major Non-Recoverable Fault (MNRF), which is usually associated with a serious hardware fault. I don't think I've ever seen one.

All compact logix memory is retentive. Whatever values are in your array will stay in your array until modified by either logic, an external device writing to them, or a download that overwrites them. You can switch the PLC from Run to Program, cycle the power, do whatever you like - but the array values will stay the same until one of those things happens.

If you do a download, whatever values are stored in the offline copy of the PLC program will be written into the array. Let's take a simple example of an array with 5 elements. When you create the array for the first time, they'll all be zero, and when you download to the PLC, the array will be created with all it's members zero. Then, you run the code for a while, and your array now has values 1, 2, 3, 4, 5 in it respectively. You make a change to the offline code, download the program to the PLC again, and your array is reset back to all zeroes, as that is what is in the offline code. Now, you run the code for a while, until the values 1, 2, 3, 4, 5 are in your array. Then you go online with the PLC, and press Save. You'll get a dialog box asking if you want to upload all tag values. If you click yes, the values of all tags, including those in your array, are uploaded into the offline file. So now, the array in your offline file has the values 1, 2, 3, 4, 5. Let's say your code runs some more, until the values in the array are 2, 4, 6, 8, 10. But then, you do another download. You will download whatever values are stored in your offline file - 1, 2, 3, 4, 5. So after the PLC goes back to run mode, your array values will once again be 1, 2, 3, 4, 5.

Does that clear that part of it up?

But if you do it the way you've described, you are constrained by the periodicity of your task. Let's say your task runs at 250 ms and you have to loop through 1000 array elements. You'd have to wait 250 seconds (over 4 minutes) to loop through your array! I don't see anything wrong with running a loop within a scan, as long as you don't MAX TIME your thread execution.
Absolutely - there are certainly reasons where you might want to create a loop. In ladder, you use JMP and LBL instructions. Keep in mind though, that there are several instructions you can use that will operate on every element in an array of any size, within one scan, by default. So you may still not need to create a loop, depending on what you're trying to do.

With those military applications I mentioned above, a task had 25 ms to execute its thread, and if that time was exceeded, the OS would terminate the task and send it a WarmStart message (to re-start). Earlier versions would simply stop the processor, but this wasn't 'fault tolerant'. What happens in a PLC when you exceed the MAX TIME for your thread execution? Does the PLC come to a screeching halt?
Yes. Each task has a configurable watchdog timer, which if exceeded, will cause a Major Fault (not MNRF, though), and your PLC will stop executing code.

Looks like I can use a FLL (per OkiePC) or, as you suggested, a COP or CPS.
If you're trying to clear all values to zero, an FLL is a better option, as you can use a constant (i.e. 0) as your source. With a COP, you can't - you'd have to set a tag to 0, and then copy that tag to the rest of the array elements. Which, I mean, you can still do, but FLL is simpler.
 
ASF:

Thank you for your complete response (and clearing that up). It's pretty much what I thought - each download resets the defaults to whatever is in your offline version.

But a few related questions/comments:

1.) I knew you could upload a program, but where is that program stored? Is it a copy *separate* from the one you used to initially connect to the PLC (and perhaps just downloaded)? I would hope so. Is it possible to inadvertently overwrite your saved application with the "new" defaults (from a system run) that way? Seems like if you're not careful you could really hose yourself with that feature.

2.) Thanks for the tip on the single-scan array instructions. Curious, though - how can an array of *any* size be guaranteed to complete in a single scan without causing a MAX TIME fault? Is it possible that you could 'hang' the PLC (without crashing it)? And these instructions implicitly know the size of your array, or you still have to specify that?

3.) Surprised that these newest PLCs (ControlLogix) aren't fault-tolerant. So the PLC simply crashes? That's something I saw back in the late 80's that was corrected shortly afterward. If the PLC is smart enough to see a task has overrun its execution time, you'd think it'd be smart enough to tell the offending task so it could correct itself. Can you write some kind of exception routine to prevent the hard stop?

4.) FLL *does* sound cleaner than COP (it saves a tag), but I assume that tag you'd use for the COP would still be a 'constant' (so it couldn't be overwritten).

Speaking of overwriting memory, how much memory protection do these things have? Is it possible to overwrite any part of memory ... your tags, maybe even your instruction segment with a rogue index? How is the program and its data stored in the PLC's memory.

Back to the military systems ... a module had an instruction segment and a data segment. Each segment had a known length plus associated memory protection. Each segment ran under an associated base register. The two segments could be anywhere in physical memory, depending upon where the OS put them. The instruction segment was write-protected, but the data segment wasn't (of course). You *could* calculate a rogue index or pointer and end up writing all over your data segment!

Are PLCs susceptible to that kind of thing?
 
Last edited:
1.) I knew you could upload a program, but where is that program stored? Is it a copy *separate* from the one you used to initially connect to the PLC (and perhaps just downloaded)? I would hope so. Is it possible to inadvertently overwrite your saved application with the "new" defaults (from a system run) that way? Seems like if you're not careful you could really hose yourself with that feature.
Nope, it just saves the file like a word document or an excel spreadsheet. By default, Logix is configured to also save backups (each time you save the file, it will create a "Filename.Username.BAKnnn.ACD" file, and automatically keeps the last 3 versions (or however many you configure) in the same directory as the main file. I'm not sure why the concern about it though - to me, that's the only way it makes sense. If I've got to make some changes to a running system and need to do a download, I don't want to wipe out 200+ settings. That will take them days to recover from as they try to get everything set up and fine tuned again. I want to go online, save the tag values, make my changes and download with the same settings they are currently using.
If having some "default" values that should never change is important, then I'd be hardcoding those values into the code with a method, available to the operator, of restoring those default values.

2.) Thanks for the tip on the single-scan array instructions. Curious, though - how can an array of *any* size be guaranteed to complete in a single scan without causing a MAX TIME fault? Is it possible that you could 'hang' the PLC (without crashing it)? And these instructions implicitly know the size of your array, or you still have to specify that?
Well, you can't be *guaranteed*, you still have to think about it and plan accordingly. But the watchdog time is typically in the realm of 500ms by default - I don't know what you could possibly be doing to an array to make something take that long. And if you did, the rest of your code is no longer executing for that 500ms, which could have drastic impacts on other processes, so in that case, you'd have to take a step back and ask if perhaps you're trying to undo a hex head bolt with a phillips head screwdriver. Wrong tool for the job. Most instructions you have to specify the length of your array, but if you'd prefer it to automatically detect, you can precede that instruction with a SIZE instruction, which, you guessed it, returns the size of your array. That's what I typically do.

3.) Surprised that these newest PLCs (ControlLogix) aren't fault-tolerant. So the PLC simply crashes? That's something I saw back in the late 80's that was corrected shortly afterward. If the PLC is smart enough to see a task has overrun its execution time, you'd think it'd be smart enough to tell the offending task so it could correct itself. Can you write some kind of exception routine to prevent the hard stop?
No PLC is fault tolerant. When these things are controlling a 30-ton robot, if there's a bug in your code, you sure as hell don't want it to just do the best it can to keep running. You want it to stop, NOW.
Yes, in ControlLogix/CompactLogix you can write a fault handling routine, which executes once under fault conditions, but that's typically just for things like logging the fault code, or perhaps setting some values in an attempt to bring things to a graceful halt rather than just a crash. But your PLC is going to stop, and that's IMHO exactly what should happen.

Speaking of overwriting memory, how much memory protection do these things have? Is it possible to overwrite any part of memory ... your tags, maybe even your instruction segment with a rogue index? How is the program and its data stored in the PLC's memory.

Back to the military systems ... a module had an instruction segment and a data segment. Each segment had a known length plus associated memory protection. Each segment ran under an associated base register. The two segments could be anywhere in physical memory, depending upon where the OS put them. The instruction segment was write-protected, but the data segment wasn't (of course). You *could* calculate a rogue index or pointer and end up writing all over your data segment!

Are PLCs susceptible to that kind of thing?

They are absolutely susceptible. Take the COP instruction, for example. The "length" operand for that instruction is in terms of destination elements. Let's say you want to copy two 16-bit integers into a single 32-bit integer. If you set the length to 1, it will copy 32 bits, which is what you want. If you set the length to 2, it will copy 64 bits. The two 16-bit integers will copy into your 32 bit integer, exactly as you wanted - but then, whatever happens to be next to those two 16 bit integers in PLC memory will be copied into whatever occupies the next 32 bits after the original 32-bit integer. And, in a Logix system, unless that's part of a user-defined data structure or a larger array, you have no idea what those memory areas are. You could overwrite a single DINT with a "meaningless" value, or you could overwrite one SINT, 5 BOOL's, and the first 19 bits of another DINT.

Basically, no PLC memory is "protected". You can do whatever you want to it, and it will happily do it. It's up to the programmer to program correctly. However, you can't overwrite an instruction segment. The instructions act on the tags, but never the other way around.

Side note: there are differences between brands. Siemens, for example, takes much more of a rigid, structured approach - which makes for a less flexible system, but it's harder to "break" things. Whereas AB tends to let you do whatever the hell you want, so it's much more flexible and has the potential to be far more powerful, but with the trade-off that it's much easier to "break" something. It's a double edged sword; with great power comes great responsibility.
 
I'd like to answer some of your questions.....

2.) Thanks for the tip on the single-scan array instructions. Curious, though - how can an array of *any* size be guaranteed to complete in a single scan without causing a MAX TIME fault? Is it possible that you could 'hang' the PLC (without crashing it)? And these instructions implicitly know the size of your array, or you still have to specify that?

You guarantee this by testing the program under "worst case" conditions. But having said that, if the program scan is say 35 mS, it would be a bad move to set the scan watchdog to say 50 mS. There is so much more going on "under the hood" than executing the user program.... I/O updates, Produced/Consumed data exchange, unscheduled messaging, and so on. All of this could "hit" the system simultaneously, causing a huge stretch in task execution time. I've always recommended setting a Task Watchdog at least 3 times longer than a typical task execution time. The default of 500mS serves most purposes.

Surprised that these newest PLCs (ControlLogix) aren't fault-tolerant. So the PLC simply crashes? That's something I saw back in the late 80's that was corrected shortly afterward. If the PLC is smart enough to see a task has overrun its execution time, you'd think it'd be smart enough to tell the offending task so it could correct itself. Can you write some kind of exception routine to prevent the hard stop?

Modern PLCs (eg. Logix5000 including ControlLogix) are no more fault tolerant than older PLCs. If a fault exists that isn't dealt with, the processor will enter fault mode and stop execution of the user's program. That is the correct response.

I will say that Allen-Bradley PLCs do far more than some other brands in detecting a fault, and allowing the programmer to do something about it, before the processor enters into a FAULT-STOP condition. Some faults you can do nothing about, "Non-Recoverable Major Faults", such as memory checksum error. That's a hardware failure, and it is right and proper that the processor shuts down. Other faults you can do a lot with, "Recoverable Major Faults" - these are most often caused by bad programming. They shouldn't occur in a well-written program.

This might sound severe, but in my opinion any program that "faults" due to a bad index being calculated, or a timer gets loaded with a negative preset or accumulator value, or one of many other reasons, means that the programmer has done a bad job.

In Logix5000 you can trap these "Program Faults", and optionally clear them to allow the program to continue. In any project I do, I would make sure I fix the cause of the fault, not just ignore it.


FLL *does* sound cleaner than COP (it saves a tag), but I assume that tag you'd use for the COP would still be a 'constant' (so it couldn't be overwritten).

If you use COP instead of FLL, the tag you have to specify as the source is not a "constant" unless you make the tag a "constant" tag, that was only possible from version 20 onwards.

Both COP and FLL can be interrupted, mid-operation, by a higher priority task. If it is important to ensure the data array is filled completely before any other instructions can use the partially completed data-set, then I would advocate using CPS, and making the source tag a constant tag if available in your revision, otherwise I would write the source value to it immediately before the CPS.

Speaking of overwriting memory, how much memory protection do these things have? Is it possible to overwrite any part of memory ... your tags, maybe even your instruction segment with a rogue index? How is the program and its data stored in the PLC's memory.

In all Allen-Bradley PLCs it is physically impossible to trash the "instruction segment" (code area). No instruction can cause any memory write outside of a tag boundary, so user's program code is protected.

I believe that in Siemens PLCs you can write code that can cause havoc anywhere in the memory space, and welcome comments from Siemens experts.
 
How about the FOR instruction? How does that index count get reset? It counts up to 1 past the terminal count, but then the manual doesn't say how it gets reset. Does it happen once the rung goes false, or do I have to reset it manually?

And I *thought* I saw a blurb somewhere that said with the FLL you have to specify the first element of the array (eg: Array[0]), and not just the name of the array? Tried to find it again, but couldn't find it! Is that correct?

Also - can I access the scaling parameters defined on the I/O Card in the logic? Let's say I want to read the upper and lower engineering limits to calculate a span, then take 1% of that to declare a transmitter out of calibration. So for my 0-10,000 ppm span, if the AT-xx transmitter drifted down to -100 ppm, that would trigger a maintenance call.
 
Last edited:
How about the FOR instruction? How does that index count get reset? It counts up to 1 past the terminal count, but then the manual doesn't say how it gets reset. Does it happen once the rung goes false, or do I have to reset it manually?

It gets re-initialised to the Initial Value on the next execution of the FOR instruction. There is no need to reset it at all, in fact the index tag can be re-used many times as a "temporary" variable.


And I *thought* I saw a blurb somewhere that said with the FLL you have to specify the first element of the array (eg: Array[0]), and not just the name of the array? Tried to find it again, but couldn't find it! Is that correct?

Yes, you always have to specify a starting element, you may not wish to FLL the whole array.


Also - can I access the scaling parameters defined on the I/O Card in the logic? Let's say I want to read the upper and lower engineering limits to calculate a span, then take 1% of that to declare a transmitter out of calibration. So for my 0-10,000 ppm span, if the AT-xx transmitter drifted down to -100 ppm, that would trigger a maintenance call.

Yes you can, they are in the "C" tag for the I/O module. Everything to do with module configuration is held in that tag. It is downloaded to the module once, and only once, whenever the system powers-up. You can manipulate the configuration parameters with code, but you would have to initiate a "Module Reconfigure" message to put your changes into the module.
 

Similar Topics

I have installed rs logix 5000 v 20, and I have a project file (.acd) ehere the controller is 1756-L71..... my software does not contains 1756...
Replies
3
Views
3,745
I have a friend/customer that has a old program, they say its version 8.... anyone have anything they can open it with and print a PDF I can go...
Replies
6
Views
2,667
More dumb questions from the 'Janitor: In this program I've been looking through (that I didn't write), I see hard-coded constants which are...
Replies
5
Views
2,757
OK, the "Janitor" here with more dumb questions: I've got an Analog I/O point (AT-13) on a 1756-IF8 module which is configured as a 4-20 ma...
Replies
42
Views
12,537
Hi, I wish to verify the CPS instruction using RSLogix 5000 v20 on Controllogix PLC. Is there any method i could do this and generate a...
Replies
1
Views
4,219
Back
Top Bottom