Best Practices for Limit Switch Shutting Down Motors

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings,

 

I am a mechanical engineer using an ATXMEGA128 A1U to control a system with a servo motor. This motor will displace an object attached to an encoder to provide position feedback. On either side of the travel range are limit switches.

 

Since this is my first time designing something like this and only have about 4 months experience programming AVRs, I'd like to ask the community in general about best practices when using limit switches.

 

I want the limit switches to stop what it's doing, turn off the motor, and turn on a red LED. I would then press a button to reset the system.

 

I think I need to connect the output of the limit switch to a pin and route it to the event system. Meanwhile, there is an ISR that is running which is driving the servo motor.

 

Any guidance would be appreciated. I will also appreciate suggested topics to study.

 

best regards,

Will

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a safety or damage issue involved?  IOW, what is the worst that can happen if the system doesn't respond to the limit switch?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the things I tell people like yourself when they're first venturing into embedded systems is to remember the mechanical world is slow compared to the microcontroller. So what does this mean? How far does your system move in a millisecond? Microsecond? I'd suggest 'not far'.

 

How fast can the switch react? If it is a mechanical switch, the reaction time is measured in milliseconds as there is mechanical bounce. Assuming the switch could react in a microsecond, there is the mechanical inertia of your system. How fast can you physically stop it?

So you need to keep in mind how fast your real world system can react.

 

For a point of reference, so typical reaction times:

small relay - 100ms

large contactor- >100ms

human reading a display ~100ms

A car engine rotating at 6000 RPM - that's 100 times a second or 10ms per rotation. Even with a major mechanical malfunction, they rotate a few times before stopping!

 

 

The point here is connecting your limit switch to the event system is probably overkill. Same with connecting it to an interrupt. These give you sub-microsecond response times.

Another real world issue, apart from mechanical bounce is transients. These are usually microsecond events due to switching motors, relays etc - if these couple into your limit switch circuit, you need to determine what is garbage and what it a real limit switch event. An example I came across was a turntable driven by a variablespeed drive and a motor/gearbox. there was a limit switch to stop the rotation at a given point. The problem was the turntable would sometimes stop at random positions. The cause was transients and the system designer didn't anticipate these transients.

 

There's an old maxim in computing - 'garbage in, garbage out'. So any inputs to your system need to be filtered both electrically and in software. So, for your limit switch, you would filter the input so that a state, say longer than 50ms is considered true. How far does you system move in 50ms?  To achieve this I normally would have a 10ms tick interrupt. All timing is derived from this. Your limit switch would go to a port pin with the required hardware to protect it against transient voltages and EMI. Each 10ms tick you read the pin state and count. This is called debouncing and there's a lot written here about it. If you read the same state 5 times in a row, we can consider that true. In many industrial PLCs (sound like you should be using these rather than making your own) , they allow you to adjust this time up to many 100's of milliseconds - sometimes you can have mechanical oscillations where things bounce a little.

 

Similarly if you have analog inputs - these should be filtered in hardware and in software. One example of this I saw is with an car ECU - the throttle position sensor had some interesting processing done on it that took me a little to figure out. The code would filter the position value then compare it with the raw value. If the signal was good, the two would compare closely, but if there was noise due to a fault with the sensor, they wouldn't. The system could detect a fault. Again - understand your system. If things happen faster (or slower) than you expect, then there is problem.

 

 

It sounds like what you're trying to do is build a programmable logic controller. You might want to do some research on these in terms of the features and how they work. They are just a microprocessor with the required hardware, power supply and code to do industrial control. Historically they use a language called 'ladder logic' and it is processed in a cycle. The controller reads the inputs, does the logic processing, then updates the outputs. Rinse and Repeat. The cycle time depends on the amount of processing, but usually it is in the range of milliseconds.

 

Another feature that is common is that they have 'normal' and 'high speed' inputs - again, this is to cater for slow signals like limit switches and pushbuttons, and high speed signals like encoders. If you have an encoder you'll normally take extra precautions with shielding etc to ensure to eliminate noise.

 

