Stepper motor homing sequence not behaving

[nealbert]

I wrote a little stepper motor homing routine and have found that it's implementation is anything but routine.  My application is a small vertical elevator that is moving a door.   When my device is at rest (everything de-energized) the door is at the bottom of travel (due to gravity) and is fully open.  When I energize the device, the first thing the operator needs to do is home the stepper motor.  (For safety sake I chose to force the Operator to start the Homing sequence by pressing a button on the HMI rather than initiating an unannounced homing sequence when the device is powered up.)   In this case Home means the door is fully closed.  The stepper motor needs to drive about 400 steps to close the door.  The number of steps is approximate due to manufacturing tolerances and the presence of a soft gasket on the face of the door.  Hence, the need for a homing/limit switch.

The routine I wrote is in the attached "Homing.pc6".  My idea was that I would start the Homing sequence by touching a button in the HMI (Relay1 or Start).  This starts the "Homing" Custom Function. I first set the step motor speed using the STEPSPEED command, then jump into a while loop that is running the STEPMOVE command.  I would exit the While look as soon as the door tripped a limit switch (Input[1]).  Once I exit the While loop, I issue a STEPSTOP command to immediately stop the step motor, then follow that with a STEPHOME command to set the new Home position.  At least in theory it sounded good.

Even on the iTrilogi 6 Simulator everything looks good.  Clicking on Relay 1 starts the stepper motor.  Clicking on Input 1 stops the stepper motor.  Great.   EXCEPT, I discovered that clicking on ANY input, stops the Stepper motor.  Hmmm!

So I moved to the hardware and discovered JUST THE OPPOSITE...The step motor starts like it should when I activate Relay 1 via the HMI.  However, closing the Limit Switch/ Input[1] (or any Input) does nothing.  The step motor keeps on going until it reaches a hard stop.  Or, you cut the power.  Ouch!

The Simulator and the real hardware do share one common trait...if ANY Input is closed when I hit the START Button (Relay 1) then the Step motor will NOT start.  Well, I guess I can throw out my Normally Closed E-Stop!

I've tried this code on iTrilogi versions 6.47 build 05, 6.52 build 03 and 6.52 build 05 and get the same results on all 3 versions.

I'm open to any and all suggestions.  I'm not too worried that the Simulator and the real world don't behave the same.  It would be great if they did, but I can work around that.  The main thing I need is a working, repeatable, reliable Homing Sequence.   At his point I don't know if most of my problem is with my logic or the software.  

[garysdickinson]

Your program appears to be a single ladder logic rung that will invoke the custom function, "Homing", on the rising edge of the RELAY, Start.  Nothing wrong with this...

This is your entire Start CF:

STEPSPEED 1, 100, 200

While Input[1] = 0
STEPMOVE 1, 400, 99
endwhile

STEPSTOP 1
STEPHOME 1

Your problem is with the use of the arithmetic statement, "Input[1] = 0", to determine when to stop looping.  Input[1] is a 16-bit integer where each bit represents one of 16 physical inputs 1..16.  If any one of these inputs is non-zero, then "Input[1]" will be non-zero and this will end the loop.

I suggest that you use the TestIO() function to return the value of a single physical INPUT:

STEPSPEED 1, 100, 200

While TestIO(Limit_Switch) = 0
    STEPMOVE 1, 400, 99
endwhile

STEPSTOP 1
STEPHOME 1

There are several other problems with your code.  I will list the 3 most grievous:

• Your are polling for a physical INPUT in a CF.  This will lock up the PLC until the INPUT goes active.  I believe that it should not be possible to poll for a changing INPUT from within a CF. But I have been wrong, before.
• Your are issuing the next STEPMOVE statement before the previous STEPMOVE comand completes the motion command.  This can't possibly work.  The 3rd parameter in the  "STEPMOVE 1, 400, 99" statement "99" is the RELAY that is set when the motion is completed.  I use this 3rd argument to control the sequence of events. I will issue the STEPMOVE in one CF and the SETSTOP stuff would be in a 2nd CF that is invoked when the RELAY goes active. This removes all looping in CFs.
• If you need to "home" the system, then you don't know where you are.  The 3rd argument in the "STEPSPEED 1, 100, 200", statement, has to do with acceleration.  If you don't know where you are, why would you want to accelerate? You should step no faster than the system can stop without losing steps.  I have been able to destroy low cost, hobbyist, stepper driver boards when issuing a SetStop command when the stepper running at full tilt.  The inertial load of the system caused the stepper to continue moving and the stepper motor acted as a alternator and produced very large voltage spikes that destroyed the protection diodes in the driver chip.

Best regards,

Gary D*ckinson

[nealbert]

Gary,

