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.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


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

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old June 14th, 2017, 10:12 AM   #31
dmargineau
Lifetime Supporting Member
United States

dmargineau is offline
 
dmargineau's Avatar
 
Join Date: Dec 2011
Location: Midwest
Posts: 2,164
Quote:
Originally Posted by Sparkyman1 View Post
I was not aware that AB PLC's would do that, what is needed for the processer to "decide" that a bit should be turned off on the first scan?
Because that's how the manufacturer decided its products will operate; it is a safe approach for starting up a PLC controlled system:

"...On power-up, the controller prescans logic to initialize instructions. The
controller resets all state-based instructions, such as outputs (OTE) and timers
(TON)...."
  Reply With Quote
Old June 14th, 2017, 10:18 AM   #32
LoganB
Member
United States

LoganB is offline
 
Join Date: Apr 2017
Location: Michigan
Posts: 71
Quote:
Originally Posted by AustralIan View Post
Disadvantages:
Takes up twice the space on the HMI.
I usually stack the buttons on top of each other and give them visibility animations. There's not really an instance when the machine will be "ON" and need to be turned on again, so displaying the BTTN doesn't serve much purpose.
  Reply With Quote
Old June 14th, 2017, 10:20 AM   #33
LoganB
Member
United States

LoganB is offline
 
Join Date: Apr 2017
Location: Michigan
Posts: 71
Quote:
Originally Posted by Sparkyman1 View Post
I was not aware that AB PLC's would do that, what is needed for the processer to "decide" that a bit should be turned off on the first scan?
Nifty part of AB controllers. OTEs will always be in a "0" state on first scan, so any XIC holding on an output with the output address will power up in an off state. Latched outputs, on the other hand, will remain in a state of "1" if the machine loses power while they are latched on iirc. Depending on the application, knowing the difference is rather useful!
  Reply With Quote
Old June 14th, 2017, 10:38 AM   #34
rdrast
Lifetime Supporting Member
United States

rdrast is offline
 
rdrast's Avatar
 
Join Date: Apr 2003
Location: South Carolina Lowcountry
Posts: 4,992
Quote:
Originally Posted by dmargineau View Post
Because that's how the manufacturer decided its products will operate; it is a safe approach for starting up a PLC controlled system:

"...On power-up, the controller prescans logic to initialize instructions. The
controller resets all state-based instructions, such as outputs (OTE) and timers
(TON)...."
If and Only If the routine is scanned during prescan. So it doesn't apply to routines not called.

And in any event, if I want something to be in a certain state on powerup, I will always put an direct command to set it properly in my own initialize routine.
__________________
------------------------------------
How to ask questions the SMART Way!

Look First, Ask Second!

  Reply With Quote
Old June 14th, 2017, 10:54 AM   #35
dmargineau
Lifetime Supporting Member
United States

dmargineau is offline
 
dmargineau's Avatar
 
Join Date: Dec 2011
Location: Midwest
Posts: 2,164
Quote:
Originally Posted by rdrast View Post
If and Only If the routine is scanned during prescan. So it doesn't apply to routines not called.
.
I believe Logix controllers do not execute logic during pre-scan.

Logix controllers do execute logic during the first-scan.
  Reply With Quote
Old June 14th, 2017, 10:57 AM   #36
proof
Member
United States

proof is offline
 
Join Date: Jan 2014
Location: Illinois
Posts: 113
Quote:
Originally Posted by ASF View Post
The line between genius and bat-***** insane is a thin one, and I'm not sure which side of the line this technique sits on. One half of me goes "oh my god, that's not how you do things! Why would you abuse ladder logic like that!", and the other half of me goes "actually, that's quite a clever way of doing it, even if it IS unconventional".
The original question was about what we thought about using duplicate destructive ONS bits. It seems that most people don't like seeing duplicate ONS bits. I don't like them because they generate warnings. I wouldn't change it, but if I was writing from scratch, I'd do it different.

Base on what the code does and the way it its coded, what seems to be the function required of the code, and thus what conditions limit how it is coded?

1) The HMI toggles a Pushbutton Bit, and the PLC resets this bit and toggles a Toggle Bit.
2) Because a second ONS was used, I assume that A one shot bit is needed elsewhere in the code when the pushbutton is pressed. If the one shot isn't needed, the duplicate ONS wouldn't be needed.
3) Since OTL and OTU were used, I assume that the toggle state must be maintained during power cycles/PLC restarts, and thus logic latching the toggle bit using an OTE isn't appropriate.
4) It should be short and simple.


Toggle1.png


This code would get rid of the duplicate destructive bit warnings, but could confuse the Bubbas with the PB needing to be both ON and OFF to prevent the Toggle bit from latching.

Last edited by proof; June 14th, 2017 at 11:01 AM.
  Reply With Quote
