You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

Reply
 
Thread Tools Display Modes
Old April 15th, 2021, 05:32 PM   #1
whumphrey
Lifetime Supporting Member
United States

whumphrey is offline
 
Join Date: Aug 2011
Location: Lincoln, NE
Posts: 35
Studio5000 equivalent of OTU S5:0

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!
  Reply With Quote
Old April 15th, 2021, 05:45 PM   #2
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 2,675
S:V?


Cf. https://literature.rockwellautomatio...5%2C457%2C0%5D


?


or this: http://www.plctalk.net/qanda/showthread.php?t=92578

Last edited by drbitboy; April 15th, 2021 at 05:50 PM.
  Reply With Quote
Old April 15th, 2021, 06:04 PM   #3
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 5,282
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.
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
Everything works with smoke. Let it out, and it stops working.

Nil Carborundem Illegitimi




Last edited by daba; April 15th, 2021 at 06:19 PM.
  Reply With Quote
Old April 15th, 2021, 06:10 PM   #4
whumphrey
Lifetime Supporting Member
United States

whumphrey is offline
 
Join Date: Aug 2011
Location: Lincoln, NE
Posts: 35
Thanks. So no way to keep a CompactLogix from faulting on an in advertant negative timer .PRE. ?
  Reply With Quote
Old April 15th, 2021, 06:24 PM   #5
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 5,282
Quote:
Originally Posted by whumphrey View Post
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 ....
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
Everything works with smoke. Let it out, and it stops working.

Nil Carborundem Illegitimi



  Reply With Quote
Old April 15th, 2021, 06:29 PM   #6
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 5,282
Quote:
Originally Posted by whumphrey View Post
Thanks. So no way to keep a CompactLogix from faulting on an in advertant negative timer .PRE. ?
Inadvertent values don't just "happen", they are created by programmers ....
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
Everything works with smoke. Let it out, and it stops working.

Nil Carborundem Illegitimi



  Reply With Quote
Old April 15th, 2021, 08:55 PM   #7
Corsair
Member
United States

Corsair is offline
 
Join Date: Dec 2020
Location: Missouri
Posts: 57
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 ...
  Reply With Quote
Old April 15th, 2021, 09:51 PM   #8
jhenson29
Member
United States

jhenson29 is offline
 
Join Date: Mar 2021
Location: St. Louis, MO
Posts: 63
Quote:
Originally Posted by Corsair View Post
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.
  Reply With Quote
Old April 15th, 2021, 10:23 PM   #9
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 5,282
Code works with data, period.

If either are untrustworthy there is no hope ....
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
Everything works with smoke. Let it out, and it stops working.

Nil Carborundem Illegitimi



  Reply With Quote
Old April 15th, 2021, 10:51 PM   #10
Corsair
Member
United States

Corsair is offline
 
Join Date: Dec 2020
Location: Missouri
Posts: 57
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....
  Reply With Quote
Old April 16th, 2021, 04:00 PM   #11
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 5,282
Quote:
Originally Posted by Corsair View Post
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.
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
Everything works with smoke. Let it out, and it stops working.

Nil Carborundem Illegitimi



  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Using Studio5000 Emulate to Sim program to Ifix matthew1 LIVE PLC Questions And Answers 6 June 15th, 2020 12:19 AM
Problems opening a file in studio5000 bendanator LIVE PLC Questions And Answers 4 December 11th, 2018 11:14 PM
Studio5000 Reuires Logon to FactoryTalk whussain6 LIVE PLC Questions And Answers 2 February 8th, 2016 12:15 PM
RSLogix 500 Instruction Help mdeltat LIVE PLC Questions And Answers 26 September 19th, 2011 06:55 PM
Motor Equivalent Circuit (Long & Detailed) DickDV LIVE PLC Questions And Answers 36 February 12th, 2006 07:03 PM


All times are GMT -4. The time now is 05:41 AM.


.