Thanks for the feedback.  I took your suggestion and inserted "While TestIO(Limit_Switch) = 0" in place of my "While Input[1] = 0"  Unfortunately, that didn't work either.  Hitting the Limit Switch did not stop the stepper motor.  So, taking your bullet points into consideration I re-wrote the code as attached.  This DOES stop the stepper motor when ever the Limit Switch actuates.  Hooray.

Basically, I separated the different functions into multiple CF's.  STEPSPEED is now defined in the Initial Scan.  STEPSPEED and SETSTOP/STEPHOME are in their own CF.  No more polling an INPUT from within a CF.  I also got rid of the While loop which was causing problems before.

I was planning on adding another STEPMOVE command to traverse my door quickly towards the home position, then slow down as the door moves towards the Limit Switch.  Fortunately, in my application the door is already moving slowly and is also moving against gravity, so when the stepper motor stops, the door stops very quickly.  My biggest concern was overshooting the Limit Switch due to system inertia and encountering a hard stop.  I never considered the voltage spike that could be generated by a high inertial load over-driving a stepper motor.  I have not encountered that, yet, but it's good to know.

Thanks again,
Neal Cooper

[garysdickinson]

Neal,

I am glad that you are making progress on your project.  Your code didn't get attached.  The Yabbse forum acts real funny with attachments.  They tend to vanish.

Stepper motors are deceptively simple.  The simple view is that for every step you issue the stepper will rotate a predicable amount.  Unfortunately the simple view is an illusion.  There are real-world issues with starting torque, holding torque, acceleration profiles, winding currents and micro-stepping modes.

1. The big issue with stepper motors is torque.  If a stepper is a rest and you issue a single step pulse, the stepper will move if the torque that it can generate is greater than what it takes to move the stepper's rotor and the attached load.  Torque is determined by the design of the stepper motor, the current that your stepper driver supplies and the step mode that your driver is using.

2. Once you can issue a single step pulse, the next problem is figuring out how long you have to wait to issue the 2nd step pulse.  You trying to figure out the maximum step rate without losing any steps.  If the stepper stalls and hums or if the system continues to move (inertia) after the last step pulse, you are stepping too fast.  You need to figure out this maximum step rate and cut it in 1/2.  This is as fast as you can operate without using acceleration / deceleration ramps.

3. Next you will run into mechanical resonance.  Stepper based systems can howl and scream at certain step rates and these are determined by a mess of physics.  To keep the noise down you can change the step mode of your controller (micro-stepping) rates like 1/4 or 1/8 might help quiet the system down. However, this reduces the starting torque and you will need to re-evaluate the maximum step rate without acceleration (step 2).  The other strategy is to run your system at higher step rates and you will need to figure out the acceleration/deceleration profiles to ensure that you do not lose position.

If you are using the stepper motor to move the door against gravity, you get into another stepper motor bit of physics, holding torque.  Most stepper motors use permanent magnets and this results in a motor resisting rotation when the coils are not powered.  Most stepper controllers, reduce the current through the coils when the stepper is not actively moving to reduce power usage. With no or low current it will be much easier for your load to move due to gravity.

If your system requires the stepper coils to remain energized to keep the door from closing due to gravity, you may need to use a much larger stepper and deal with the larger power supplies and the cooling issues to keep things from burning up.

I'd vote to counter balance the door.  This will increase the inertial mass of your system, but will require much less power to operate.  You might, also, consider a positive latching mechanism to hold the door open if living humans are going to use this gizmo.  I guy named Otis solved a bunch of these problems back in 1861.

Best regards,

Gary D*ckinson

[Lorne Van Dusen]

After reading this post I decide to add my comments as I am very familiar with the type of doors he is talking about.
They are vertical sliding doors that can either be a single door or two doors that meet in the middle and one goes up while the other goes down.
From experience I would not recommend using a stepper motor for that type of door control
Stepper motors by them selves do not have any feed back and therefore the actual position is really never known if the motor fails to step for any reason.
You can however use a lit switch at each end of travel one when the door is fully closed (Home Position) and one when the door is fully open then you can call a stop motor command on the rising edge of each limit.    
If the doors are properly counter weighted then a power failure at any position should not be a problem and yes it is wise to only cause a close or homing command when a button is pressed.
Your only problem is to insure that when you give a close command that the stepper motor will keep stepping in the down direction until it sees the lower limit switch open and when you give an open command the stepper motor will stop at the right count but will also reset if the upper limit is open.

[nealbert]

Gary, Lorne,

Sorry for the slow response, but I've been out of town for the past week taking care of some family business.  Anyway, thanks for the feedback and suggestions.  I did install a counter balance system to the door just before I went out of town.  This solves the problem of the door dropping like a rock when we lose power.  But, As y'all pointed out, it also lightens the load on the motor while moving (less chance of missing steps) and while holding the door closed (less chance of motor burn-out).

