What VIs should I be using to program a motion profile given seven discrete displacement-time points of the profile using Labview (7.0) and a PCI-7344 motion controller?

[jk_astroinst]

I have a motion profile defined by seven discrete displacement-time coordinates (one at each end (start & finish) of the move, and five at regular time intervals during the move), the constraint that the initial and final velocities are zero, and an assumption that the accelerations are constant between each discrete defined displacement-time coordinate. Which Labview VIs would be recommended for programming this motion profile? We've used the Start/Stop Motion VIs at the ends and the Blended Motion VIs for the "middle" moves, but the results haven't been what was expected. We may need some help with the
parameters associated with these VIs and their proper application. The moves take longer than anticipated. There seems to be a problem when the velocity is constant during an interval, meaning that the accel/decel is zero; I'm guessing that the program doesn't like the zero values for accel/decel? Any help or suggestions out there in the way of recommended VIs or explanation of the parameters with the above named VIs (Start/Stop Move & Blended Move)?

[Scott_R]

jk_astroinst,

The acceleration/deceleration values in MAX and LabVIEW pertain to the process of beginning the move and concluding the move. Those values describe the rate at which the axis achieves the velocity that you have prescribed for it. Each step of the motion will follow a trapezoidal motion profile, moving from a zero-velocity to your target velocity (at a rate equal to your acceleration) and then slow down as it approaches the target position (deceleration).

Without using blended moves, the velocity will decrease all the way to zero and then start the next move. Using blended moves means that the motor will smooth the transition into the next move by decelerating as it approaches the first position and then accelerate into the next move prior to re
aching zero velocity.

If the time value is regular over moves of differing distances, then you will need to vary the velocity for each move. To achieve the time that you want, you can increase the acceleration or the target velocity.
It sounds like you are using the proper VIs for this move. For information regarding the parameters for each VI, activate the context help and then hover your mouse over each VI and select "Click here for more help" The resulting window will have information regarding the datatypes and use of each parameter.

Take a look at the context help, and let me know if you have any questions about particular parameters, or if you have any additional questions on this issue.

Regards,
Scott R.
Applications Engineer
National Instruments"

[jk_astroinst]

Scott-

Thanks for the reply. This is the same issue that I created a support request number for of 7054946 on NI's website. I'm assuming that the Scott I'm dealing with on that # is you. Anyway, I hope that's not a problem. I was hoping someone else out there might have some experience or thoughts that might be relevant.

Per the message I left you last night (9/1/04), I didn't have any success at all running the step response to check the PID control loop parameters, as before. When we configured our motor drive for the motor in this application, and ran an autocommutation process, (another process where current is applied to rotate the motor for a short time like the step response function in MAX), we noticed a very high cogging or detent torque that had to be overcome. Typically, according to our motor drive manufacturer, about 1 A of current is sufficient for this autocommutation process. For the motor in our application, however, we needed to apply almost 5A to overcome this detent torque. I'm wondering if there's a way to increase the current sent to the motor during the step response function in MAX, and if so if perhaps this would allow the step response function to work with our motor? Please let me know.

While I think that the PID loop parameters may indeed be able to be improved, I feel that they are close enough that they aren't causing the problem that we're having with the motor stopping at the high velocities and accel/decels that we spoke about yesterday by phone. When I do moves in MAX, including cycling moves, the encoder readout on MAX's ID interactive page indicates that I'm reaching the target position, quickly and accurately. I have no doubt that using the step response will enable us to improve it somewhat, as the graph will allow a better window into the small times we're dealing with than just watching the encoder readout by eye, but I think that the PID loop parameters are definitely close to optimal.

I'm wondering if there's a way to use one of the oscilloscope functions in MAX to view the current being drawn or called by the motor. I'm thinking that when we input the high accels (approximating infinite accels) to allow us to use the average velocity and a rectangular V-t profile, rather than an equal trapezoidal V-t profile which uses less steep accels and a velocity of 1.5 times the average velocity, for each move segment, the motor is drawing current beyond its current limit to try to run at these high accels.

I understand your thoughts about trying to drive as quickly as possible to the average velocity for each segment of the move, but I think that's going to lead to problems with the high accel/decel values that this scheme requires. I also can't afford to lose this accel/decel time at the start and stop of the entire move (ie, the first and last (sixth) segments), even though it is small. I'm trying to create a system that has a minimum move cycle time of .4615 seconds. Each move cycle has a forward move profile that's intended to be broken into six intervals, as well as a backwards move profile that's also intended to be broken into six intervals. So even if I load accel/decel values such that I reach the average velocity target in 10 msec, since I have four accel/decel periods that aren't blended at the start and end of each move profile, I would lose a total of about 40 msec, resulting in about 10% error, which I can't have.

This is why I wanted to perform each of the six segmented moves at a uniform accel/decel, with initial and final velocity values. The initial velocity of the first segment would be zero, as would the final velocity of the final segment. With the user defined position/displacement at the end of each move segment, I can calculate the constant acceleration for each move segment, as well as the intial and final velocity for each move segment. This lowers my accel/decel values and the load on my system, and though it increases the velocity requirements on my system by 50%, these are still capable of being handled by my system. I spoke with someone yesterday that mentioned he's heard of people writing their own Labview VIs if standard ones don't exist. I'm wondering if this is a reality, and if we'd be able to create some custome VIs with NI's help to perform the move as I've described it above?

Please let me know your thoughts.

Thanks,

Joe