What happens when a PLC runs out of RAM?

[dmbartender]

I am running an L72S and it has just 84kb of the 4mb left. I can get the program loaded into the controller, and it scans the main routine at about 45ms per cycle.

The HMI seems really slow however...can it be that with so little RAM left over, that the PLC cannot service the interface to the HMI very well?

Thanks!

 

[dmargineau]

It looks like you need an L73S.
43 ms for the Continuous Task would be considered "slow" even for a forty years old PLC5.
Personally, I think any CPU running at more than 75% CPU usage is definitely "undersized"...I always aim for no more than 66% "normal" usage...

 

[dmbartender]

WEll, I know I need the L73S, but I have to wait until I get it. My projects generally run between 25-35ms with an L72S...they are pretty big machines for just one processor.

But back to my original question....how is the performance of the PLC affected when the RAM is maxed out?

 

[dmargineau]

In a similar manner to the results you are experiencing... The CPU will considerably "slow down" the continuous task's execution timing, "overhead" processing (including HMI/SCADA unscheduled communications)will "wait" longer and, in extreme situations, the processor will fail to execute the scheduled tasks within the alloted time slice, fail to poll I/O at the RPI setting or it won't be able to maintain the motion planner's Coarse Update Rate.
Like pretty much anywhere within the artificial intelligence world, processing speed is directly proportional to the RAM availability.
Until your L73S shows up, if the HMI communications timing is a major issue, within the Controller Properties applet, Advanced Tab, try to slightly increase the default 20% slice time alloted for "overhead" processing and unscheduled communications; a 30-40% setting might add a few milliseconds to the Continuous Task's execution, however, improve the HMI/SCADA performance;
Altering the default setting for the Unused Overhead Time Slice from the Continuous Task priority to Syatem priority might also alleviate the issues you are experiencing.

 

[daba]

In my experience running short on Free Memory is not accompanied by anything "slowing down".

What will suffer is the amount of online editing you can do, since that uses free memory until the edits are assembled.

You will also limit the processors ability to update offline projects when they go online if they do not have the most up-to-date copy of the program (correlation).

With only 84K left in a 72S, you are way, way above the margin suggested.

I wonder what you have in there that is using so much memory, and that perhaps there are things that could be rationalised to reduce the memory usage.

As for adjusting the System Overhead TimeSlice, go ahead and increase it, don't be shy either, but make sure you tick the box that says "Continue normal processing with unused time-slice". That gives you the best of all worlds.

 

[dmbartender]

Thanks for the insightful replies, guys. Experimenting with the time slice settings, I found that I got better results with lowering the time slice to 10%. That way I get decent continuous cycle time of about 40ms, and my recipe saves in about 22 seconds. Actually, the saving of my recipe doesn't seem too heavily affected by the time slice.

I use this benchmark, because it takes the longest amount of time to execute between the HMI and CLX. By the way, I am using a Zenon HMI with Rockwell driver, and my recipe is 12,672 bytes (large size due to lots of arrays).

 

[MichaelG]

my recipe is 12,672 bytes (large size due to lots of arrays).

You probably already know this

Is your Recipe using a UDT?
If so have you minimised the UDT size by blocking the data types?

Are you aware that a single BOOL data type uses 4 bytes and a UDT with 32 named bools uses 4 bytes?

 

[dmbartender]

Howdy. The recipe is comprised of various UDTs. What do you mean by blocking the data types?

 

[MichaelG]

Look at the following UDT Byte Calculations
Same Members but use less space

Big


Compact



I think that the 4 byte data types must be on 4 byte boundary

The Rockwell Recommendation is to block all BOOL's, SINT, DINT, REALS together
Ie order the data types from smallest to largest
BOOL
SINT
INT
DINT
REAL


Easiest way to do this off line is

Copy the UDT members to Excel
Use Sort on the Data type
Copy and Paste back into the UDT
WARNING this may ruin existing data stored in the UDT​

The Default STRING datatype has 82 chars you may be better off with with a custom STRING datatype if you are not using all 82 characters

 

[dmbartender]

Hey Michael G, that is a good summarization of how to make data types in CLX. Unfortunately for me, even after reorganization, I still will have a huge recipe due to all of the array members. But thanks for the tip...using the filter and sort function in Excel will be a good way to implement data types in the future.

 

[dmargineau]

In my experience running short on Free Memory is not accompanied by anything "slowing down".

What will suffer is the amount of online editing you can do, since that uses free memory until the edits are assembled.

You will also limit the processors ability to update offline projects when they go online if they do not have the most up-to-date copy of the program (correlation).

With only 84K left in a 72S, you are way, way above the margin suggested.

I wonder what you have in there that is using so much memory, and that perhaps there are things that could be rationalised to reduce the memory usage.

As for adjusting the System Overhead TimeSlice, go ahead and increase it, don't be shy either, but make sure you tick the box that says "Continue normal processing with unused time-slice". That gives you the best of all worlds.

Yes we are getting into the gray areas of processing capability and experiences tend to take over what theory might suggest.
I have personally and recently encountered a couple of "classic" application over-developments which caused nothing but grief and countless hours spent to no avail by the owners' professionals; tasks overlaps, long Continuous Tasks's executions (50-75 ms) and motion which failed to return consistent results.
I believe there were two L62s running with no issues for seven years or so until the applications needed to be further developed due to the production lines' modernizing; the firmware was pushed up to 20(and then promptly returned to 19!), UDTs were implemented everywhere allowed and quite a few AOIs were created in order to alleviate the new development 90% CPU RAM burden.
Nothing generated significant improvements but an update to a L63 processor which would run an identical application at a 71% "load" and returning the expected results; obviously, doubling up the RAM availability allowed the CPU to execute the application in a more efficient manner since most of the L62s issues were related to timing.