speed sensing

I have done some basic ladder programs that work ok and I am learning all the time.
I now have a problem that I cant see a solution to, I need your help.

I have a prox watching a spinning barrel (for movement detection) and the doors cannot be opened to it until it has stopped.

This program has been written 1 year ago by me and has worked well but i read a similar thing on here before (cant remember when and who by) about the prox failing.

Well it failed the other day and somebody opened the door while it was still spinning. No accident happened but I have to make it safe for future.

I have already sorted that if prox failed, it cant run (after short time no signals from prox)
But what can I do if prox fail while it is running at full speed or slowing down.

Especially if its slowing down because when signal stops - means ok for doors open???

Since its a safety issue you may want to consider redundancy...ie more than one sensor.

I assume that the prox is working with a gear (or?) and it "pulses" when the barrel is rotating.
One method is to use a time factor to detect if prox has failed closed (full ON) when drive is OFF....ie when motor is OFF during x time period I should see A pulse if not then ALARM.

If you programmed it to detect the movement you should be able to program it to detect if the prox is not pulsing. This can get tricky because it can stop with prox in full on position.

could also turn the drum on with the PLC and in your program say you have to be telling the drum to be spinning and if you dont see the prox flickering you can alarm & not allow door to be opened.
I like the redunancy, though.

If it's a high risk, you should add a mechanical brake that's failsafe when the door is opened via a safety relay. Using the PLC for a safety device is never a good idea.

one shots

Assuming the prox only provides a short pulse, use it to drive a one shot which resets a retentive timer which is always enabled. If the prox fails, no more one shots. The timer times out and stops the motor. The motor run logic will need to be involved in this also.

Queation:

Are the doors on the spinning barrel, or on an enclosure containing the barrel? If the door is on the barrel a cintrifical lock on the door may be in order. If the door is on the enclosure containing the barrel then a safety switch on the door, (positive action limit switch), that would cut the power to the motor, (bypassing the PLC), might be a good idea.

Thanks for replies

To explain further:

This barrel is enclosed in a huge box with electro magnetic locks
The barrel extracts fat from cooked meat.

The whole process is controlled from the plc

There is a brake but because of the high speed and the varying weights inside, it takes different times to stop.

The brake sometimes fails or wears out but the pulsing prox still doesnt let them open the doors until it has coasted to a stop.
I even put a timer on the braking to put a brake fault light on. (set longer than the longest time with normal braking)

2 prox's was my first idea but then i realised I have no spare inputs and the plc is none expandable (apart from buying a bigger model) I have since learned to over spec a plc

I have replaced the prox and it is working perfectly again, but its not perfect and I know its not perfect and it is eating at me.

I have programed it to stop and brake if the pulses are lost during the motor running and keep the doors locked for long enough to have stopped

But in normal working, when the brake has been applied and the motor disengaged (contactors off) I am relying on the pulses to stop to tell it the doors can be opened.

In this case, they opened the door and saw it was still spinning (no deadly serious danger as the barrel is a way inside) but I know its not right.
They were not unduly alarmed and still arnt.
I repaired the fault and everything is ok with them, but not with me.

I thought I might be missing a condition or factor that I could tie in with the logic should it happen again

It's too bad you don't have any spare PLC inputs. A combination normally open/normally closed prox could be a solution. With that, the two inputs should always be in opposite states. If both were on or both off at the same time that would be a fault condition.

One of our customers makes the media for petre dishes and uses a simmilar process. I have no idea how it's setup thou.

Anyway, there is such a thing as a magnetly coupled centrifugal switch that could be mounted on the drive shaft, or motor shaft. The contacts on the switch would be wired to the magnetic door lock and release the lock only after the barrel as stopped, and also could be hardwired to prevent the barrel motion if the door is not closed. This circuit would be totally independent of the plc, and provide a better degree of safety.

Link for switch: http://www.hubbell-icd.com/icd/speed/ss2200.asp