Other things to consider -

1. keep your signal wiring away from mains wiring

2. keep your signal wiring away from wiring that switches high voltage and/or high current

3. When using variable speed drives - religiously use shielded cable to the motor and ensure it is grounded correctly - how many times I have been called in to fix systems where this was not done. Even one guy tried to convince me that steel wire armour cable was adequate - No! Ignore this at your own peril. VSDs generate an enormous amount of interference if not wired correctly.

4. Do not ever rely on your controller for safety functions. Emergency stop is a legal requirement - keep it out of the controller. There are safety rated PLCs that can do this - legally. Designing safety systems is a whole new topic.

5. Further to #4. Have mechanical limits or interlocks. Things go wrong - ensure there is a plan B. Do not rely on a microcontroller to do the right thing everytime.  Required reading is the story of the Therac 25. More recently the Boeing 737 saga.

 

Here's something I wrote earlier:

 

https://www.avrfreaks.net/forum/...

 

 

I've implemented a number of industrial controllers using this framework. Even a simple servo system to rotate a large display board.

 

Hopefully I've given you an overview on how to approach your problem. Feel free to ask more questions.

 

 

 

Last Edited: Sun. Jul 7, 2019 - 02:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The worst thing that can happen is something can break. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Suggestions:

 

Use optical limit switches, not mechanical.  They're faster, and can put up with overruns without wrecking themselves.  They also have much more repeatable travel distance before tripping.

 

Include hard stops beyond the optical limits.

 

When 'homing' the system, move to the limit (slowly!) then back off and keep track of what your position is supposed to be in software.  Any touching of a hardware limit switch during normal operation should be considered a very serious error.  Turn on your LED when you've hit the software limits.

 

Akin to Kartman's #4, if there is any possible risk to life, limb, or something else valuable, include a hard power disconnect.  Note that servo motors will stop faster if you short their connections together, not just disconnecting them.  Stepper motors are pretty good at stopping on their own.

 

Have fun, S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use optical limit switches, not mechanical.  They're faster, and can put up with overruns without wrecking themselves.  

Or possibly hall-effect (magnetic), since they are immune to dust/dirt...depending on your situation & needs.  This is what is used on anti-lock brake rotors/hubs ...the road is a tough environment.

 

In some cases, you may need to consider redundancy (such as dumping buckets of molten steel).   It is nice if the switch is normally closed...then you can check if the wiring has become disconnected/broken.  There are fancier schemes to detect shorts.

 

Also, if the limit is  stopping the system,  how do you allow it to move?  Probably only allow the opposite direction (otherwise always stuck at the limit).

 

 I would then press a button to reset the system

Remember, the limit is still being exceeded & you want it to still enforce its safety effect.

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Optical has its merits, but I'd avoid using optical in an industrial setting - dirt etc ruins your day. Really, for simplicity, it's hard to beat the old microswitch - you can see, hear, touch, feel the operation. Next would be inductive sensors. These are pretty cheap these days, but they sense metal. Most have a little led so you can see when they're activated. Nevertheless, my comments regarding filtering/debouncing the inputs still stands - even without mechanical switches. The other nasties - EMC, transients , lightning and static discharge are still problems that filtering/debouncing solves.

 

 

Or possibly hall-effect (magnetic), since they are immune to dust/dirt...depending on your situation & needs.  This is what is used on anti-lock brake rotors/hubs ...the road is a tough environment.

Most of the anti-lock systems I've seen use reluctors. No silicon involved. You can't get much simpler than a magnet and a coil of wire. Easy to test in circuit. Reluctors are great for measuring rotating things. No good for static or slow moving things. I've not seen too many hall effect  limit style sensors in an industrial setting. I'm quite sure there are - current sensors for one are commonly hall effect. Many of the new rotation and angle sensors are hall effect as well.

 

