Sign in to follow this  
Followers 0
Conor

SLC no One shot

16 posts in this topic

Hi, I am trying to program in a latch for alarms. I have alarms on coming into inputs. These inputs are mapped to N9's. So I:1.0 mapped to N9:1 I:2.0 mapped to N9:2 I:3.0 mapped to N9:3 What I want to do set a sounder off when an alarm is present. Then have a button that turns off the sounder, even though the alarm might still be active. The sounder is for indication purposes for my operators. I tried the following code; When N9:1 is greater than 0, then a OSR latches a bit alarm 1. Alarm 1 latched sets sounder bit. Silence alarm bit unlatches alarm 1. My problem is that if one of my Integers is still at one the OSR is at one. Can anyone tell me how to do this please. I am using a SLC 5/05 L553

Share this post


Link to post
Share on other sites
Double click to the left of the rung noted above. The mnemonics of the rung should appear. Copy those mnemonics and paste them in a post here.

Share this post


Link to post
Share on other sites
SOR GRT N9:1 0 OSR B3:1/0 OTL B3:0/1 EOR

Share this post


Link to post
Share on other sites
So this rung latches B3:0/1 if N9:1 changes from zero to non-zero. It must return to zero then back to non-zero to trigger the latch again. Is that not what you want? It is what you wrote. If it is not what you want then please be more precise. Is it possible that you want to latch B3:0/11 if ANY of the bits within N9:1 changes from 0 to 1?

Share this post


Link to post
Share on other sites
Sorry if I explained it wrong the first time. When I get an alarm, say N9:1/3. Then my alarm latch will come on. I am then able to unlatch the alarm with a push button. Unlatching the alarm silences a sounder. But my alarm N9:1/3 is still present. Then we say, N9:1/7 comes on. I have unlatched the alarm bit from the push button above but the alarm bit does not latch again. If this was a One shot instead of a OSR then would this not work??

Share this post


Link to post
Share on other sites
not sure what the sor is but the rest of it looks like it would do what you are looking for. keep in mind that the OSR bit will turn on and stay on until the condition if front of it is false (or 0). It will only pass that true (or 1) condition through for one scan. So in your case, if the result of the GRT instruction is true, then the osr bit will be on; however, the otl instruction will only see a true condition before it for one scan. You should be able to toggle that bit at will even though the osr bit is true. The bit assigned to the OSR instruction is just used to show that it has already performed its oneshot function.

Share this post


Link to post
Share on other sites
Try this: BST NEG N9:10 N9:11 NXB AND N9:1 N9:11 N9:12 NXB GRT N9:12 0 OTL B3:0/1 NXB MOV N9:1 N9:10 BND What we are doing is storing (at the end) the current state of the inputs. On the next scan we invert (change all 0 to 1 and vice versa) the previous. We the AND that with the current input. What remains is any NEW bit which turns ON relative to the previous. Finally, if there are any of these new turn on bits then set the alarm. The comparison with the results of the previous rung acts like an OSR for each individual bit in the word.

Share this post


Link to post
Share on other sites
Oh now thats different. No it would not work. OSR is a oneshot. A traditional oneshot looks for the value before it to go from a 0 to a 1. One shot rising (OSR) does the same. The reason this is not working is that the value of N9:1 is always greater than 0 in your case. If the first bit is still set when the second bit goes on, the oneshot still sees a 1 at the output of the GRT statement.

Share this post


Link to post
Share on other sites
I think that is more along the line of what he is looking for except you will need a NOT instead of the NEG. With 2's complement integers, the negative will not be a simple inversion but an inversion +1.

Share this post


Link to post
Share on other sites
Good catch - thank you

Share this post


Link to post
Share on other sites
Thanks guys. I tested this code and it works great.

Share this post


Link to post
Share on other sites
Doug-P - that would generate a one shot when a bit turns off also. The oroginal poster only wanted one on the the Turn-On.

Share this post


Link to post
Share on other sites
Indeed, NEQ would be better. We'll wring all the problems out of this yet.

Share this post


Link to post
Share on other sites
Thanks again guys. I hadn't seen the last few posts. If I let my processor see -32768 will this send the processor into fault? I haven't got a chance to put in the latest version on this code from the post yet

Share this post


Link to post
Share on other sites
No the minus wouldn't fault the processor, at least as far as the compare is concerned, it just wouldn't give a TRUE to the GRT zero. If we use the NEQ, zero then we get a TRUE in ALL non-zero instances (that is if ANY of the bits including the top one go on).

Share this post


Link to post
Share on other sites
I really dislike the code because it will be difficult to troubleshoot. One shots and latches should be used sparingly. The usual code that I would use is to have a "seal in" or latching RUNG. In text, A=your condition to set the alarm bit If not reset_signal AND (A or output_bit) then OTE output_bit This is akin to the usual code for start/stop buttons... If not stop_button AND (start_button OR output_bit) then OTE output_bit The code latches the output_bit whenever the input conditions are true, and it is held by the very same bit. Whenever the input conditions (reset_signal) go true, then the latched bit clears. There is one sticky issue that can help or hurt here depending on your intended application. This method uses nonretentive bits. In the event of a power failure, the outputs will be cleared automatically on power up during the power up prescan. To avoid this, the latching instruction (OTL) is necessary and the latching ladder logic is not needed. Instead, the reset signal should go straight to an OTU. Second issue...use of the one shot. The OTL already retains the correct setting. Using the OSR means that if the alarm condition persists, then it will not rearm when the reset command is giving. Normally that's not the correct handling of alarms...they should rearm immediately if the alarm conditions still exist. Using the OSR AND OTL is double handling.

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