You didnt mention what brand plc, most can be "networked" so another unit the same size could offer more inputs. You have the right idea...make it better...the how is up to you. I believe you need to use redundant sensors.

In our mill we use zero-speed prox switches (Omron and Turck) and locking door switches which lock automatically while machine is in motion, if operator needs to open the door they have to manually turn a switch which disables all motors

"I have programed it to stop and brake if the pulses are lost during the motor running and keep the doors locked for long enough to have stopped

But in normal working, when the brake has been applied and the motor disengaged (contactors off) I am relying on the pulses to stop to tell it the doors can be opened."

While the motor contactor is engaged, continuously run a timer. If the timer times out then latch "Prox-Failed".
While the timer is running, each prox-pulse resets the timer. As long as the timer does not timeout then the prox is assumed OK. Consider the time-value carefully.

The concept here is... "I'll believe that the prox is OK only so long as the prox continues to prove it is OK."

Hmmm... is this a "front-loader" (like a typical clothes dryer) or a "top-loader" (like a typical clothes washer)?

The coast-time for a top-loader will be longer than the coast-time for a front-loader. How much longer? It depends...

Assuming that the meat is simply contained loosely within the drum, not necessarily "held-in-place" within the drum...

In a front-loader...
If the mass of the meat is significant when compared to the mass of the drum, then at some point, when the velocity of the drum falls low enough, instead of completing the circular path in the drum, the meat will fall to the bottom of the drum thus helping to provide braking action.

In a top-loader...
If the meat is "riding high" on the side of the drum, then, as the velocity is reduced, the meat will slide down the sides toward the bottom of the drum. This will reduce the inertia presented by the meat. The inertia of the drum will remain the same. The total inertia will be reduced. However, the falling/sliding meat does NOT contribute any braking action as it does in the front-loader.

In any case, if the "Prox-Failed" bit is latched, you must also assume total brake-failure.

Unless you have a way to determine the actual inertia involved for the particular load, you must assume the worst case inertia. That means assuming maximum speed, maximum weight and maximum time to coast to stop.

So... when the motor contactor is opened, if the "Prox-Failed" bit is latched, then run a timer that covers the absolute worst case coast time. Then, after the timer times out, unlock the door.


Now... how to handle the case where the prox fails during stopping... this is definitely tougher...
(additionally, I don't know your system like you do...)

The first thing you need to do is determine that the brake is working adequately. You should do this under all stopping conditions.

How many pulses-per-revolution? How many pulses-per-minute at full speed?

While stopping, track the number of pulses per unit of time and see if the change in pulse counts per unit of time indicates that the brake is working as expected. Basically, you are looking to see that the velocity of the drum is reducing as expected (at least within a reasonable range). As soon as this can be determined, latch a bit indicating "Brake is OK".

You know better than I what your braking-curve looks like (or should look like). Remember, during the first few moments of braking the velocity will change little.

While "Brake is OK" and prox is still known to be good... continue monitoring the velocity of the drum. As the velocity reduces, the time between pulses will increase... you should be able to calculate the time before the next pulse. Every time a pulse occurs, calculate the current velocity and then calculate the time before the next pulse... add a small percentage (5%-10% buffer) to that time and then load that time into the timer. If the velocity is still high enough that the pulse should occur, however the pulse does NOT occur... then the prox must be assumed to have failed.

At some point, the velocity will be low enough that the occurance of the next pulse becomes questionable. If the velocity is low enough and the pulse doesn't occur when expected then run one more timer just to make sure that the drum is stopped (even if the prox fails during this time).

If you determine that the velocity is NOT reducing as expected (well out of range), then latch a bit indicating "Brake is BAD!". Meanwhile, continue monitoring the status of the prox. If the prox is determined to have failed and the "Brake is BAD!" bit is latched, then you must fall back onto the worst case stopping scenario described earlier.

That's the best I can do with the given information...

Does this stuff give you any ideas?