The average industrial inductive sensor is a simple oscillator and coil that gets detuned in the presence of metal. There's also capacitive sensors as well. Many of these are two wire and they vary the current for on/off.I've seen a few people get tricked by the apparent simplicity of this - in order to work, they need to drop enough voltage across themselves. This gets added to your relay coil voltage to get a minimum loop voltage. Many try to use a 24V relay with 24V supply but ignore the few volts drop across the sensor, so the relay is either unreliable or simply doesn't activate. Then there's the three wire ones - pnp or npn. That causes some confusion as well. Have I had experience with these??

 

 

Recently, I've been dismantling a conveyer type system. Built like a tank! There's plenty of inductive switches, VFDs, motor/gearboxes etc. There's also a few Sick brand optical gates in the mix. The whole thing is controlled by a Beckhoff automation system. Very expensive. Our friends at Microchip have a few parts in there - PIC24s. The sensors are all ASI bus items. The Beckhoff system has a little PC104 mini PC running the show with module comms done by EtherCat then down to K bus for the simpler i/o. There's a few safety i/o modules in the mix as well. Would've been worth 10's of thousands back in 2000.

 

 

Last Edited: Sun. Jul 7, 2019 - 04:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have relays which are connected to the servo power and will shut it down. What I want to know is what should I do in the software realm?

There's going to be a loop running, then the limit switch is hit. There's an ADC sampling an input and a DAC outputting to a servo amplifier. What should I do with thosrre bits of code? What is normally done in the real world?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What to do? Tell your servo loop to de-accelerate when the limit switch is hit. Remember - you can't stop the motor 'instantly'. As far as your servo code is concerned, it doesn't know or care about a limit switch, It should simply respond to commands of acceleration, speed and position. A limit switch simply tells it to de-accelerate quickly. The limit switch is the first warning. If this fails, you have another limit switch to disable the power or have a mechanical stop and current limiting on the servo drive. Either way, the system should fail gracefully.

 

Last year I was refitting the control system on a friends cnc milling machine. The limit switches did what I described above. In testing we would overrun these limits. The mechanical stop did its job and the servo drives tripped out. These were 1kW servos, so they could easily do damage.

Last Edited: Sun. Jul 7, 2019 - 05:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Best practices for mechatronics that can or does create harm, loss, damage, and/or fraud are :

  • safety standard
  • coding standard
  • code reviews
  • regression testing
  • static analysis

The safety standard may require that hardware safeties override software; if not in the safety standard then in the system specification or an agreement between you and the customer.

Unfortunately, XMEGA AU doesn't have XMEGA E's XCL.

Given : XMEGA CPU operates in parallel with XMEGA PDI (all XMEGA) and XMEGA DMAC (most XMEGA)

Proposed : debounced limit switch generates a limit event to DMAC which writes safety override data read by software (relay control) (hardware writes, software reads)

Not completely hardware so do at least a code review of DMA and relay control.

 

in XMEGA AU Manual (page 24)

 


Firmware Update v18.03 | Barr Group

(2/3 page)

The State of Embedded Systems Safety

AN_42083 AT01084: XMEGA E Using the XCL Module via ATxmega32E5 - 8-bit PIC Microcontrollers

ATxmega128A1U - 8-bit AVR Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El_Cuc0 wrote:
I would then press a button to reset the system.
Make certain the servo goes in the opposite direction; my experience was I had to manually rotate the limited axis away from the limit switch then the result of the typical "reset" was to zero the rotation.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Similarly if you have analog inputs - these should be filtered in hardware and in software. One example of this I saw is with an car ECU - the throttle position sensor had some interesting processing done on it that took me a little to figure out.
The lesson I learned from the mechanical engineer is that the hydraulic pump's pressure will have an expected oscillation about a normal bounded value.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Nevertheless, my comments regarding filtering/debouncing the inputs still stands - even without mechanical switches. The other nasties - EMC, transients , lightning and static discharge are still problems that filtering/debouncing solves.
fyi

Bounce Free Switches Pushbutton and Micro Limit Switches (LogiSwitch)

due to

http://www.ganssle.com/tem/tem353.html#article6

http://www.ganssle.com/tem/tem354.html#toolsandtips

 

"Dare to be naïve." - Buckminster Fuller