Studio5000 equivalent of OTU S5:0

whumphrey

Lifetime Supporting Member
Join Date
Aug 2011
Location
Lincoln, NE
Posts
35
In the SLC and Micrologix we were able to prevent math overflows (like negative timer presets) from faulting the processor by inserting a (OTU) S5:0 at the end of ladder 2.

Is there an equivalent method to this for CompactLogix and ControlLogix?

Sorry if this has already been posted. I've searched a little and came up empty.

Thanks!
 
You don't need to.

A math overflow is never considered to be a major fault in Logix5000, neither is it in PLC2, PLC3, PLC5 PLC5/250 etc.

It is only the SLC & MicroLogix families that have it, and strictly speaking, it isn't the math overflow condition that causes the fault, it is the fact that you HAD an overflow status SOMEWHERE in the program scan.

In effect the "overflow trap" bit is pretty useless, it will cause a Major Fault if it is still set when the program scan finishes, but it won't tell you WHERE the ACTUAL overflow set the overflow trap bit.

Every single SLC program I have ever seen has OTU S:5/0 as an unconditional rung at the end of file 2. That explains how useful it is ....

Forget about it in Logix5000, along the same lines as we never had it in 2, 3, 5 etc., and totally ignored it in SLC by resetting it as the last rung in the program.

Going back to your OP, a negative timer preset is declared a Major Fault in Logix5000 as it is scanned, it does not wait until the end of the scan before faulting.

You perhaps need to read up on Fault handling, both at the Program level, and the Controller level. It is possible to read the fault type and code, and clear them if that is appropriate, to allow the controller to carry on without faulting, perhaps just raising alarms for specific faults that can stop erroneous actions.

But in the case of negative timer presets (same goes for ACC values, those are also Major Faults), you have to ask the question "how did it get there?". If you have calculated the preset, you should limit-check the result before moving it into the timer. If it has come from an HMI data-entry, you should limit-check it on the HMI data-entry object.
 
Last edited:
Thanks. So no way to keep a CompactLogix from faulting on an in advertant negative timer .PRE. ?

Yes, read my previous post again - I edited it.

But in answer to this post, don't let it get negative, then you won't have to write fault routines to handle any mess caused upstream ....
 
Exception Handling

The PLC class outline download at corsairhmi.com has some discussion of the topic of exception handling. As the previous posts have indicated problems need to be handled before they become exceptions. The navy learned about it awhile back when somebody entered a zero into an interface and they lost steering control on a ship for a couple of hours. The computer was running NT and the penguin people went wild criticizing Windows exception handling. Their point was totally off the mark - the problem wasn't bad exception handling, it was bad code that caused the exception. The OS exception handler didn't and couldn't know anything about steering a boat.

The French rocket that blew up 37 seconds after liftoff since the computers were trying to stuff a >32767 value into a 16-bit signed integer was a similar situation.

For what it's worth - my general advice is to let the CPU shut down on every possible fault while you are there during startup so that you can fix whatever problems show up. Only after that should you let the CPU continue on a fault.

A more general warning is that you should always be aware of what is code and what is data and you should never trust data to the same extent that you trust code. This could lead to a lot more discussion and spirited disagreement so maybe I should leave the topic for now ...
 
A more general warning is that you should always be aware of what is code and what is data and you should never trust data to the same extent that you trust code. This could lead to a lot more discussion and spirited disagreement so maybe I should leave the topic for now ...

I’m not sure what you mean here. Trust in what way? I’m not sure that trust is the right concept here, but I’m interested in exploring it further.
 
Code works with data, period.

If either are untrustworthy there is no hope ....
 
Code and Data

I realize that newer PLCs complicate the distinctions - but in the general case the 'code' part of memory can only be changed by somebody with the PLC programming software. Once it has been changed the PLC has some sort of checksum on it. If the CPU sees that the memory does not match the checksum it shuts down with an error - as it should.

The 'data' part of memory is changing constantly from PLC logic, I/O scanning, network communications, and so on. It is impossible to checksum this memory. The new intern doing HMI development in the upstairs control room has a great deal of access to data memory. Newer PLCs have much more capability to control access to it. In the rough days of wooden ships block transfer configuration data was in an N: file that was wide open to the HMI. The intern could fat-finger an address, accidently cobble a value in a register, fix his mistake and go on. Now your PLC was trying to block transfer to the wrong slot.