Right now there is only one limit switch and it is tripped when the door is closed.  The operator must Home the door one time when he/she first powers up the machine.  After the initial "Homing" I ignore the Limit Switch.  Since I am running open loop that is is a bit of a risk that the motor could miss a step or two.  If we find that the door loses steps then I could make the door "re-home" every time it closes.

So far the machine is working fine without a second Limit Switch (at the fully open position).  During operation, the door is never fully open.  The door is either fully closed or in some intermediate position between open and closed.  I might add a Limit switch to the fully open position just as an indicator that there was a mechanical failure ( belt broke, motor died, etc).

This machine is a prototype so we have lots to learn about it's performance.  But, just in case, I've already purchased a second stepper motor with a brake and a third stepper motor with a 50:1 gear box.  Better safe than sorry.

Neal

[garysdickinson]

Neal,

You have made good progress.  Test the mess out of your prototype system. The 2nd limit switch may help detect door open/close issues.

As Lorne has indicated, steppers may not be the best solution for your door actuator.  I think of your application as being similar to “power windows” in automobiles. Automotive window lift mechanisms have the following characteristics:
1. High torgue geared DC motors. Tremendous starting torque. And the gear train (often worm gear based) holds the windows in position when the motors are not powered.
2. They sense motor current to detect when the window hits either the full open of full closed stop position. They actually use a quadrature encoder on the motor shaft.  They use the encoder to calculate the velocity of the window motion. When the velocity hits zero the window quit moving. This is how they detect the up and down limit position.
3. The current sensing The encoder, also, allows them to detect windows that are blocked from motion by by either a mechanical failure or a human body part window is moving slower than normal. In either case the window control mechanism attempts to reverse course.
4. If the window controller supports an “auto up/down” operation, the mechanism includes some sort of encoder that keeps track of motor rotations so that the window, once calibrated, can be moved based on position feedback rather than depending on the motor current to spike when they hit the full up/down position.

My current crop of Honda cars have window actuators with theses behaviors and they need to be re-calibrated if actuator is replaced or the battery has been disconnected. The calibration procedure is pretty simple, lower the window and then raise it and keep holding the “up” button for a couple seconds after the window gets to full the full up position.

This a link to a low cost geared-DC motor with a quadrature encoder:

https://www.servocity.com/26-rpm-premium-planetary-gear-motor-w-encoder

The PLC supports quadrature encoders. You can use two single pole double throw relays to get motor up, motor down, and motor braking.  Same number of I/O's that you needed for a stepper and 2 limit switches. And you get better feedback on where the door is positioned and if their is a problem the  prevents the door from moving properly.

Good luck with your project,

Gary D*ckinson

[Lorne Van Dusen]

I have attached a simplified version of what you will need to fully test your project
There is no wait statements or interlocking between the open and close as I didn't feel it was necessary at this point in time. However you can add a timer into each direction circuit to insure that the doors cannot be reversed to quickly. After the close cycle is done relay R10 will turn on which can then be used to start a timer used to prevent the Open Signal calling the Open Function and you will see that once the open is completed relay R11 will turn on that can be used to start a timer needed to interlock the close.  
I have allowed for a limit switch at both the Closed position as well as the open position
However you really only require the one for the closed position
You will need to look at the INIT custom function and change the speed in pulses per second as well as the accell rate see notes inside the function
Next you will need to set the required number of step pulses required to go from fully closed to fully open
For testing I set the position to 1,000 1/2 steps for the full open position
You can test this program on the built in simulator and view the results on the build in display
I hope this helps

[nealbert]

Gary and Lorne,

Thanks again, y'all are great.

Gary, thanks for the description of servo motion operation.  We discussed servo motors during our initial designsessions but I thought it would be more difficult and costly to implement.   I appreciate the link to the low cost servo.  I'm going too buy one so I can get familiar with their operation and control.

Lorne,  thanks for the code.  I've printed it out and at first glance it looks very similar to my code. (I can't seem to upload a *pc6 file).  I hadn't thought about adding a timer to the circuit to prevent changing directions too quickly.  On my HMI I have grayed out some of the buttons to prevent "operator induced accidents".  For instance, on my Manual Control screen, when the door is closed (all the way up) the button labeled "CLOSE" is grayed out so the operator cannot try to close the door more.  Also, in the HMI I have put limits on the numerical inputs so the operator cannot input step values that exceed the maximum step travel of the door..

I'm trying to make operation of this machine "fool proof", but as you know, the fools keep getting more creative and ingenious.

Neal