PLC memory usage

[aditya89]

I would like to create an AOI which throw me an alarm when cpu usage is more than 75%. Since GSV doesn not support this functionality I am wondering, is there any way to monitor the PLC CPU usage. I tried calling rockwell for support but they were unable to provide me any concrete information. Please help !!

 

[PreLC]

I would like to create an AOI which throw me an alarm when cpu usage is more than 75%. Since GSV doesn not support this functionality I am wondering, is there any way to monitor the PLC CPU usage. I tried calling rockwell for support but they were unable to provide me any concrete information. Please help !!

What's your use case? What's your PLC? Are your tasks all periodic, or continuous? Are you looking to have an AOI and deploy it across multiple PLCs?

Also, why do you want to check for usage? Would execution time not be more important than CPU usage in almost all cases?

 

[aditya89]

PLC 1756 -L73
Current logic is under continuous taks . New routine to be added are in periodic task( Monitor the health / collect data from the VFD's). Yes, would like to deploy this AOI to all the panels in my building.I want to check for the usage beacuse I feel adding all the new routines will interfere will the messaging ( Sending information back and forth to the cloud )I am currently doing in the continous task . Yes, execution time does matter but I want to create the AOI just a tool for local site control people to keep a watch on .

 

[JeremyM]

If you have a continuous task, CPU usage will be 100%.

Your goals are also a little ambiguous. Do you want to monitor your VFDs or the % time spent on execution threads by a real-time piece of hardware designed to operate uninterrupted 24/7?

 

[drbitboy]

If you have a continuous task, CPU usage will be 100%. ...

^ Stated another way, this is why CPU usage cannot be measured directly: the CPU can always run the continuous task, so the CPU always has something to do, so CPU usage is 100%.

That said, looking at how long it does take to complete each scan of the continuous task, and comparing that to the longest allowable/desirable time it should take, is an expression of PLC loading: as the amount of work the CPU does per scan increases, the [does take:should take] ratio increases.

So, if this new AOI was run at the start of every scan, and subtracted its previous GSV-obtained WallClockTime from the current WallClockTime to get an overall per-scan duration, then that difference duration could be divided into a "watchdog" timeout duration, and the resulting ratio is a form of CPU usage. The nice thing about this per-scan approach is that higher-priority tasks, such as communications, scheduled tasks, housekeeping, etc., are all included in the calculated "usage", although they are likely to cause this "measured" usage to bounce around a bit.

The point here is that CPU "usage" is only an issue if it takes too long for the PLC to respond to a process change on the next scan after that change. The exact definition of "too long" is a specific property of OP's process, but it is essentially a form of watchdog timeout, so at least the approach above is consistent with that.

The details of how to calculate a difference between two WallClockTime DINT[2] or LINT[1] values, what the process' "too long"/watchdog divisor value should be, whether and how to filter this "measured" usage, etc., are left as an exercise for the OP.

 

[Aardwizz]

An alternative approach to what drbitboy said is to use GSV(Task, Continuous, LastScanTime,<DINT tag>) to measure how badly the PLC is being held up by interruptions.

Keep in mind that the L8x processor have a co-processor to handle communications (HMI, PLC, I/O) while the older processors did not, and so used System Overhead Time Slice to try to manage comms. I've had some very large programs that were brought to their knees by HMI comms which disappeared when I upgraded to an L8x.

 

[Operaghost]

I'm with the others here. Measuring CPU usage is not useful since a Continuous task will keep it at or very near 100% all the time even with next to no logic. That's just how that type of task works.

Instead, use a GSV to monitor the scan time of the Continuous task. Anything happening in the Periodic task will impact the scan time of the Continuous task. You can setup a GSV using the Task object to retrieve the LastScanTime or MaximumScanTime attributes. Those will be values in microseconds. Monitor those and write logic to take an action to respond to changes.

OG

 

[janner_10]

Do you mean Capacity, i.e. the value you read in controller properties?

That increases as you add more tags and logic and doesn't change if you don't!

It will estimate capacity for you when offline, so add your logic and check it.

If only you are doing the changes, there's really no point trying to read this live, you wouldn't check the larder everyday if you lived alone to see if someone has put food in it when you weren't looking.