Host Engineering Forum
General Category => CTRIO and CTRIO2 => Topic started by: Dan R on September 23, 2014, 03:46:24 PM
-
I'm using the IBOX load profile instruction to run a parallel synchronous pick and place system using pulse (step/direction). My homing search profile works well but the limit 1 options are limited to channels on the CTRIO card itself. In this case - Ch1C. Since I intend to use encoders for both motors (fed through the one CTRIO card) I will be using the Ch1C input with one of my encoders. I'd like to use this simple IBOX Load Profile instruction with my Limit 1 input as a simple DC input from anothed card in my PLC rack. Is this possible using the IBOX instruction with say input X1 from a D2-16ND3-2 card?
-
Sorry, no. In order to deliver the tighter timing that is expected from a high speed module, it is necessary for the I/O to be directly on the module itself.
You could certainly use a velocity profile and control it from PLC logic. For homing that might be fast enough.
-
I'm back at the H2-CTRIO(2) phase of the project after installing the two drives onto the machine (press). As a test I have an S-Curve profile and Trapezoid Plus profile loaded plus a Home and Jog circuit. My HMI allows me to test all these profiles in a Test mode (press is idle). Also, in the Run mode (press is cycling) I can test the Trap & S-Curve profiles alone. In the Test mode I can move the drives without an issue by means of the HMI's screen push-buttons (Up & Down). But when the press is in the Run mode, the pulse signal that initiates the S-Curve or Trap profile will either allow the drives to run as they should (down then up with each press cycle) or they move the short distance in the opposite direction, reach their max travel proximity sensors and stop due to logic. And to further complicate things, when I enter the Run mode and select the Trapezoid profile, only the S-Curve now operates - and occasionally it faults out due to opposite travel (max travel proximity sensor). My Trap profile seems to be ignored even though the logic shows that's the profile selected.
My ladder logic shows all profiles have successfully loaded per the IBOX control bits. Likewise, none of the IBOX fault bits show faults. So all my profiles are loaded and I select which one is to be used through the ladder logic. Only one profile is programmed to run at a time, e.g. in RUN Mode with TRAP profile selected - both drives run up, momentary delay after full travel per the pulse train value, then both drives are to move down full travel. That's one press cycle. I enter the pulse train length through a numeric data entry.
Sometimes this works in the RUN Mode, sometimes not (by moving in direction opposite to the intended direction and reaching max travel).
Not sure what's going on here. Any idea what might be causing this erratic action?
-
Can you post your project file or send it to me, I'll take a look at it.
-
Will do Monday. Using the IBOX instruction to control the CTRIO outputs is the Reset instruction required? I'm not using it in my program.
-
I now realize where my problem was. That being the CTRIO's pulse train only runs once per load command. I read that before but I thought that since my success and error bits remained true (after the pulse train completed) I didn't need to repeat the IB-1001 CTRIO Load Profile ibox instruction each time I wanted the stepper motors to actuate. I was relying on logic of the success and error bits (within the ibox instruction) along with other logic (found in my ENABLE OUTPUT output bits for the CTRIO)when attempting to put the motors in motion. When I added a store positive differential contact to each of my IB-1001 Load Profile rungs at the beginning of my program, the motors actuated as intended when the machine went into its run mode.
I should have read that chapter more closely. But I still don't know for certain if a RESET bit (output) rung is necessary for ibox instructions. Maybe I should read on. :o
-
Dan R: "I now realize where my problem was. That being the CTRIO's pulse train only runs once per load command."
Actually, more accurately, you can repeat the pulse train by simply toggling the Enable Output bit (ON --> OFF --> ON).
Dan R: "But I still don't know for certain if a RESET bit (output) rung is necessary for ibox instructions."
Not entirely clear what you mean by this. The CTRLDPR IBox executes once and runs to completion each time it is enabled. That instructions copies the configured table from CTRIO RAM into its operating RAM for the particular CTRIO output you designate. After it is completed you need to enable that output with the Enable Output bit. That's when the pulse profile will execute. To execute that profile again you do not have to reload it (re-execute the CTRLDPR IBox), instead, as I mentioned above, you can reset the Enable Output bit OFF and then set it back ON.
-
Strange thing now seen - both drives are inching from their stop points but in one direction only. The program is rather straight forward. The steppers are driving linear belt drives. Both drives start in the up position (top dwell position),then downward travel (100,000 pulses), then bottom dwell for half second, then upward travel (same 100,000 pulses), then top dwell again for same half second, constantly repeats cycle of down, wait, up, wait, down... One drive motor must turn clockwise while the other turns ccw in order for them to travel parallel & synchronous.
What I see is motor "A" slowly inches upward each cycle from its stop point in the top dwell position and motor "B" slowly inches downward each cycle from its stop point in the bottom dwell position. The "inching" distance is equal for each motor. I tied in an encoder to monitor the position for motor "A" and programmed in an up/down counter. The down stroke always gave me the exact 100,000 pulse reading as what I have programmed in the Trap+ profile. But the upstroke always ends with 4 pulses displayed. Every stroke the accumulated value at the end of the upstroke has another 4 pulses added. 4, 8, 12, etc. This happens for motor B in the bottom dwell position.
Any idea what might be resulting in the 4 pulse incremental offset?
Also, I'm using a brake on each stepper motor as a safety device to prevent travel when employees are setting up the machine. Is it not advisable to make use of the brake to assist in accuracy? Would I be overtaxing the brake by cycling it on every time the stepper motor Enable Output is energized?
-
What is the resolution of the stepper motor?
-
2000 step/rev
The drive is Automation Direct's STP-DRV-4850 configured for pulse & direction.
-
Is the move repeatable or is the error accumulative?
-
Accumulative. 4 pulses each cycle.
-
Are you 4 pulses short when you come back to top stop or over shoot by 4? How is your inertia match with the load? Is it possible to try it with no load, only the motors running?
-
Yes - 4 pulses short. I had just altered my inertia to a default of (1.0 x rotor inertia). Under the motor config I have set up for my NEMA 23 motor: holding torque 2.0Nm, max A 5A, rotor inertia 0.48Nm, waveform smooth 25,phase 0,max volt 100%, max lead angle 120 at 25 rev/sec
idle current delay 0.40 sec, idle current % 50%, load inertia 0.497 kgcm2, wave smooth off
-
You are using a trap+ profile? Are you using encoder feedback?
-
I am using a trap + but have not yet made use of encoder feedback for positioning - just for readout
-
I had just altered my inertia to a default of (1.0 x rotor inertia).
I was asking if you calculated the actual load inertia of what the motor sees. That parameter you set tells the drive what the reflected inertia is. There are motor sizing programs that you can use to calculate this. If this mismatch is too great, you will see problems like this. That is why I had asked if you tried the moves with the motors disconnected from the load. If you have the same problem then I would say that it is probably a programming issue. If it disappears, then I would look at your motor to load inertia ratio and see if it could be reduced by using a gear reduction. If I had a photo of your setup, it may be more helpful. Sometimes also, micro stepping can be inaccurate. Basically it is a 200 step motor where there are 200 locations where the motor's holding torque is the greatest. They get the micro step positions by adjusting the current in the windings. If there is a force on the motor and it ends up at one of the weaker step positions, it might pull it back some and you loose steps. When the motor is first energized, it will jump to a stable position. Try to realign your end position on one of these stable points.
-
I didn't have the opportunity to pull the motors to test like you suggested. I'll try over this weekend. My load inertia was calculated earlier and motor sizing software was used by the sales engineer who I ordered these NEMA23 steppers & belt drives from. I've changed the pick and place head design that I'm anchoring to the drives. The weight has increased a little (from 15 oz to 23 oz) but my X dim reduced from 4" to 2.5" and my Y dim reduced from 2" to 0" (flush mounted on drive head). I do see that I need to adjust my load inertia value entered into the motor setup software. I'll test this too over the weekend as the machine is going through some guard work as we progress with the whole package.
It just seems strange that the offset is equal but in opposite directions. I'm concerned about the stepper accuracy statement you made in your last message.
My top out position (top dwell) is only about 200 pulses from my travel limit switch that I use as max up travel (and Homing) that I could actually home it at top dwell every cycle. The position at top dwell will never change in this machine and I might have enough dwell time to actuate a Homing profile before the down stroke is initiated. Doing wouldn't stop the ~ 4 pulses being left but it would clear the cascading offset from cycle to cycle.
Thanks for your input.
-
For chuckles, would you please check your H2-CTRIO2 gate array and firmware versions?
And are you so far into this that changing to a Do-more controller is out of the question? I can't stress strongly enough how much easier this would be with Do-more...
-
When the micro stepping first came out, the company I worked for ran some repeatability tests. If I remember, and it has been a while, the best repeatability that they saw was at best a half a step,no matter what the micros stepping was set to. Maybe the companies selling it can do better in perfect lab conditions, but we didn't see it. Any time I use them, I set the resolution at 400/rev and go from there.
If you can lock the tooling into the top stop dwell position, then loosen the coupling to the motor. Power it down and up. That should put it in a stable position. Then tighten the coupling.
-
Bob O,
I'm not sure where to find the gate array info. Here is other CTRIO info: firmware - H2CTRIO2_1_0_0,workbench version - 2.2.1, file version - 2.2.1.4, hardware rev - 4A.
I'd prefer not to change the controllers until I know if a stepper application can't do the job for me. It seems that it should. I just need to eliminate the cascading error. I can live with about 0.015" swing either way at the end of travel but if the error causes by start point to get further away every cycle, it won't do the job.
-
in CTRIO Workbench, the Booter Version is the Gate Array version for the CTRIO2.
-
Gate Array - 1.5.0
OS Ver - 1.0.3
-
A few questions:
1) What is the difference between Trapezoid Plus & Dynamic Positioning Plus profiles? They look to be the same with the exception to the "Target position is specified at run time through Parm 3."
2) I'm now configuring my input in Workbench for a Quad Counter. My output is Pulse (step/dir) as stated earlier in this thread. I already have my Trapezoid Plus profile programmed but now I'm going to click on the Use Encoder for Position option. This is then looking at my Quad encoder I set up in Config Input section. So if there is backlash (overshoot) will the stepper reverse direction to the encoder value I desire? I guess that's what a servo is for.
3)Up to this point (no encoder used yet for position - just reading pulses counted), when my indexer heads travel downward they count to 100,000 pulses as desired. When they move upwards on command, the pulses count down toward zero. But this is where I see the 4 pulses left over and my CW turning motor inches up and CCW motor inches down (cascading error). If it's a logic problem, how would the encoder as an input be anymore accurate than a preset pulse train output of 100,000 pulses?
Any thoughts upon reviewing my program?
-
1) What is the difference between Trapezoid Plus & Dynamic Positioning Plus profiles? They look to be the same with the exception to the "Target position is specified at run time through Parm 3."
Dynamic positioning allows multiple target positions. The trapezoid is a single move. DynaPos is a poor man's axis.
2) I'm now configuring my input in Workbench for a Quad Counter. My output is Pulse (step/dir) as stated earlier in this thread. I already have my Trapezoid Plus profile programmed but now I'm going to click on the Use Encoder for Position option. This is then looking at my Quad encoder I set up in Config Input section. So if there is backlash (overshoot) will the stepper reverse direction to the encoder value I desire? I guess that's what a servo is for.
It closes the loop on the encoder position, within the specified deadband. It will reverse if needed.
3)Up to this point (no encoder used yet for position - just reading pulses counted), when my indexer heads travel downward they count to 100,000 pulses as desired. When they move upwards on command, the pulses count down toward zero. But this is where I see the 4 pulses left over and my CW turning motor inches up and CCW motor inches down (cascading error). If it's a logic problem, how would the encoder as an input be anymore accurate than a preset pulse train output of 100,000 pulses?
It doesn't sound like a logic issue to me...just a gravity issue. When you enable encoder feedback, the module closes the loop on the encoder so there is no cumulative error. We added the feature for exactly this issue...to prevent small amounts of slippage or mechanical lash from accumulating.
Any thoughts upon reviewing my program?
Greg has it. I haven't heard if he reached any conclusions.
-
Dan, I looked over your program and your CTRIO2 configuration and I don't see any obvious programming issues. I believe, like BobO pointed out, you simply need to use the Trapezoid Plus Pulse Profile with encoder feedback. This wouldn't require any programming changes. It is inherent in the Pulse Profile itself.
BTW, I gave you a call Monday, 19-Jan-2015 after 5pm Eastern time. Sorry I missed you. I'll try calling you in the morning (Tuesday, 20-Jan-2015).
-
For those browsing this thread, I talked to Dan R on the phone and he is going to try the CTRIO2's Trapezoid Plus Pulse Profile with encoder feedback enabled to see if this takes care of his accumulating error he is seeing on his machine. I also recommended that he experiment with moving his encoder to some place on his machine that it will indicate actual distance traveled instead of just having it connected directly to his stepper motor.
-
After the encoder hookup, I'm experiencing issues. When I cycle my Trap + profiles for the downward travel, the heads (indexer - belt heads)travel beyond their desired travel length. They proceed to the max travel proximity switches and stop. When I change my ratio in the encoder option under the Trap + profiles, I still exceed desired travel length but the rate of the heads change (speed up). This I believe is just the Accel taking less time to reach top speed per the profile.
What I did was since I have just the one encoder hooked up, I'm using it for both channels (1 & 2). So my encoder input "A" and "B" wires feed into the H2-CTRIO(2) at 1A & 1B. In Workbench under Config IO for Ch1/Fn1 & Ch2/Fn1 I have Quad Counter, Position Scaled selected. I have the Count In multiplier in 1x (but have tried 2x & 4x). I'm in BCD and left the default values in the scaling wizard for the Raw values: min raw value = 0cts, max rv = 10000cts, min scaled value = 0, max sv = 100. For my two parallel Trapezoid + profiles, I selected the "Use Encoder for Position" option and selected Encoder Input as Channel 1 for both of these profiles because I want just the one encoder hooked up to handle the control for now. My pulse count entry for both outputs is through Parameter 3.
Must be a scaling thing or units.
-
After the encoder hookup, I'm experiencing issues.
Does this mean you moved the encoder from being directly connected to the stepper motor to some other location on your machine that indicates travel distance?
When I cycle my Trap + profiles for the downward travel, the heads (indexer - belt heads)travel beyond their desired travel length. They proceed to the max travel proximity switches and stop. When I change my ratio in the encoder option under the Trap + profiles, I still exceed desired travel length but the rate of the heads change (speed up). This I believe is just the Accel taking less time to reach top speed per the profile.
This is most likely caused by not getting the "Scale Factor" parameter not set properly. You indicated to me on the phone that your motor was 200 ppr and your encoder was 500 ppr. If they were directly connected together that would be Output/Input = 200/500 or 0.4 as a "Scale Factor". However, if you moved your encoder to some other location on the machine then all the mechanical linkages and their gear ratios must be taken into account. I recommend you either calculate this or empirically derive it by moving the motor one rotation manually and see how far your encoder moves.
If calculating and it is belt-driven, then, for example, the diameter of the driven pulley vs the diameter of the driving pulley needs to be taken into account.
What I did was since I have just the one encoder hooked up, I'm using it for both channels (1 & 2). So my encoder input "A" and "B" wires feed into the H2-CTRIO(2) at 1A & 1B. In Workbench under Config IO for Ch1/Fn1 & Ch2/Fn1 I have Quad Counter, Position Scaled selected. I have the Count In multiplier in 1x (but have tried 2x & 4x). I'm in BCD and left the default values in the scaling wizard for the Raw values: min raw value = 0cts, max rv = 10000cts, min scaled value = 0, max sv = 100. For my two parallel Trapezoid + profiles, I selected the "Use Encoder for Position" option and selected Encoder Input as Channel 1 for both of these profiles because I want just the one encoder hooked up to handle the control for now. My pulse count entry for both outputs is through Parameter 3.
Must be a scaling thing or units.
Doing Position Scaling has to be taken into account as well.
Can you technically describe what your stepper is connected to and what your encoder is connected to and how one drives the other on your machine?
-
The encoder is fixed to the motor. For now I intend to keep there until I see how an encoder input controls my position.
I did make use of the 200/500 ratio as well as the 2000/500 ratio to see how they affect the process. The the travel length still maxes out for both ratios (and others that I experimented with).
This package consists of (in this order) a brake, an encoder, motor, coupling, belt drive.
Are you saying I must make use of the scaling wizard? I did set to position but didn't change anything with the min raw value, max raw value, etc. as they are relatively close to the parameters I'm working with.
-
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.
-
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.
-
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?
-
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?
-
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.
-
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.
-
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.
-
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?
-
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.
-
Slow speeds isn't as bad but still unacceptable. The faster, the less accurate.
-
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.
-
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.
-
And I know you aren't keen to change...but...all of this becomes much easier in Do-more.
-
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.
-
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.
-
For closed loop control, I like to equate it to Cruise Control in your car. You can set your cruise to 55MPH, but if you tie the feedback to the RPMs (motor drive), not the speedometer (tire speed, what you are trying to close the loop on), you will get results similar to yours, i.e. not accurate.
The encoder feedback for closed loop control must be tied to the actual thing you are measuring, not the motor side.
You can replace the motor, replace the tires, replace the transmission, and none of that will fix your Cruise Control. You gotta move the encoder from the motor drive to the tire (i.e. the other end of your drive system).