Cx-programmer instruction or method to detect sensor fault

[Bobobodopalus]

Hi all
I feel like im having a bit of a brain freeze and this little bit of logic should be easy but its not coming to me.
i just want to see that a sensor is changing states when the machine is moving.


when the clutch is activated, if the sensor has not changed from on to off during the clutch activation it should set an error.


i feel like there must be a way to easily do this but its really stumping me for some reason :/

 

[drbitboy]

when the clutch is activated, if the sensor has not changed from on to off during the clutch activation it should set an error.

So if the clutch is activated AND the sensor is on, then that is the error?

[XIC clutch_activated XIC machine_stopped_sensor_on OTE error_machine_not_moving]
​

seems like the minimal case for which you are looking, no?


The XICs could be used as the Trigger in a State Coil/Fault Coil pattern, cf. here, if you want the set error state to persist and require operator acknowledgement even if the error condition changes (e.g. the clutch is deactivated).

Perhaps there could be a delay on the situation, to allow the sensor a short time to detect machine movement and change to off e.g.

[XIC clutch_activated XIC machine_stopped_sensor_on TON 0 100 OTE error_machine_not_moving]
​

Sorry if I have the syntax wrong, but basically it is equivalent to a debounce TON on the ANDed XICs' result, where the TON is not expected to expire so its .Q not expected to be 1, but if the TON does expire then its .Q assigns 1 to the error bit.

 

[Bobobodopalus]

the error is that is the clutch is active and the sensor is on for the entire duration, i think i came up with something workable if not maybe a bit clunky.
if the counter is completed there is no error, the counter is reset at the start of the cycle

 

[drbitboy]

the error is that is the clutch is active and the sensor is on for the entire duration, i think i came up with something workable if not maybe a bit clunky.
if the counter is completed there is no error, the counter is reset at the start of the cycle

hmm, that "for the entire duration" is new information; duration of what?



what counter? what is a cycle?


I don't think enough information has been provided here to help.


It does sound like

[XIC clutch_is_active XIC machine_stopped_sensor_on ...]


​

is the start of what is desired, but there seem to be other pieces of the puzzle.

 

[drbitboy]

Is the sensor going on and off (1 and 0) repeatedly while the machine is moving? I.e. is it generating pulses, and those pulses are counted? All while the clutch is activated?


And if no pulses are being generated when the clutch is activated, then that implies the machine is not moving, and that is the error?


If that is the case, then there should be a maximum time that the sensor input can be either 1 or 0 continuously while the clutch is activated, so you could AND the clutch activated bit with the sensor bit, feed the result into the enable rung of a TON, and normally the sensor bit will change and reset the TON before the TON expires, but if the TON expires (.DN becomes 1), then the sensor has been in one state too long while the clutch is active, which implies the machine is not moving.

 

[osmanmom]

how about using speed feedback

 

[Bobobodopalus]

so while the clutch output is on, the machine turns and the sensor should see a gap while moving before the clutch disengages and becomes blocked again.
this is simply to see if the sensor has become dirty and is giving a false reading, we know that while the clutch is active the sensor should see a gap at some point during it.


edit: ah i just noticed that the screen shot i added didnt add before

https://imgur.com/a/m556X4l


for some additional info this is on a canning machine, the can present sensor is blocked by a can being in the starwheel, in theory there will never be an empty slot.
when the machine clutch activates the starwheel indexes and moves the next can into position

 

[drbitboy]

So you want to see the blue behavior below, not the red x's?

           Time ===>


       1            +------------------------------+
clutch              |                              |
sensor              |                              |
       0  ----------+                              +---------
          <-clutch-><--------clutch active--------><-clutch-...
           inactive                                 inactive

       1  -----------------[COLOR=Blue][B]+[COLOR=Red]xxxxxxxxxxxxxxxxx[/COLOR][/B][/COLOR][B][COLOR=blue]+-[/COLOR][/B]---------------
   can                  [COLOR=blue][B]   |                 |[/B][/COLOR]
sensor[COLOR=blue][B]                     |                 |[/B][/COLOR]
       0                   [COLOR=Blue][B]+-----------------+[/B][/COLOR]
                 
          <---can---------><---no can--------><-----can----...
            present            present             present

