H2-CTRIO(2) IBOX Load Profile Limit input

[BobO]

Please do the following:
1. Remove encoder feedback.
2. Remove any scaling on the encoder.
3. Direct the pulse output to move 200 pulses (assuming it is 200 pulses per revolution).
4. Confirm that the encoder moves 500 pulses.
5. Reconfigure encoder feedback, setting the ratio to 0.4, with a deadband of at least 3.
6. Direct the pulse output to move 500 pulses. (When encoder feedback is enabled, moves are expressed in encoder units)
7. Confirm that the motor shaft turned one rotation.

[Dan R]

Well the encoder input is in play now.  When using the Monitor IO in Workbench and comparing to my numeric display I'm reading one to one.  But when I execute my Trap + profile for Up and Down,I'm seeing the stop point (top) changing.  I see that it adjusts in position from cycle to cycle but not as tight as I think it is capable of.  This is a 200 ppr stepper and every pulse equates to 0.0138".  As the belt head travels up and down, I'm seeing the stop point at the top swing as much as +/- 0.05".  The numeric display has the pulse counts moving with respect to this swing.

Rather than the motor compensating by going CW to count back to the desired pulse count or CCW to count ahead, the compensation seems to take place over a series of trap + moves.  So the position seems to be oscillating. I was under the impression that the motor rotates to correct at the end of the Trap profile.

I also made adjustments to my motor parameters.  This had no affect on the overshoot/undershoot issue I describe in this Post Entry but it did help in improving how smooth the head travels.  Unfortunately, occasionally the actuator head will stop in mid travel of the Trap profile and continue to move (creep) in the same desired direction but the motor makes a loud whining noise.  This must be an issue with the motor parameters.  But the values I entered are directly from the motor manufacturer. Possibly I'm Acceling to quickly. 
 

[BobO]

The trap will run until the deadband is satisfied. The deadband needs to represent the smallest encoder change per motor pulse. There is no compensation between traps.

Do you still have the encoder connected to the motor shaft? It really needs to be on the other end of the belt to remove mechanical slop.

What resolutions did you end up with, and what are your ratio and deadband settings?

[ATU]

  Unfortunately, occasionally the actuator head will stop in mid travel of the Trap profile and continue to move (creep) in the same desired direction but the motor makes a loud whining noise.  This must be an issue with the motor parameters.  But the values I entered are directly from the motor manufacturer. Possibly I'm Acceling to quickly. 

This is what is called "Falling off the torque curve"  You are trying to either accelerate too fast or attempt to make the motor move faster than the available torque will permit. You have to slow reduce the acceleration or slow down or both. Is there anyway to counterbalance the system?

[Dan R]

Reducing my acceleration and deceleration seems to have eliminated the stalling. I lost overall speed, but I'm likely able to operate at this slower speed.
Thanks. I'm going to make other changes and will report results.

Bob, I'm at a 4X setting for my quad encoder value in Configuration IO. My encoder deadband is 5 with a 4 ratio.
For now, the encoder is still on the motor.

[BobO]

Bob, I'm at a 4X setting for my quad encoder value in Configuration IO. My encoder deadband is 5 with a 4 ratio.
For now, the encoder is still on the motor.

Encoder was 500ppr, so with 4X you are now seeing 2000ppr on the encoder...and stepper was 200ppr, but you had it configured to be 2000ppr, correct? If so, your ratio should be 1, and the deadband could be 1, or even 0.

[Dan R]

Yes, I had experimented with several combinations including the parameters you stated.  I even went with a ratio of 4:1 to see the closed loop feedback.  The belt drive's actuator head oscillated up and down over a few inches as it found its home.  Right now, the gentleman from ATU's point of "falling off the torque curve" is what I have to address.  I'm going to reduce the weight of the actuator head. 

All the input from this Forum has been extremely helpful.  I appreciate your help.

[Dan R]

