Input checking

Please illuminate with a logic example how to check if an input changes state between uses. I wish to confirm that a sensor input is actualy switching.

you could add a line of programme to count the sensor inputs and check this against the number of inputs you should have recieved

davefinic said:

you could add a line of programme to count the sensor inputs and check this against the number of inputs you should have recieved

Click to expand...

what software are you using? either way the best way is to use a pulse or positive edge detection instruction.

Hi,
i had to do something similar on a revolving fixture:

Sequence was along these lines

1. parts loaded and detected

2. Table turns and Parts Welded together

3. When the table turns back to load position set an internal marker using the position switch as a oneshot/Rising edge

4. The internal marker is set to 1 till the sensor is off which resets the internal marker,ready for next cycle

5. If the sensor stays on ie Part still loaded or defective Lead/Switch ~ inhibit cycle start and fire an error message to the user

Even if you take out the table turning, you could use another event to start your switching test.

Hope this helps
STL

"...changes state between uses"?

It just wouldn't make sense that you are only looking to verify that your input goes on, but if that is what you are looking for, then try the following, where Input-X is the input in question and Input-Y is a spare button, or switch, that you can use to reset the latch.

After entering the code, go flash the sensor and then go back to your monitor to check the status of "Input DID come on!"

Note: You shouldn't have to go through all of this if you have help. You should be able to simply watch the monitor while someone flashes the sensor. However, if you are working alone... maybe.

 Input-X

---| |-----------( SET ) Input DID come on!



 Input-Y

---| |-----------( RST ) Input DID come on!

 

.
On the other-hand... if you are looking to see if the input comes on when it should not come on, then you simply need to KNOW when the input SHOULD NOT be on. If it comes on when it should not be on, then Latch that fact!

 Input-X

SHOULD NOT

  BE ON!    Input-X

---| |---------| |-----( SET ) Input came on at the wrong time!



 Input-Y

---| |-----------( RST ) Input came on at the wrong time!

.
Now, you should only trap the fact that the input came on only when it shouldn't have come on. In order to turn on "Input-X SHOULD NOT BE ON!" you need to know what conditional activities indicate that period when you "know" that the input should not be on. Then, you also need to "know" when that input is expected to come on. You must turn off "Input-X SHOULD NOT BE ON!" just a moment, or two, before the input is really expected to come on... so that you don't record a "false-positive".

You need to understand the conditional activity that occurs (time-wise) before, and after, the particular input should be on. This of course depends on your process and how you have designed your code.

By understanding your process, and having enough inputs to provide enough information... you should be able to "see" the sequence of events before, and after, thus allowing you to determine that "window" when the input should not be on.

I have no idea what your process is... so I can't go any further... without subjecting myself to a great deal of pain.

Sooo....?

I have run into this with prox switches of different types/situations. We cycled grippers on pick n place stations on the return cycle. The grippers had three prox switches, one for part in place, one for closed - no part, the last for open. On the return there should be no part, and both prox switches should make when closed. This tested the prox switches, and didn't cost any cycle time. This was done in statement logic, and depended on the machine cycle. If a prox was not in the correct state during a particular part of the machine cycle, an alarm was set. The alarm would either flash a light or stop the machine.



Your situation will depend on your machines cycle, and how the programming is done over all.



I have used timers in de-bounce/dwell situations, count up/count down, latch/unlatch and have even compared the value of an input card word, to a known value to check multiple inputs(in one card.) All of these are useful, but are dependent on machine cycle. If you are assembeling parts, there is always a place or two where you can compare in one way or another.

Its hard to give an example without first having a known process. Logic, depends on processor at the least. Machines that complete one step at a time are easily checked.

By cycle time, I ment machine cycle, not processor cycle. All of the checking did cost in terms of program cycle.