If yes, when do you want to detect/declare the red x's (error) conditions? e.g.

• 100ms (or some other delay) after the clutch goes active?
• when the clutch goes inactive (0) again?
• Some other point in the process?

Is there a minimum width (duration) over which the can sensor should be 0?

 

[parky]

Perhaps this is one way, I have no idea if you have rising & falling oneshots so shown own rolled ones, I'm not sure if I read your explanation but this checks sensor switches while clutch is on.

EDIT: Ah.. Just seen your latest post so may not be what you want.

 

[drbitboy]

• Hand-rolled one-shots
  • Edge-detection instructions, if available, reduce number of rungs by 1 and number of instructions by 4
• Canonical patterns from Contact & Coil
• Issues an alarm (no_gap_alarm becomes 1) when there have been no gaps in cans between
  • clutch going active (rising edge),
  • and clutch going inactive (falling edge).
• Will not issue an alarm if can is missing from a starwheel slot.
• Untested.

​

 

[parky]

I would expect that even if a can is there you will get transitions as the cans are gapped by the star wheel, how do you determine cans there.
So, you need to see a gap or how can you tell if it is working ? the problem then becomes if there is a missing can what do you do ? do you alarm & stop just because 1 can was missed, or do you wait for at least 5 or six cans in that case, there are no cans or the sensor is not detecting cans ?.
I have worked on fillers, generally the speed is quite high above a few thousand cans a minute, however, some of the larger cans may be in the hundreds, scan time can then become a problem, answer use high speed interrupts.
The ones I worked on relied on sensors on the can infeed system to check if cans are present & runout routines to bypass can in place checking, we also had to do something with glass bottles, there were sensors to detect broken bottles, if so, a wash jet was used to clear the broken glass before it was filled, this was to reduce waste product so was tracked into the filler star wheel.

 

[drbitboy]

Here is the simple timer-based version; this might not work if the rate of cans is too high and the TON preset time too low.

 

[parky]

I think he wants to check if the sensor does not trigger either way i.e. could be open or closed fault, the only way I see this working if for example it is possible to have missing cans is to have a count of the cans scenarios:
1. if it is not possible for a can to be missing then each rotation of the star wheel can check a transition from 0-1 & 1-0, this assumes in normal operation there is always a can.
2. Allowing for the odd empty slot: in this case it would need to check over a short time period i.e. if more than two or three cans were missing then alarm (note this would be either there are no cans or the sensor stopped working).

3. If 2 is the ideal, then a second sensor would be needed to differentiate between no cans & sensor fault, it would also need a runout routine so at a normal stop (if cans are to be run out) that disables the alarm.
I have seen many versions of checking for can jams/missing cans (also applies to bottles), often the maintenance guys disable them because they cause more trouble than they are worth, I'm also surprised that the star wheel is driven by a clutch, most ones I have come across are mechanically linked to the filling system so basically most of the operations are mechanical. off one drive, a can stop is then provided on the infeed of the star wheel.

 

[mendonsy]

Omron supports differentiated inputs so the simple answer is a counter with a preset of 2 or 3. The clutch output would be used to trigger the counter and an on or off transition of the sensor would be used to reset the counter. If the counter reaches the preset then the sensor has failed.

 

[drbitboy]

Say we expect the two bits to follow a known sequence, e.g.

0. clutch active/can present = 0/1, then
1. clutch activated => 1/1,
2. gap start detected => 1/0
3. next can detected => 1/1
4. clutch deactivated => 0/1

That is the normal sequence. So

• 0/0 generates an alarm
• if sequence is 0 and 1/1, increment seq# to 1
• if seq# is 1 and 1/0, increment seq# to 2
• if seq# is 2 and 1/1, increment seq# to 3
• if seq# is 3 and 0/1, increment seq# to 4
• on falling edge of clutch active, alarm if seq# is not 4
• if seq# is 4, reset seq# to 0
• Whenever clutch/can sensors are 0/1, reset the sequence# to 0 at the end of a scan
  • assumes I/O scan is either synchronous with program scan or uses a buffer/input map)

Pedantic and ugly, but it catches anything outside of "normal."