In the really rough PLC-2 days the CPU didn't even have constants. You might want to multiply something times 3.1416 using their extended math stuff. You had to set the 3.1416 into a register and hope that it didn't get scrambled by some misdirected communications. The only way at that time to lock the value using code was to load the register bit-by-bit.

When I first started using PLC-5 I had people tell me that a lot of startup problems were fixed by 'reloading the program'. It took me awhile to realize what they were really interested in was reloading the data. I had been using a different antique PLC where code and data were separate downloads so I did not understand what they meant at first.

So today - if you want to be really conservative - if there is a timer preset that is exposed to the network for HMI control the HMI should be hitting a separate place in memory. The PLC should check if that value is acceptable and then copy it to the timer preset. HMI data entry bounding doesn't really do this to the same extent. The recent thread about the water plant situation in Florida relates to this.

You have to decide how paranoid you want to be about your data. The greater the paranoia the more code is required. Sometimes it's not worth the effort and sometimes it is.

As I said before, lots more could be discussed here. And it could turn into a lot of brand-specific politics....
 
I realize that newer PLCs complicate the distinctions - but in the general case the 'code' part of memory can only be changed by somebody with the PLC programming software. Once it has been changed the PLC has some sort of checksum on it. If the CPU sees that the memory does not match the checksum it shuts down with an error - as it should.

The 'data' part of memory is changing constantly from PLC logic, I/O scanning, network communications, and so on. It is impossible to checksum this memory. The new intern doing HMI development in the upstairs control room has a great deal of access to data memory. Newer PLCs have much more capability to control access to it. In the rough days of wooden ships block transfer configuration data was in an N: file that was wide open to the HMI. The intern could fat-finger an address, accidently cobble a value in a register, fix his mistake and go on. Now your PLC was trying to block transfer to the wrong slot.

In the really rough PLC-2 days the CPU didn't even have constants. You might want to multiply something times 3.1416 using their extended math stuff. You had to set the 3.1416 into a register and hope that it didn't get scrambled by some misdirected communications. The only way at that time to lock the value using code was to load the register bit-by-bit.

When I first started using PLC-5 I had people tell me that a lot of startup problems were fixed by 'reloading the program'. It took me awhile to realize what they were really interested in was reloading the data. I had been using a different antique PLC where code and data were separate downloads so I did not understand what they meant at first.

So today - if you want to be really conservative - if there is a timer preset that is exposed to the network for HMI control the HMI should be hitting a separate place in memory. The PLC should check if that value is acceptable and then copy it to the timer preset. HMI data entry bounding doesn't really do this to the same extent. The recent thread about the water plant situation in Florida relates to this.

You have to decide how paranoid you want to be about your data. The greater the paranoia the more code is required. Sometimes it's not worth the effort and sometimes it is.

As I said before, lots more could be discussed here. And it could turn into a lot of brand-specific politics....

Some good points raised there.

Firstly I would never let an external device, whether it be an HMI, SCADA, or even another PLC manipulate data that could crash mine, it would all go through intermediate tags that my code would range-check before use. Anything on comms can be susceptible to random noise events, which might cause data corruption.

What I am saying is that your applications will always have two elements, code and data. Both of those have to be "trustworthy".

The data your code uses is just as important as the code that uses it, and if you have to write additional code to protect against bad data, so be it.
 

Similar Topics

Hi Hope you all are doing well. Iam working on a project with some AOI. I also hate no online edits... lol. My problem occurs when I use a UDT...
Replies
0
Views
16
I am not sure if this is possible but if there is a way, you guys would be the ones to know. I am currently working on a project where we are...
Replies
7
Views
184
Hi all. I'm having issues adding an ethernet module to my project in Studio500 v34. The device is a Fredericks Televac EthernetIP MX gateway which...
Replies
8
Views
258
The day of week program started changing day of week 2 hours early. It changes at 10 P.M. instead of 12A.M. Just started this year.
Replies
22
Views
2,568
Hello All, need one help , looking for a example which can help me to write following code in Studio 5000 ladder logic. I have 2 String...
Replies
14
Views
735
Back
Top Bottom