Best Practice - What controls recommended for a 2-position turntable

[Baxterr]

Out of interest, I'd like some thoughts on what would be considered best practice with regards to a 2-position turntable control scheme (see attached image for reference).

The turntable rotates 90 degrees to its turned position, then returns back to its home position.

The turntable has a conveyor section attached and transfers products between adjacent conveyors.

The SEW motor that drives the slewing ring via a PowerFlex 525 0.4kW VFD to rotate the turntable has an EK8S incremental encoder 1024/4096 analog resolution wired back to an Allen-Bradley 1734-IK POINT I/O 24V DC Incremental Encoder Module.


Given this information, what would you consider best practice to control the rotation and stop positions?

Points for consideration:

• Inductive proximity switches
• Use of incremental encoder
• Overtravel protection
• Slowdown before reaching position

Sorry if this may seem vague, I'm trying to get responses without giving away its current method of operation to compare. If any other information is needed, please ask.

 

[Steve Bailey]

Sorry if this may seem vague, I'm trying to get responses without giving away its current method of operation to compare.

Knowing the current design has never deterred forum members from suggesting a redesign.

Based on the picture, I'd guess that there is a few degrees of leeway in the angular position at each position, so proximity switches might give you adequate accuracy. But if you've got an encoder on the motor and the corresponding module on the drive, why not take advantage of it?

How often does the turntable need to operate and how much time is available for each move? That, together with the inertia of the loaded turntable is likely to dictate the acceleration deceleration rate you can handle. The drive will need to be sized to handle the current required to accelerate the load and to dissipate the kinetic energy when you decelerate it.

 

[I_Automation]

Set destination position for encoder
Have setting for difference to drop to slow speed (able to adjust)
Have setting for drop to creep speed (also adjustable)
Have safety magnetic switches for In Position A and In Position B
Watch encoder and if goes past stop point creep backwards to stop point


I have done these with 2 position turntables and a hoist that moved racks along a track with 22 stations.


When I started working on the hoist it had 2 proxy switches for nearing position and drop to slow, but I found they weren't out far enough to stop the hoist in time, so I programmed them out and added the above count that I add or subtract from the destination count and can tweak on a setting screen. Plus I had to add the creep back as the original program just stopped and lifted even if it went too far and missed the rack.

 

[Baxterr]

Knowing the current design has never deterred forum members from suggesting a redesign.

Based on the picture, I'd guess that there is a few degrees of leeway in the angular position at each position, so proximity switches might give you adequate accuracy. But if you've got an encoder on the motor and the corresponding module on the drive, why not take advantage of it?

How often does the turntable need to operate and how much time is available for each move? That, together with the inertia of the loaded turntable is likely to dictate the acceleration deceleration rate you can handle. The drive will need to be sized to handle the current required to accelerate the load and to dissipate the kinetic energy when you decelerate it.

My thinking leads me down the avenue of combining the positional feedback from the encoder and the use of proximity switches to create a band for both positions e.g. stop on proxy A for position A, check encoder count is within predetermined band, position verified. Or would you stop based on encoder count then check for proxy activation to confirm?

Turntable performs anywhere between 600-900 cycles per day. Working to a takt time of 56 seconds so speed isn't necessary. They currently perform a cycle within 30 seconds. Inertia and other mechanical variables aren't really a concern due to the design being over-engineered for its application.

Set destination position for encoder
Have setting for difference to drop to slow speed (able to adjust)
Have setting for drop to creep speed (also adjustable)
Have safety magnetic switches for In Position A and In Position B
Watch encoder and if goes past stop point creep backwards to stop point


I have done these with 2 position turntables and a hoist that moved racks along a track with 22 stations.


When I started working on the hoist it had 2 proxy switches for nearing position and drop to slow, but I found they weren't out far enough to stop the hoist in time, so I programmed them out and added the above count that I add or subtract from the destination count and can tweak on a setting screen. Plus I had to add the creep back as the original program just stopped and lifted even if it went too far and missed the rack.

So you believe that the stop positions should be controlled by proxys, and slow/creep/overtravel should be controlled by encoder position?

Do you have any concerns when using incremental encoders in the event of power failure whereby you may lose current positional data with the turntable in any postion other than its home position?

 

[controlsgirl]

Is it a turntable that has a mechanical cam? If so, there will be a dead zone where the motor can spin but the turntable will not which makes it super easy to stop the motor with a prox switch without the delay affecting the position of the table. That's the only turntable I have used and its way better than having to worry about a servo and all that goes along with commissioning/programming it.

And I can answer the question about "why not use it if you got it"...because its extra work for everyone involved; extra work to program, extra work to recover, and extra stuff to troubleshoot when things break.

 

