Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Feedback monitoring!!

Status
Not open for further replies.

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
I'm looking for idea's.....

I have a H bridge.... I move the H Bridge with PWM and monitor the position with a basic potentiometer...

The customer fitted a slightly different load ( in this case spotlight ).. The load is driven by an inverter circuit which rocks the Vsup of my micro!!! I have all the safety features built in for crash reset... Making sure everything works as it should, but last week the motor went mad and crashed two plates with semi dire consequences...

Out of this came the problem of "What happens when the feedback is lost" ( someone didn't engage the pot properly) and my "Safety net" failed..

Question:- How to tell if the feeback is stuck and halt all operations.... I have struggled a bit as the CCPCON is totally variable and if I detect the movement of the pot ( or lack of ) within a time period... I get too many false trips when I monitor for 1 second and crashes if I leave it for 2~3 seconds... At the moment I assume the pot would have moved several bitcounts and act if it hasn't, but one of the pots has to move quite a bit before its detected...

There must be a better way... Perhaps a simple PID algorithm???
 
Good EMI design is critical. SPotlight may have 10x surge currents.

Intelligent feedback is useful. Such as analog or pulses or data echo with parity.
Lack of feedback must always fail safe mode.
 
Your reminding me of my experiences. One with HP X-Y recorders. They needed lubrication. They operated in a servo mode and when they slammed, they slammed.

In one of my other lives, I did a simple UP/Down positioning system with a small pot, BUT wit additional sliding contacts. Thy could cause movement, but it wasn't a problem.
Limits were one way or maybe I solved it with a cap. Dunno.

In another super simple case, I did sense motor over-current over an integrated time and that killed power. Power recycle was necessary to fix/

In other cases an slip clutch was used and some were adjustable.

==

Monitor/control velocity and/or acceleration? Limit switches. Springs one the end. Then there is the equivalent of a shear pin for protection. e.g lawn mower, propeller.
 
Its weird... The motor stall torque is quite low, so I'm astonished that it caused this issue...

Limit switches are not feasible.. I have suggested an external current detection to shut down the bridge, but hat has fallen on deaf ears... I will push for this extra circuit as I know this would be the best way forward, but the company has pushed for this "Pot" fail safe ( I think purely for the D**k that set it up wrong )... I will persevere on Monday to make something a bit more robust!!!
 
current detection
That would be the way to go without a limit switch or a encoder wheel the pot could be jumping in dust.
encoder wheel could tell if it's moving and even when you hit the end just count the slots up and back down.
 
I'm currently waiting for customer feedback at the moment... I have put into place a basic monitor but both axis move at different rates... They only complained once about false triggering so its down to minor adjustments now... I have suggested a thermal fuse to prevent the next crash and it looks like they are in agreement!!!

Lets see how it pans out!
 
Could you use a dual-gang pot and compare their position signals?
 
Could you use a dual-gang pot and compare their position signals?
PCB's are already in production.... So I can't make such changes..

We have agreed on a compromise.. On initial startup, I will move the motors left / right then up / down and determine the pot conditions before passing control to the user!!!

He is also going to use a resettable thermal fuse...
 
I thought I'd let you all know that my algorithm did actually work!!!

Here's the thing....
Code:
Check axis feedback..
after X milli seconds of motor movement.. Re-check axis feedback..

if feedback moved
    all is okay.. Continue
else
    all is not okay.. Throw error!!

What happens is.. If you move the motor to the left, the cycle counter counts the allotted milli seconds.. If you change direction too quickly and the "Over the center" isn't detected.. It carries on the count, thus the new direction count is far too short!! False trigger... So.

Code:
Check axis feedback..
if direction changed reset milli second count
after X milli seconds of motor movement.. Re-check axis feedback..
if direction changed reset milli second count
if feedback moved
   all is okay.. Continue
else
    all is not okay.. Throw error!!
 
I logged in especially to Congratulate you Ian. Well done :)

Till later good person :cool:
 
I'm looking for idea's.....

I have a H bridge.... I move the H Bridge with PWM and monitor the position with a basic potentiometer...

The customer fitted a slightly different load ( in this case spotlight ).. The load is driven by an inverter circuit which rocks the Vsup of my micro!!! I have all the safety features built in for crash reset... Making sure everything works as it should, but last week the motor went mad and crashed two plates with semi dire consequences...

Out of this came the problem of "What happens when the feedback is lost" ( someone didn't engage the pot properly) and my "Safety net" failed..

Question:- How to tell if the feeback is stuck and halt all operations.... I have struggled a bit as the CCPCON is totally variable and if I detect the movement of the pot ( or lack of ) within a time period... I get too many false trips when I monitor for 1 second and crashes if I leave it for 2~3 seconds... At the moment I assume the pot would have moved several bitcounts and act if it hasn't, but one of the pots has to move quite a bit before its detected...

There must be a better way... Perhaps a simple PID algorithm???


With a higher mass load on servo, feedback might improve with PID filtering so that you regulate the amount of acceleration and thus current consumed.

Good servo designs will have a maximum torque or current limit, a maximum velocity limit and an then position error limit for "Seek complete"
This is how disk drive servos are designed to achieve optimum speed , and minimum overshoot in minimum time.
 
The trouble with this thing is the pot resolution was very tight!!! After three seconds (real slow) it would increase @ 4~5 bit counts... so trying to achieve a reasonable PID would have been close... The tolerance and backlash from the pot and gears is just enough to get any accuracy at all... Its working as it should now, so for the time being.. There it will stay!!
 
Every servo problem has a solution but requires that you define each parameter of gain, backlash and sensitivity then define the required stability for error.

Until then you must accept your limitations.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top