Upon further work, I'm still seeing inaccuracy.  I know the recommendation is to move the encoder from the motor and place it on the drive but I would think that the motor-mounted encoder setup would provide better results than what I'm seeing. To go an extra step, I removed the pick & place actuator head from the belt drive's carriage - to make the carriage as lightweight as possible.  I have a reset value of 10 and a pulse count payoff of 13000. My deadband is 0, ratio is 1, encoder at 4X.  On my CMore I'm reading the pulse counts as well as the time of the Trap + moves UP & DOWN (independently). I'm also viewing the pulses on the Monitor IO from Workbench. 

When I run the Trap + profile for the down stroke, I see my pulses start at 10 and count toward the 13000 value I entered.  I know that ideally, this value should end up at 13010 (13000 + 10).  It doesn't.  The value is any where from +/- 25 pulses.  The first few cycles the value is only off by ~ +/- 5 but it climbs and drops and climbs randomly.  The same applies in the up stroke travel results.  I can see my travel timers moving all over the place as the feedback kicks in.  I can even see the carriage move backward or forward ever so slightly. Typically, I'd see about a 0.8 sec up stroke & down stroke.  But as my position strays and feedback attempts to adjust, the timer value for that move can exceed 1.7 secs.

At this point I'm not certain what else I can do other than attempt to run a Homing move every time the carriage reaches its top position.  I can live with the minor inaccuracy the first few cycles and by running the Home move, I'd keep resetting to a near equal start point each cycle.  However, I don't know if I can perform this extra move during the top dwell due to a lack of time available during dwell (~ 0.5 secs).

Would another profile option (To Position) do something better for accuracy?

[ATU]

Have you tried running the system only at your base speed? If you can't get an accurate move then, there has to be something else going on.

[Dan R]

Slow speeds isn't as bad but still unacceptable. The faster, the less accurate.

[ATU]

Base speed is the starting speed for the motor. If you can't get it to work at that speed with no accel ramps, then it will never work at any other speed.

[BobO]

Would another profile option (To Position) do something better for accuracy?

I'd use DYNAPOS+. The basic trapezoid quits spitting out pulses once the target plus/minus deadband is satisfied, but the system can easily move after the fact. Dynapos+ basically becomes an axis, and will continue to adjust the position to stay on target as long as it is enabled.

[BobO]

And I know you aren't keen to change...but...all of this becomes much easier in Do-more.

[Dan R]

DO MORE - That's what I'm doing.  Ha

The stepper motor and belt drive company I'm working with provided me with an RA# and I sent the equipment back for inspection.  The sales engineer was here today to see the problem first hand.  They are providing support just as you all have too so I'm in good hands.

Bob - I reprogrammed my RESET slightly so that it does so after the 2nd move with the press cycle - that being after the Trap up-stroke move (1st move is down stroke, 2nd move is equal up stroke). I also changed my deadband to 5. When cycling, the encoder pulses are now reading much tighter (within 0 to 3 pulses). But the higher the speed, the more the pulse counts strayed - much tighter than before this modification. The one gentleman in this forum who suggested a test at base speed said if I can't hold the accuracy at that speed, there's something else wrong.  I still see the pulse count move with next to nothing for Accel & Decel and low Hz but again, the slower I go, the more accurate it is. 

Even after changing the logic to the reset and going to a deadband of 5 where the pulses are reading on the display accurate, in time my actuator head still inches away from the desired start point.  With this tighter accuracy on the readout, the encoder isn't automatically enabling the motor's output to find the preset pulse count.

Maybe there is something damaged in the belt drive. It will be ~ a week before I get the equipment back.

[Greg]

Dan R, I keep reading all these conversations and I still believe there is a fundamental disconnect here. If you are wanting to measure some distance accurately, putting the encoder on the motor that is driving the system is fundamentally wrong. The encoder should be used to actually represent the distance that the actuator head is actually moving. It should be connected to a "cog" in the system that is closest to the actual actuator head movement, preferably on the other side of that belt (which notoriously slip and stretch). Putting it there would give the CTRIO2 a more precise representation of the movement. And calculating the ratios is still, of course, necessary, but easy to do. The motor moves "this much" and that results in "this much" movement in the actuator head.

That's my 2-cents worth.