Old June 14th, 2017, 03:17 PM   #37
Sparkyman1
Member
United States

Sparkyman1 is offline
 
Join Date: Apr 2017
Location: Minnesota
Posts: 27
Quote:
Originally Posted by LoganB View Post
I usually stack the buttons on top of each other and give them visibility animations. There's not really an instance when the machine will be "ON" and need to be turned on again, so displaying the BTTN doesn't serve much purpose.
If you stack two buttons on top of each other then what's the point of having two buttons? Why not just one maintained button with 2 states? I've found the same thing on another HMI in our plant. I was assuming that the original intention of doing it was to have two buttons
  Reply With Quote
Old June 14th, 2017, 03:24 PM   #38
LoganB
Member
United States

LoganB is offline
 
Join Date: Apr 2017
Location: Michigan
Posts: 71
Quote:
Originally Posted by Sparkyman1 View Post
If you stack two buttons on top of each other then what's the point of having two buttons? Why not just one maintained button with 2 states? I've found the same thing on another HMI in our plant. I was assuming that the original intention of doing it was to have two buttons
I should have specified, "in instances where space is an issue".

Even in instances where latched/maintained buttons would make more sense, I usually use momentary buttons with that logic layout just out of force of habit.
  Reply With Quote
Old June 14th, 2017, 05:31 PM   #39
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,101
Quote:
Originally Posted by dmargineau View Post
I believe Logix controllers do not execute logic during pre-scan.

Logix controllers do execute logic during the first-scan.
Depends on how you define "execute logic".

Ron Beaufort give a pretty good explanation of it in this post. The long and short of it is, on a Logix-class PLC (not SLC, or MicroLogix), every bit associated with an OTE tag will be set to zero during the prescan, but only if the OTE is in a routine that has some way of theoretically being called (i.e. a JSR in a routine that also has some way of being called).

The pre-scan also resets any non-retentive timers, and a few other things. So you can call that "executing logic" or something else, but whichever way you go, I can promise you if you hang around long enough someone will disagree with your semantics
  Reply With Quote
Old June 14th, 2017, 06:11 PM   #40
dmargineau
Lifetime Supporting Member
United States

dmargineau is offline
 
dmargineau's Avatar
 
Join Date: Dec 2011
Location: Midwest
Posts: 2,164
Quote:
Originally Posted by ASF View Post
Depends on how you define "execute logic".
The original quote (..."Prescan differs from first scan in that the controller does not execute logic during prescan. The controller executes logic during first scan...") is from Page 36 of Publication 1756-RM094C-EN-P - June 2007 -Logix5000 Controllers Design Considerations

I believe there is a difference between 'pre-scan' and 'first-scan'.

During pre-scan, input values are not current and outputs are not written.

After the power-up pre-scan the first-scan will follow and execute the implemented logic.

According to the UM, the power-up Pre-scan does not relate to any implemented logic regarding all state-based (non-retentive?) instructions (OTEs, TONs, ONSRs etc.); they are all reset no matter if the routines they are placed within are programatically 'called-up' or not.

Ron's example refers to OTLs and OTUs which do not fall within the above category- they are retentive by design and if they are placed within routines programmed to be scanned will retain their states.

Last edited by dmargineau; June 14th, 2017 at 06:14 PM. Reason: Poor grammar!
  Reply With Quote
Old June 14th, 2017, 06:19 PM   #41
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,101
Quote:
Originally Posted by dmargineau
The power-up Pre-scan does not relate to any implemented logic regarding all state-based (non-retentive?) instructions (OTEs, TONs, ONSRs etc.); they are all reset no matter if the routines they are placed within are programatically 'called-up' or not.
This is not quite correct. In a Logix-class PLC (again, not SLC/Micrologix), if you have an OTE on a rung anywhere, the pre-scan will set the associated BOOL tag to zero - but only if that rung is in a routine that has some way of being called.

If the OTE is in a routine that is called by an unconditional JSR, the bit will be turned off during prescan.

If the OTE is in a routine that is called by an JSR that may or may not be executed depending on the state of preceding logic, the bit will be turned off during prescan.

If the OTE is in a routine that is called by an JSR which cannot possibly be executed because it is preceded by an AFI or similar always-false logic, the bit will be turned off during prescan.

But, if the OTE is in a routine to which no JSR or other path exists, the bit will not be acted upon in any way during prescan.

The same, of course, applies if there is no path to the routine containing the JSR to your routine with the OTE. By which I mean, if you have an OTE in SBR_03, and SBR_03 is called by an unconditional JSR in SBR_02, but there is no JSR or other means of executing SBR_02, then likewise, your OTE will not be set to zero during prescan.
  Reply With Quote
