Sign in to follow this  
Followers 0
waterboy

ONS against bits vs JSR

14 posts in this topic

Using CLX I tried to capture the state of a bunch of bits using a single ONS and branches like this ONS XIC1 OTE1 XIO1 OTU1 XIC2 OTE2 XIO2 OTU2 When in a continiously scanned ladder this will hold the OTE's in whatever state they are captured in. I thought the ONS would prevent this but . . . So I put the above in a routine and then used ONS JSR1 And that worked like a charm. I can manipulate OTE1 and OTE2 without a problem after the initial scan. Why the difference? Shouldn't the ONS have done the same job as the ONS to JSR?

Share this post


Link to post
Share on other sites
No it shouldn't. The ONS is on when the bit in front of it is on. When it turns on it passes the "on state" to the coil for one scan. After that the coil is turned off. In your stated example if any input bit was on then the ONS goes true and stays true until all inputs are off Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
Maybe another way When the ONS triggered the JSR1 the logic in subroutine 1 executed JUST ONCE When the ONS was in the rung the logic executed with a TRUE state just before it ONCE. But after that the logic was still evaluated each scan but with a FALSE state just before it so that the OTEs turned the outputs OFF regardless of the C1/C2 states. Edited by b_carlton

Share this post


Link to post
Share on other sites
Thats the piece I missed. I was assuming a ONS simpley ignored stuff after it had executed, but I got it now. Heres something interesting too, Dont leave a timer in an unscanned ladder. the .ACC winds up with all sorts of crazy numbers. I know there is a KB article about scanning a timer at least every 90 minutes or something like that, but this craziness was immediate.

Share this post


Link to post
Share on other sites
An older SLC500 / Micrologix Instruction Set Manual showed 2.5 seconds as the maximum ttime between evaluations for a .01 second timebase timer. The way a timer works is that, when first evaluated, it zeroes its accumulator and also grabs a snapshot of the current system free-running timer. When it is evaluated again it subtracts that snapshot from the CURRENT value of the free-running timer (it knows how to handle a single roll-over). The difference it adds to its accumulator, tests to see if it is at or past the Preset in which case it sets the Done bit, and grabs another snapshot. If the time between evaluations is more than one FULL cycle (the 2.5 seconds in the particular application) of the free-running timer it has no idea that that much time passed. it just blindly does the math and continues with false information. Edited by b_carlton

Share this post


Link to post
Share on other sites
THAT... is a great answer. Makes complete sense. Thank you Thank you both.

Share this post


Link to post
Share on other sites
Just for a follow-up ... your first post would have worked the way you expected if you replaced the OTEs with OTLs

Share this post


Link to post
Share on other sites
I could then manipulate those bits in another part of the program without them being affected by the OTL?

Share this post


Link to post
Share on other sites
Correct. OTLs and OTUs only DO SOMETHING to the bit if the logic to them is TRUE. If it is FALSE they DO NOTHING. This is different than an OTE which does something if the logic to it is TRUE (turn the bit ON) and also does something if the logic to it is FALSE (turn the bit OFF).

Share this post


Link to post
Share on other sites
Well, thats gonna change my thinking.

Share this post


Link to post
Share on other sites
Why would you though? To many, this is very bad practice & only adds to confusion.

Share this post


Link to post
Share on other sites
Fair question, In this specification I need to capture the current commanded position of several devices just as the system is switched from an automatic sequence into a manual control mode. Essentially freezing the process right where it is and then allowing manual control from that point in the sequence. This requires that I disable a set of control bits (xic) and use different ones. I do this by jumping (JSR) out of the current ladder set and into a specific ladder, running only that one. This abandons the automatic recipe driven control bits that were in play and instead uses a different set used only for manual control. Switching back to automatic likewise abandons the manual bits and uses the automatic ones again. In this case exiting manual mode will home everything. Manual mode here is just to allow the operator to get the machine out of a problem that some failure or the material has created. It wont be used frequently but had to be predictable. Homing everything on error was not desired.

Share this post


Link to post
Share on other sites
this might be going into places that you would rather not have to even think about – but ... first, suppose that you're running in the MANUAL mode – and suddenly the system suffers a plant-wide power failure ... later when the power is restored, how do you want the system to react? ... (1) stay in the MANUAL mode (2) revert to AUTOMATIC mode (3) something else now, suppose that you're running in the AUTOMATIC mode – and suddenly the system suffers a plant-wide power failure ... later when the power is restored, how do you want the system to react? ... (1) stay in the AUTOMATIC mode (2) revert to MANUAL mode (3) something else I don't have time to go into a lot of detail right now – but my point is that many systems like the one you've described often behave unpredictably whenever the controller has a "Go-To-Run" event ... so ... once you've got it "working OK" you still need to carefully test the system's responses under various "start up" conditions ... particularly if the system happens to present any type of safety hazard ... HINT: it's hard to tell from the code samples that you've shown, but based on what you've posted so far, I'd bet substantially more than pocket change that some of the instructions that you've mentioned (especially the OTE and the ONS instructions) are NOT always doing exactly what you THINK they're doing ... in particular, you need to consider how these things will be affected by the controller's PRESCAN operation ... here's part of the official write-up for how PRESCAN affects the ONS instruction: (here the book is using the term "set" to mean "written to a status of ONE") ... so in other words, if you program an ONS instruction on an UNCONDITIONAL rung, the ONS will NOT "fire" (or go "TRUE") when the rung is first scanned ... forgive me if I've misinterpreted what you've posted – but it appears that you've been somewhat puzzled by that fact ... (going further: note that the PRESCAN rules can be different for the systems which use RSLogix500) ... but back to my basic idea: test the system under normal day-to-day operation conditions – and then be sure to test how the various operating modes will respond when put through a "power cycle" ... based on what you've posted so far, there could be some potential "gotchas" lurking in the underbrush ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
I had considered the power up problem, I will be using the power-up ladder ( I might have that name wrong) to home everything and leave it in a known state and you are (of course) right that the unconditional ONS may not be reset when something goes wonky even after the first scan. I saw very quickly that issue simply taking a ladder off scan ! I tried solving that by reseting the bits I used for the ONS, but than saw how silly that was, tossed that idea and got rid of them (and Timers) in any ladder that can be put off scan. I can see the potential of what might happen should the power fail in mid transit, PLC not knowing where the device is or even which way it is going. In this particular case I am safe, the devices all simply get out of the way upon restart, Operators put things right and then start up again, But I will look into the "underbrush" just to improve my techniques. The stuff I usually design from the ground up is very slow moving and generally sequential so I can get away with quite a lot of. . . less than optimal . . . code. But I am aware that I can do better and I do appreciate it when a better technique gets pointed out. I will look at the prescan. I never gave it much thought before. And of course I will turn it over to a real operator to see if he can break it before it goes live.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0