[controlsgirl]

Best practice with any motion using an encoder is to always have some sort of sensor to at least verify the home position when commanded there. This allows you to throw a machine fault early on if/when anything slips mechanically. ;-)

My thinking leads me down the avenue of combining the positional feedback from the encoder and the use of proximity switches to create a band for both positions e.g. stop on proxy A for position A, check encoder count is within predetermined band, position verified. Or would you stop based on encoder count then check for proxy activation to confirm?

Turntable performs anywhere between 600-900 cycles per day. Working to a takt time of 56 seconds so speed isn't necessary. They currently perform a cycle within 30 seconds. Inertia and other mechanical variables aren't really a concern due to the design being over-engineered for its application.



So you believe that the stop positions should be controlled by proxys, and slow/creep/overtravel should be controlled by encoder position?

Do you have any concerns when using incremental encoders in the event of power failure whereby you may lose current positional data with the turntable in any postion other than its home position?

 

[Baxterr]

Is it a turntable that has a mechanical cam? If so, there will be a dead zone where the motor can spin but the turntable will not which makes it super easy to stop the motor with a prox switch without the delay affecting the position of the table. That's the only turntable I have used and its way better than having to worry about a servo and all that goes along with commissioning/programming it.

And I can answer the question about "why not use it if you got it"...because its extra work for everyone involved; extra work to program, extra work to recover, and extra stuff to troubleshoot when things break.

It is a slewing ring assembly.

I do have to somewhat agree with your latter point, not everybody is controls-oriented and it can make troubleshooting/recovery difficult when you throw black magic such as encoders into the equation.

Sometimes keeping it simple and using physical limits can be the answer for something that is essentially a basic operation.

Best practice with any motion using an encoder is to always have some sort of sensor to at least verify the home position when commanded there. This allows you to throw a machine fault early on if/when anything slips mechanically. ;-)

This is my understanding also.

What would your answer be to the following:

Turntable is halfway through cycle, encoder count @ 200,000.
Power is lost then restored, count resets to 0, turntable remains in its position.

The PLC that the remote I/O communicates back to is on a UPS and should never turn off. I've played with MOV of PresentData (encoder count) into an internal register to save the count but how would you then reinitialize the turntable? My thinking would be to force it to drive until it sees its home position sensor to reset count... but then I think of scenarios:

Shutdown periods. Machinery is powered down, turntable may be slewed manually with brake released, stored encoder count will then no longer be the same as its actual position. Would telling it to drive back to home (which would always be, lets say clockwise in this scenario) suffice? What if home is @ 0 degrees and the turntable is left manually slewed at 5 degrees, it would then try and drive home 355 degrees clockwise, potentially damaging cabling underneath as its normal operating conditions only require 90 degrees of movement.

 

[I_Automation]

So you believe that the stop positions should be controlled by proxys, and slow/creep/overtravel should be controlled by encoder position?

NO!


Verified by safety magnetic switches after stopped at the correct encoder count.


Plus, because of the possible safety issues I would not use proxy sensors for in safe position.

 

[ASF]

I'd always have overtravel limits. Failsafe both mechanically (i.e. not reliant on a flag that could get bent or removed to trigger the sensor, but rather always triggering the sensor unless it overtravels) and electrically (i.e. power on the input = no overtravel condition). You hit the overtravel, you stop all motion in any direction and make someone physically come and look at what the heck is going on to have managed to hit an overtravel limit and fix it manually.

what I'd do next would depend on whether my objective is "make it works for as few peanuts as possible" or "make this as resilient and reliable as possible". Note that even if my objective is "make it work for as few peanuts as possible", I would still include the overtravel limits because an overtravel event will inevitably happen and cost many peanuts if there is no ability to detect it.

If the objective is "minimum peanut expenditure" then I'd do the rest of the positioning with the encoder. Add a function to "teach" the encoder position so that if the position is lost or mechanical slip occurs, operators can jog it to the respective positions and set those positions as the 0 and 90 degree positions. Automatically calculate slow down positions based on the taught final positions.

If my objective was "resilient and reliable" (i.e. spend additional peanuts upfront to ensure a more reliable peanut income stream long term), I would add position proximity sensors at the 0 and 90 degree position. I'd do the slow down based on the encoder position, but stop based on the sensors, and do a cross check each time to make sure the encoder reading was vaguely what I expected it to be. After a power loss or encoder position loss, homing could be done automatically by travelling to ether end sensor and setting to a known position. If mechanical slippage of any sort occurred (as detected by the encoder seeing the end sensors at a different position to the expected position), I could either adjust encoder positions automatically, or require the operator to re-home manually - this would depend on the mechanics of the system. If it were a case of "a belt might have slipped, it's fine, just update the encoder position and carry on", I'd update automatically. If it's a case of "okay, we might have worn gears or a sensor might need adjusting", I'd make it more of a manual correction process.

 

