Query Relay State
dtucker
Posts: 7
In my code, after turning a relay on or off, I usually check the state of the relay to verify that it was successful. It is critical in my application that relays behave properly. If I were to turn on a relay without verifying that it worked, and a relay 10 card was improperly connected or powered for example, it could be disastrous.
Code might look like this:
on[1:7:0,4];
long_while(![1:7:0,4]);
That should turn on relay 4 and then wait to progress until relay 4 reads as on. This has always worked fine, and has saved me in cases where relay cards weren’t properly seated in a card frame.
I have a customer who is having trouble with a system. Logging indicates that that the system is turning on a relay, and then waiting for it to read as on, but it never does, except in one case where the relay took 1 minute 35 seconds to finally read as on. That’s a slow relay. This relay is on an NXI (1:7:0,4)
My question is how does the system keep track of if a relay is on or off? Does it actually try and sense the state of the relay, or is there a table somewhere that tracks if a relay was last turned off or on? If it actually checks the state of the relay, is it likely I have a bad relay that isn’t switching properly? Or if it just saves the state information in a table, what would cause the relay to still read as off when I turned it on, but finally read as on after a minute and a half? How is the table updated?
Any information on this issue could be helpful.
Thank you,
David
Code might look like this:
on[1:7:0,4];
long_while(![1:7:0,4]);
That should turn on relay 4 and then wait to progress until relay 4 reads as on. This has always worked fine, and has saved me in cases where relay cards weren’t properly seated in a card frame.
I have a customer who is having trouble with a system. Logging indicates that that the system is turning on a relay, and then waiting for it to read as on, but it never does, except in one case where the relay took 1 minute 35 seconds to finally read as on. That’s a slow relay. This relay is on an NXI (1:7:0,4)
My question is how does the system keep track of if a relay is on or off? Does it actually try and sense the state of the relay, or is there a table somewhere that tracks if a relay was last turned off or on? If it actually checks the state of the relay, is it likely I have a bad relay that isn’t switching properly? Or if it just saves the state information in a table, what would cause the relay to still read as off when I turned it on, but finally read as on after a minute and a half? How is the table updated?
Any information on this issue could be helpful.
Thank you,
David
0
Comments
long_while(![1:7:0,4]);]
I'll assume there's missing brackets? Why use LONG_WHILE? Why not use WAIT_UNTIL? There are issues I believe with LONG_WHILE - Jeff can speak more about it, I forget the details. But I'm going to say it's more of a code issue than it is the relay being slow, or not updating quickly enough.
Maybe it would be more clear if written as:
LONG_WHILE ( NOT ( [1:7:0,4] ) );
Which is to say, do nothing but loop until [1:7:0,4] is on.
I believe WAIT_UNTIL schedules code for execution until some condition, but then continues to execute code further down in the function. I want to halt progression of execution until this condition is met. If I used a WAIT_UNTIL every time I wanted to wait for a condition, I would have waits within waits within waits, 30 deep. It is much easier to just loop until a condition is true.
I do this all the time and it works great. It is just on this one system that it isn't working. I am running the same code on other NXIs without issue. But this one consistently fails.
Rather than getting into what will only become a huge argument over what is the best method, let's examine the theory behind what you're describing.
The netlinx master knows when a device is on or offline. If the relay has physically failed but the logic board thinks it has deployed no method using feedback from the relay device is going to save you.
You can always tie the status of the relay to a variable or virtual device.
Things like
DEFINE_VARIBLE
volatile integer my_relay_Stat
DEFINE_PROGRAM
my_relay_Stat=[dv_My_Relays,4]
will track it in a way that you can easily use throughout your program.
Also you could (and I'd do it this way myself..) put it in an event. Events allow you much more flexibility and are much less processor 'spendy' than stuff in DEFINE_PROGRAM.
channel_event[dv_MY_Relays,4] { on: { my_relay_Stat=1 // now do something about it } off: { my_relay_Stat=0 // now do something about it. } ]Perhaps there's a way in which you could get some other kind of feedback to another port or something that will tell you that all is well.
For example, let's say your relay is sending 12VDC to something or other to make it go. Perhaps you could wire another relay in parallel to make a contact closure that will trigger an I/O port. So, now, not only do you see the relay's channel fire on and off, but you'll see an I/O channel come on and off as well. This way if the relay fails, you'll have some other port verifying the problem.
Hope that helps.
Yes, this is good -- a positive indication as to whether the relay is open or closed rather than an indication from the feedback channel. Typically, the feedback channel will indicate whether the relay is physically opened or closed, but not necessarily. I think that if you pulse a channel which is controlled by a mutually exclusive that the relay will open and close properly but the feedback will stay on, for example.
edit:
I've never used the long_while technique described by the OP but it appears to me to depend on the while being interrupted promptly by the relay feedback channel status being turned on and recognized. Seems that this may not be foolproof as it doesn't work properly in at least one case. Perhaps using a flag variable may help:
on[1:7:0,4];
flagRelay = 0
long_while(!flagRelay )
{
flagRelay = [1:7:0,4]
}
Wouldn't that help insure that the status of the relay feedback channel is evaluated every time through the while loop?
I would not use a long while loop for this purpose. If you must make sure your code wont continue until the state changes. This is far better and will not bogg down the processor!
on[1:7:0,4];
WAIT_UNTIL([1:7:0,4] == false)
{
}
Given this statement, I would absolutely go with the method Eric describes. This is an amazing coincidence. I was just dealing with an application yesterday of similar importance and I had to think of a way to positively verify the relays would be functioning. Eric's method is actually the same way that I came up with. Take the output from the relay and feed it back into an I/O port. If you can't take the signal coming from the tripped relay side, you can add a DPDT relay to allow one pole to trigger the I/O and the other to trigger the device. In my method, I'm putting in a routine in code to test the relays daily to confirm that everything is working properly.
As to your question of why your code isn't working, I don't know offhand... I didn't bother to look at it because the part of your post that I quoted tells me it's not a good idea to try to verify without real feedback from the relay output.
-John
If it's critical to know the act has occurred, sense the act rather than the switch that (should) trigger the act.
For example, if you MUST know that the lift has opened before you turn on the projector, put a sensor on the LIFT to know what position it's in, don't take the word of the activation relay that may be hundreds of feet upstream from the device.
It's much more likely that, if anything, something AFTER the relay will interrupt the desired act. The relays tend to just work. But they don't know anything about what happened to your device!
I think I already said this.
quoth me
My example was just an example to explain the theory. But, thanks for reinforcing it! E