LabVIEW
Velocity profiling with SoftMotion Module
Dear Reid,
thanks for the reply.
In my system I need to close the loop in force (measured by a load cell) and to move a stepper motor following a velocity profile. The velocity profile is the PID output (error).
To reach a good stability of the system, the control loop should iterate every few milliseconds or faster.
For instance, when the system is in control the PID error will be oft near to zero, by moving between negative and positive numbers. The velocity zero is very important in close loop control!
Platform: cRIO 9073 equipped with a NI 9512 and a NI9237. LabVIEW 2009 + RT + FPGA + SoftMotion Module 2009 SP1.
I have tried to find a work around for the problem that velocity over ride only supports positive percentage and doesn't allow to go negative.
The idea is to set a new max velocity every time the velocity changes sign. The max velocity is set with the "velocity" Straigth-Line Move and the instantaneous velocity is set with the "Velocity Override" Write.
I attach the example code. The same functionality are made with two slight different codes, the first uses only function blocks, the second realizes few functionalities with the property & invoke nodes.
Question (1)
Why the velocity that is read from the Read (Data) function block is positive also in case of negative move?
Question (2)
The velocity plot shows some computation troubles as the derivative is negative and the velocity is approaching the zero. The intensity of the computation troubles depends from settings and the computation troubles show a strong repeatability.
This computation troubles are present when the velocity is updated both with "Velocity Override" Write and with "velocity" Straigth-Line Move.
From where this computation troubles comes out?
Question (3)
The example where the Velocity Override is realized with the property & invoke nodes shows some times an error -70216.
The example where the Velocity Override is realized with function blocks shows no errors, but, I guess, the error is erased inside the function block.
I have set the Scan Period = 5 ms, as it is requested for 951x modules, and the Number of Scans = 1.
The error -70216 means that a required resource (the Velocity Override invoke node) is busy and unable to accept further commands at this time.
This means that some times the command is not written on the axis, i.e. the loop time becomes double. This make the control loop not very deterministic!
Do you have any suggestion how to eliminate this error?
Question (4)
In your reply you suggest to perform a contoured move with the points set to provide with the needed velocity.
Do you have an example how to emulate velocity control with the contoured move?
Best regards,
Asper
P.S.
About the wrong forum queue, if you can move this post to the correct forum, please do it.
In case of new questions on motion, I will follow your suggestion.
Hi Asper
I won't be able to move the post, but I have no problem discussing the issue in this thread.
In my system I need to close the loop in force
(measured by a load cell) and to move a stepper motor following a
velocity profile. The velocity profile is the PID output (error).
To reach a good stability of the system, the control loop should iterate every few milliseconds or faster.
For
instance, when the system is in control the PID error will be oft near
to zero, by moving between negative and positive numbers. The velocity
zero is very important in close loop control!
Can you explain the application a little more in detail, it sounds like what we are looking for is a system using analog feedback versus position feedback which is more common for stepper applications. Our 9514 and 9516 Drive Interface Modules allow for anolog feedback when run in torque control, this would be the general case solution to responding to analog feedback in the PID. Will your control loop be bouncing back and forth between positive and negative veloctiy values? If this is the case we may have to wait until the velocity over ride CAR is addressed for a solution.
I ran the code Axis Override Test 1 on my machine on a simulated Axis and this was the performance I observed:
My system is as follows:
LabVIEW: 9.01
SoftMotion: 9.0.1
NI-Motion: 8.1
NI-RIO: 3.3.1
NI-RT: 9.0.1
Question (1)
Why the velocity that is read from the Read (Data) function block is positive also in case of negative move?
Our versions maybe differing did you see the same behavior on a simulated axis?
Question (2)
The velocity plot shows some computation troubles as the
derivative is negative and the velocity is approaching the zero. The intensity
of the computation troubles depends from settings and the computation troubles
show a strong repeatability.
This computation troubles are present when the
velocity is updated both with "Velocity Override" Write and with "velocity"
Straigth-Line Move.
Question (3)
The example where the Velocity Override is realized with the property & invoke nodes shows some times an error -70216.
The
example where the Velocity Override is realized with function blocks
shows no errors, but, I guess, the error is erased inside the function
block.
I have set the Scan Period = 5 ms, as it is requested for 951x modules, and the Number of Scans = 1.
The
error -70216 means that a required resource (the Velocity Override
invoke node) is busy and unable to accept further commands at this time.
This
means that some times the command is not written on the axis, i.e. the
loop time becomes double. This make the control loop not very
deterministic!
Do you have any suggestion how to eliminate this error?
These two questions I feel share the same root cause. It takes a little bit longer to calculate the a preemptive move in the opposite direction. I am curious if you are observing that around zero % the override function performs poorly, was this present on the function block example? I think the problem here is the preemptive move being called from the straightline move function. Basically, the trajectory generator is still calculating points when send the command to it. Since we are updating the velocity at a very fast interval we notice some of this breakup due to the longer latancy times. Even with this
Error -70216 occurred at an unidentified location
Possible reason(s):
Motion: A required resource is busy and unable to accept further commands at this time.
To get around this error you will need to call into the trajectory generator at a slower period of time to allow it to finish the operation in progress. Keep in mind the control loop we are calling into in RT is the command loop to the trajectory generator and the position control loop is performed on the FPGA of the module itself.
Question (4)
In your reply you suggest to perform a contoured move with the points set to provide with the needed velocity.
Do you have an example how to emulate velocity control with the contoured move?
After reading over the additional details of the application I don't think doing a continous contour move would provide you with the fast update interval you are looking for. There is a small lag time with contouring as we process each point in advance.
Hi Reid,
I am developing a system for low-force tests of very thin tissues in tension and fatigue.
The force is measured with a load cell and is applied by pulling the sample with a linear translation stage and the elongation is measured with a linear encoder.
The linear stage is motorized with a 2-phase-stepper motor, and with two limit switches. The stepper is designed for applications with very limited space conditions and the motor is hollow.
The linear encoder has a 20 nm resolution and a 1 um accuracy, and includes an electronic for signal conditioning that is compliant with the encoder input of the NI 9512 module.
The load cell is a full bridge with an accuracy better than 0.01 %. For acquiring and conditioning the full bridge, the system uses a NI 9237.
The system will provide tests that are controlled both in force and in elongation.
For the tests controlled in force, the loop is closed with the signal measured by the load cell and the translation stage is driven in velocity.
For the tests controlled in elongation, the loop is closed with the encoder signal and the translation stage is driven in position.
For both type of tests, the user can select different test profiles, for example: a linear increasing, a sinusoidal profile for fatigue test, etc.
The user can pause the test at any time, and the system must take the condition, until the next proceed command.
My previous post: question (1)
Your reply:
I ran the code Axis Override Test 1 on my machine on a simulated Axis and this was the performance I observed:
...
Our versions maybe differing did you see the same behavior on a simulated axis?
Concerning the velocity that is read from the Read (Data) function block, I observe the following:
With a simulated axis (both in My computer and in cRIO-9073) the values are positive for forward move and they are negative for backward move (as you also have observed).
With the real axis (NI 9512) the values are positive both for forward move and backward move.
Please see the next images.
With simulated axis
With real axis (NI 9512)
My system is as follows:
LabVIEW: 9.0f3
SoftMotion: 9.0.1
NI-Motion: 8.1.0.3037
NI-RIO: 3.3.1
NI-RT: 9.0.0
I want to point out that the simulated-axis is a servo drive while the real axis is a stepper drive (NI 9512).
With my software release, I believe that this behavior is due to a bug, probably in the stepper drive interface. I am right?
I suggest that you try on a real stepper axis (NI 9512).
My previous post: question (2)
Your reply:
These two questions I feel share the same root cause. It takes a little bit longer to calculate the a preemptive move in the opposite direction.
Considering the observation on the Read (Data) function block issue, now I note that my second question arises from the sum of two different behaviors. In case the Read (Data) function block issue is solved, as for simulated axis, the sentence can be rewritten as:
The velocity plot shows some computation troubles as the velocity is approaching the zero, with the derivative both positive and negative.
Furthermore I have discovered that this computation troubles gives a blocking error if the velocity is approaching the zero with a zero derivative.
Once the velocity reaches the zero with a zero derivative, the "Velocity Override" Write is no any more able to change the velocity!
No errors or warnings comes out in this situation!
This behavior is true with an axis both real and simulated, and is still true both with an all function blocks code and a mixed function blocks/invoke nodes code.
From this point of view, the velocity troubles with the approaching to zero are very very bad!
Please consider that in the previous posted example you can find an all function blocks code, Axis Velocity Override_test_0.vi, and a mixed function blocks/invoke nodes code, Axis Velocity Override_test_1.vi.
You can easily test the velocity blocking error by putting the parameter offset = amplitude in the previous posted example.
My previous post: question (3)
Your reply:
I am curious if you are observing that around zero % the override function performs poorly, was this present on the function block example? I think the problem here is the preemptive move being called from the straightline move function. Basically, the trajectory generator is still calculating points when send the command to it. Since we are updating the velocity at a very fast interval we notice some of this breakup due to the longer latancy times. Even with this
Error -70216 occurred at an unidentified location
Possible reason(s):
Motion: A required resource is busy and unable to accept further commands at this time.
To get around this error you will need to call into the trajectory generator at a slower period of time to allow it to finish the operation in progress. Keep in mind the control loop we are calling into in RT is the command loop to the trajectory generator and the position control loop is performed on the FPGA of the module itself.
I want to underline that the computation troubles as the velocity is approaching the zero has not apparent connection with the Error -70216.
I have tested the posted routines with Scan Period = 5 ms and the Number of Scans = 5 or more (25 ms for cycle or more) and the computation trouble is still there every time that the velocity is approaching the zero.
The Error -70216 come out randomly and increases as the cycle time decreases.
I did not observe any decay in the time to perform the Velocity Override around zero %, but you have to consider that I did not make any test to investigate this issue.
I agree with you, the Error -70216 can arise from some commands that try to access the same resource a the same time.
In my opinion the Velocity Override has to be predominant, i.e. no matter what the routine is actually doing, the routine should start immediately to correct the actual velocity to reach the new value.
Suggestion: for the future release of the Velocity Override, please consider to leave the opportunity to select from percentage velocity (as it is now) an absolute velocity.
Regards,
Asper
Hello Asper
I setup a system last week with a stepper motor and you are indeed correct on the velocity readings showing up only as positive. Please take note of the following CAR I have created addressing this:
[TG] Velocity from Read Data FB always is listed as positive with stepper#206479
For the tests controlled in force, the loop is closed with the signal measured by the load cell and the translation stage is driven
in velocity.
The application for position and displacement control sound ideal. You're high resolution stepper system should work great for this. For the other case of force control, in each scan loop would you be taking a reading of force as an analog voltage and then setting velocity off of this? While running at a faster speed would result in less torque in the pull in and pull out moves on the stepper this would not be a linear relationship and highly unadvisable. Maybe I am missing a portion of the system here but I am imagining a linear stage running directly into a material. The greatest amount of torque you will see from a stepper motor is its holding torque after it has settled into position and the coils are fully active.
Suggestion: for the future release of the Velocity Override, please consider to leave the opportunity to select from percentage velocity (as it is now) an absolute velocity.
When the CAR is addressed it would simply allow the user to input -200 to 200% velocity. I apologize on my first post I listed the same CAR twice. The correct CAR # is listed below for Velocity Override.
[TG Functionality] Velocity Over ride with negative % value #202620
I am not sure why we are seeing the error NIMC_resourceIsBusyError, I will need to further investigate what is calling into the SM engine that is blocking the call from Velocity Override. If it’s supervisory it would make sense for it to take priority and make Velocity Override wait. I will be continuing to pursue this behavior and will update you if I do find a CAR. I found that there was no loop around the initial call to the Reset Position Function Block. I found that this was occupying a SoftMotion resource.
Make the following change:
As for the Velocity not changing after small changes are made, I saw the same performance on the issue with making small changes to the Velocity around zero. I didn’t see it in this code, but I have seen trajectory generator stop generating new points when repeatedly called with small changes in velocity. I wasn’t aware that the derivative had an effect, I think more what we are seeing is that the new straight-line velocity is not being loaded so velocity override has nothing to really update.
Hi Reid
please find in the next figure a sketch of a side view of the system for low-force tests.
The load cell measures the force applied to the sample and the linear encoder measures the elongation of the sample (once the correction for the load cell deformation is applied).
The motor moves the carriage trough a lead screw (ball screw).
The carriage position determines the sample elongation and consequently the force applied. Until the sample is in the elastic phase there is a proportionality between elongation and force applied, beyond, in the inelastic phase as the elongation increases the force applied don't change any more or it follows an unpredictable law. As the sample starts to break, the force decreases as the elongation increases.
For the test controlled in force, for example, a linear increasing test profile will correspond, in the elastic phase, to an elongation to constant speed. As the inelastic phase starts, the elongation will speed up to try to increase the force. Quickly the sample will break, the force will decrease abruptly and the control will stop the test.
My idea on the force control loop is illustrated on the next figure, where the PID error controls the movement of the stepper.
For the other case of force control, in each scan loop would you be taking a reading of force as an analog voltage and then setting velocity off of this?
Yes, this was my plane.
While running at a faster speed would result in less torque in the pull in and pull out moves on the stepper this would not be a linear relationship and highly unadvisable. Maybe I am missing a portion of the system here but I am imagining a linear stage running directly into a material. The greatest amount of torque you will see from a stepper motor is its holding torque after it has settled into position and the coils are fully active.
Ok, what you say about the torque is correct.
The data sheet of the linear translation stage reports a maximum speed (5 mm/sec) and a load capacity (up to 1 kg), values that are compliant with our test requirements.
I have planed to use the Danaher P70530 (DC) Drive with 25000 or 50000 steps giro (corresponding to 125 or 250 micro-steps).
Question (1)
Do you think that limitations that you describes are applicable in my case?
Question (2)
In your opinion, which is the correct approach to close the loop for tests controlled in force?
Make the following change:
Done, thank.
As for the Velocity not changing after small changes are made, I saw the same performance on the issue with making small changes to the Velocity around zero. I didn’t see it in this code, but I have seen trajectory generator stop generating new points when repeatedly called with small changes in velocity. I wasn’t aware that the derivative had an effect, I think more what we are seeing is that the new straight-line velocity is not being loaded so velocity override has nothing to really update.
To further investigate the behavior around zero, I have tested different settings for the Offset parameter of the posted example.
In the next figure I have superimposed three plots that have been obtained with different settings for the Offset parameter and a simulated axis:
a) the more left plot is obtained with Offset = 0.
The velocity plot shows some computation troubles as the velocity is approaching the zero.
b) the central plot is obtained with Offset = Amplitude = 1.
The velocity plot shows that as the velocity reaches the zero, the "Velocity Override" Write is no any more able to change the velocity.
c) the more right plot is obtained with Offset just bigger than Amplitude (Offset = 1.01 > Amplitude = 1.00);
The velocity plot shows the expected behavior.
With the SoftMotion example Axis Velocity Override.lvproj it is possible to use the Velocity Override function block for manually set different velocities.
(C:\Program Files\National Instruments\LabVIEW 2009\examples\motion\FunctionBlocks\Axis Velocity Override)
For example, the Velocity Override works correctly, starting from 100%, to set 0% and to set again back 100%.
If you try, starting from 100%, to set a small value, let say 0.1%, the Velocity Override is not any more able to set back a value different from zero!
I agree with you, the derivative of the velocity has no effect with the behavior associated with b) and with the manual Velocity Override.
The manual Velocity Override shows that the previous behavior is not associated with "making small changes to the Velocity around zero" but it simply associated with the Velocity that assumes values around zero.
Is important to note that a jump of the velocity between a big value and 0, makes no troubles.
I have note that setting a new velocity value with the "velocity" Straigth-Line Move erases the previous unsuspected issue and the Velocity Override is again able to set back a value different from zero!
I'm not sure that the case a) and b) are associated to the same issue.
The case a) incorporates the case b) but, as the zero is crossed, the "velocity" Straigth-Line Move, implemented in the work around routine, enables the Velocity Override to set again a value different from zero.
The case a) shows velocity computation troubles as the velocity is approaching the zero. Furthermore the case a) shows that the velocity computation is correct as the velocity is leaving the zero.
I'm surprise to observe that computation troubles as the velocity is approaching the zero are present only if the velocity crosses the zero, otherwise, see case c), the velocity computation is correct.
The velocity threshold for issue a) and b) seems to be differents, the velocity threshold appears higher for issue a) than b).
Regards,
Asper
Hi Asper
I understand your concerns, I agree that we should look into figuring out a successful solution versus taking basically with our current system I imagine all the coding for the positioning went fine but we are running into difficulties implementing the analog feedback. The real problem is with a stepper motor we don't control the current to the coils directly, I have seen some new technology on drives that will start to allow stepper motors to begin to move into this field. It's the current running through the motor that relates to the torque it outputs. I know you are already familiar with the basic concepts of stepper control, but so others reading this forum can follow along I'm going to go from the basics, right now we send a step and direction which corresponds to a position. Even if there was a way to directly add the analog feedback to our stepper it wouldn't provide a difference in force, I also think running the control loop in RT could potentially damage the sample, if our loop finishes late and our setpoint on the FPGA is not updated it could get damaged by the stage.
Ideal Solution to Application:
We need to use a control loop like this for torque control. The commanded positions for force would be given in RT and the PID would be performed in FPGA. With our 9505 module you could directly drive a servo motor changing the current and updating the correct value in a PID on FPGA, thus with the current control we can then control torque. The analog feedback would be wired into the 9237 module. The 9505 would also feature the encoder inputs you would need for doing position control. The current motors are stepper and the 9505 would need to be used with a servo motor.
With Current System:
With the current system because we are using a stepper motor that runs at a constant torque we won't be able to directly use the load cell in our feedback. Is the goal is to be able to read in from our load cell and command our motor until a set stress strain is achieved? This I thinkshould be possible by making small commanded moves in RT and then reading back the settled strain and moving to another position based off this. What we would be doing is commanding force by providing displacement that lead to pressure on the sample. Your code could then function in this manner and provide the user with the ability to directly set the displacement and read the force on the load cell from that. With the stepper you will not be able to turn the motor harder or softer on command so this will be your constraint.
Timeline on Current CARs:
I
noticed the velocity CAR earlier and this is a known issue with the
current trajectory generator. We don't have a fix date that I can
publicly disclose for any of the changes. I work on software quality
here in the Motion group, I can assure you that I have shown them to
the developer who is working on a solutions. What I can tell you is we
do have plans for improving the trajectory generator with our next
release (which usually coincides with LabVIEW)to be more robust for
corner case applications and hope to address as many CARs as we can.