[Baxterr]

NO!


Verified by safety magnetic switches after stopped at the correct encoder count.


Plus, because of the possible safety issues I would not use proxy sensors for in safe position.

Apologies, I understood what you meant first time around but in replying, just defaulted to 'proxy' in my head! I do like the idea of using safety-rated sensors, great point.

I'd always have overtravel limits. Failsafe both mechanically (i.e. not reliant on a flag that could get bent or removed to trigger the sensor, but rather always triggering the sensor unless it overtravels) and electrically (i.e. power on the input = no overtravel condition). You hit the overtravel, you stop all motion in any direction and make someone physically come and look at what the heck is going on to have managed to hit an overtravel limit and fix it manually.

what I'd do next would depend on whether my objective is "make it works for as few peanuts as possible" or "make this as resilient and reliable as possible". Note that even if my objective is "make it work for as few peanuts as possible", I would still include the overtravel limits because an overtravel event will inevitably happen and cost many peanuts if there is no ability to detect it.

If the objective is "minimum peanut expenditure" then I'd do the rest of the positioning with the encoder. Add a function to "teach" the encoder position so that if the position is lost or mechanical slip occurs, operators can jog it to the respective positions and set those positions as the 0 and 90 degree positions. Automatically calculate slow down positions based on the taught final positions.

If my objective was "resilient and reliable" (i.e. spend additional peanuts upfront to ensure a more reliable peanut income stream long term), I would add position proximity sensors at the 0 and 90 degree position. I'd do the slow down based on the encoder position, but stop based on the sensors, and do a cross check each time to make sure the encoder reading was vaguely what I expected it to be. After a power loss or encoder position loss, homing could be done automatically by travelling to ether end sensor and setting to a known position. If mechanical slippage of any sort occurred (as detected by the encoder seeing the end sensors at a different position to the expected position), I could either adjust encoder positions automatically, or require the operator to re-home manually - this would depend on the mechanics of the system. If it were a case of "a belt might have slipped, it's fine, just update the encoder position and carry on", I'd update automatically. If it's a case of "okay, we might have worn gears or a sensor might need adjusting", I'd make it more of a manual correction process.

Your overtravel and 'resilient and reliable' descriptions are almost word for word the method that I have personally decided upon. Quite reassuring!

I think my biggest decision to make would be the choice between auto-referencing or manual referencing in the event of losing encoder position. It's always nice to automate but given the potential circumstance and rarity of it occuring, a manual operation isn't a bad idea.

 

[ASF]

I would 100% give operator the ability to manually jog and set positions. Human eyeballs are much more precise than proximity sensors sometimes. Of course you may need to restrict exactly which operators you trust to do things like this, and it certainly wouldn't preclude me from also including an automated process, but having no ability to manually set things like that is just creating more reasons for people to call me at 3am and I don't like being woken up at 3am.

Perhaps an elegant solution might be an automatic homing process accessible to anyone, and a manual homing process accessible to supervisors only?

 

[Baxterr]

I would 100% give operator the ability to manually jog and set positions. Human eyeballs are much more precise than proximity sensors sometimes. Of course you may need to restrict exactly which operators you trust to do things like this, and it certainly wouldn't preclude me from also including an automated process, but having no ability to manually set things like that is just creating more reasons for people to call me at 3am and I don't like being woken up at 3am.

Perhaps an elegant solution might be an automatic homing process accessible to anyone, and a manual homing process accessible to supervisors only?

Semi-auto via HMI behind permissions.
Manual done via an attachable pendant.

 

[ASF]

I like that. I like it when people realise that "resilient and reliable" is worth many peanuts.

 

[Baxterr]

I like that. I like it when people realise that "resilient and reliable" is worth many peanuts.

Thankfully, my place of work also thinks this way. We're at a point now where we are nitpicking small details due to ironing out the creases over the past 1-2 years.

Many thanks for your input, and to everyone.

I'm still itrigued to see if there are any other contributions, however, there's only so many times you can reinvent the wheel...

That's a turntable pun...

 

[ggc]

I'm not normally a fan of non-standard sensors, but something like a Pepperl-Fuchs PMI360D-F130-IE8-V15 might remove the need for encoder rehoming while still saving a few peanuts. Would still need overtravel sensors in case of sensor failure, but non-contact 360 degree angle measurement sounds ideal for this situation.