Old June 14th, 2017, 06:24 PM   #42
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,101
Other than that, you're right in that there is definitely a difference between pre-scan and first scan. And you're right about not "executing logic" in the sense of evaluating all the instructions during pre-scan. I'm just cautious about how I word it because there is still an evaluation of the logic to the extent that it's required to determine what is and is not reset to what values. Definitely not "executing logic" in the traditional sense, but still more than just a blanket "reset and reinitialize" with no concern for any user program.

But in any case, it looks like Rockwell agrees with your terminology, no matter what I think
  Reply With Quote
Old June 14th, 2017, 06:45 PM   #43
dmargineau
Lifetime Supporting Member
United States

dmargineau is offline
 
dmargineau's Avatar
 
Join Date: Dec 2011
Location: Midwest
Posts: 2,164
Quote:
Originally Posted by ASF View Post

But in any case, it looks like Rockwell agrees with your terminology, no matter what I think
......but not the other way around......(myself agreeing with Rockwell that is!)

Anyway, if an OTE or TON is placed within a routine which is not being called-up within a Program the pre-scan does not need to worry about their 'last states' since they will be 'reset' as soon as taken out of the scan.

So, the statement that all OTEs and TONs will be reset during a power-up prescan is true no matter if said instructions' routines are called-up within a Program or not...Hmmm...Isn't it?...
  Reply With Quote
Old June 14th, 2017, 10:49 PM   #44
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,101
Quote:
Originally Posted by dmargineau View Post
So, the statement that all OTEs and TONs will be reset during a power-up prescan is true no matter if said instructions' routines are called-up within a Program or not...Hmmm...Isn't it?...
No. It's a common misconception that OTE's only hold "on" while they're actively being scanned. It's not the case. Try not to think of an OTE as a relay coil - as much as that's how all of us probably learned, that's not actually the case.

With a relay coil, if the power is cut to it because you turn the panel off (shut the PLC down) or simply pick it up and put it on the shelf (put it in an unused routine), then yes, a physical relay coil will turn off.

But an OTE is not a relay coil. Nor is it a bit. An OTE is an instruction, with two functions, that acts on a single BOOL.

The two functions:
1. If the OTE is executed with a TRUE rung-in condition: set the associated BOOL to 1
2. If the OTE is executed with a FALSE rung-in condition: set the associated BOOL to 0
(obviously, prescan is a special case, but I think we've covered that).
The BOOL itself is not linked to the OTE. Well, I mean, it is, because you've created the OTE instruction and told it to act on that particular BOOL tag. But the BOOL just sits there being either one or zero, indefinitely, unless the OTE (or some other instruction) acts on it to make it something else.

Try it out - if you have an OTE addressing a coil that is turned on, cut-and-paste it (online) into a routine that's not called. Once it's in that routine, you can manipulate the preceding logic however you want - even delete the lot and replace it with just an AFI and your OTE - and the OTE will stay "green" because the BOOL tag is still set to 1. The only way the OTE can set it back to zero, is if the OTE is scanned with a false rung-in condition - and the OTE is not being scanned any more.

I've seen the same thing with indirect addressing. I had an array of UDT's controlling a bank of 8 valves, which fed into 8 silos. I wrote the following line of code (more or less):
Code:
|   Seq_Start          InfeedValve[SelectedSilo].Open
|------| |--------------------------(  )----------------|
...the idea being that whatever silo was selected when the sequence started, the corresponding infeed valve would open. The problem was that sometimes they would change the silo partway through the process. Let's say you start with Silo #1. So My logic effectively becomes OTE InfeedValve[1].Open. So InfeedValve[1].Open - the BOOL tag - is set to 1. But now, if they change to Silo 2, my logic becomes OTE InfeedValve[2].Open. So InfeedValve[2].Open - again, the BOOL tag - is set to 1. But what happened to BOOL tag InfeedValve[1].Open? Nothing. All of a sudden, it has no OTE addressing it in any capacity. So, it'll just sit there being a 1 until some logic comes along to change it. And now I have two valves open.

The "relay coil" analogy is great for getting your head around it to start with, but when you get into fine detail, it can trip you up
  Reply With Quote
Old June 14th, 2017, 10:51 PM   #45
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,101
Do you think we've derailed the OP's thread enough yet, or should we continue on down the rabbit hole a little further?
  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
InOut Tags and Duplicate Destructive Bit warnings ASF LIVE PLC Questions And Answers 0 August 18th, 2015 01:10 AM
Sequencers randy LIVE PLC Questions And Answers 43 December 20th, 2014 03:10 PM
can you specify bits in omron PLC's maintenance@seta LIVE PLC Questions And Answers 5 January 6th, 2011 03:54 AM
Bits and more bits, chess, bit boards and tidbits. Peter Nachtwey LIVE PLC Questions And Answers 3 May 3rd, 2007 03:21 PM
Please Explain blackslipper LIVE PLC Questions And Answers 7 December 27th, 2005 01:14 AM


All times are GMT -5. The time now is 10:38 PM.


.