LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Velocity profiling with SoftMotion Module

Hi Folk,
I need to move a stepper motor following a velocity profile, i.e. I need to change continuously the velocity while motion is in progress.
I intend to perform the move with a cRIO platform equipped with a NI 9512 module.

By using the property & invoke nodes, introduced first in NI SoftMotion Module 2009 SP1, I have created a small test routine to perform my task.
I have used the property & invoke nodes, instead of the function blocks, because I want to update the velocity profile as fast as possible.

For the test routine I have used a simulated axis (a servo motor) and the routine is developed by using the scan interface.
In the main loop, a sinusoidal wave (point by point) generates a sample velocity profile, the velocity is passed to the "velocity" Straigth-Line Move property node and it is applied to the axis by the "Start" Straigth-Line Move invoke node.

The test routine runs circa correctly until the velocity profile cross the zero, at that time the routine stops with the following Error -77070.


I have added an offset to the generated sinusoidal profile. The test routine runs correctly if the offset sets the sinusoidal profile all positive or all negative, i.e. the offset is greater than sinusoidal amplitude.

Question (1)
I beleave that this behavior is due to a bug in the Straigth-Line Move node. I am right?

Question (2)
I have written that the routine runs "circa" correctly because furthermore the previous bug there is a timing issue.


I have set the Scan Period = 5 ms as it is requested for 951x modules.
If the timed loop (Synchronize to Scan Engine) is set to 5 scans or more the timing of the timed loop seems to be correct (the sinusoidal wave shows the period that has been configured).
If the timed loop is set to 4 scans or less the timing of the timed loop becomes longer  (the sinusoidal wave shows a longer period as that has been configured).


Any idea about this timing issue?

Question (3)
Any suggestion how to write a faster velocity profiling with the SoftMotion Module?

Thanks for your help,
Asper



P.S.

Error -77070 occurred at Invoke Node in Axis_Velocity_profiling.vi

Possible reason(s):
NI SoftMotion:  A Start operation is pending. Please add a delay between consecutive preemptive Start Motion calls.

Message 1 of 25
(9,403 Views)

Hi Asper

 

Thank you for trying out our new API. I wanted to point out a couple of things to note about the new API, it's not necessarily designed to make things run "faster" but to provide the user with more control over what is being accessed than before. For instance, as you demonstrated you configure your straightline move, and then make a more simple call inside of the loop (since we don't need to configure the move each time). Since none of the code from the function blocks is a blocking call we would see only minor changes in the amount of time taken to process. As we are passing less data to the SoftMotion engine we may see a minor speed increase, but this is not primarily what the new API is for. The general idea of the new API is to provide users with even more control and open up new architectures.

 

I've looked over the code and the application and I can see where we are throwing an error, when we rapidly call into the trajectory generator we will get the error that a preemptive move is in process. This is even more evident when running across the positive/negative velocity threshold. This takes the generator a little bit longer to calculate. If a wait time of 50 ms was implemented the the generator should have plenty of time to complete its preemptive move and not throw the error. I understand that making this change would go against the point of the code.

 

CAR: [TG] Problems making small jumps from negative to positive velocity #205410

 

To address quick changes in the velocity or position we recommend using the Write function block. With the write function block you can send a command for a new position or write a new velocity with velocity over ride. Velocity over ride is going to be the way to do this, the only problem is right now there is a CAR out that velocity over ride only supports positive % and doesn't allow us to go negative.

 

CAR: [TG] Problems making small jumps from negative to positive velocity #205410     
 

For examples on how to use velocity over ride see the following directory:

C:\Program Files (x86)\National Instruments\LabVIEW 2009\examples\motion\FunctionBlocks\Axis Velocity Override

 

I don't know when your project is scheduled for release, our best bet would be to do this with velocity over ride after the change is made, but if we need a work around before this the other option as a work around would be to perform a contoured move with the points set to provide you with the needed velocity. I know this is position control and not velocity, but you could drive velocity with position.

 

For future questions and comments on how to use the new API or what you think about it please post on our motion forums which our visited by us more often.

 

http://forums.ni.com/ni/board?board.id=240

 


Thank You
Eric Reid
National Instruments
Motion R&D
0 Kudos
Message 2 of 25
(9,349 Views)

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.

 

computation_troubles_web.png

 

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.

0 Kudos
Message 3 of 25
(9,314 Views)
Here the example code of the previous post.

Asper
0 Kudos
Message 4 of 25
(9,310 Views)

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:

 

 Axis Velocity.png

 

 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.

 

 

 


Thank You
Eric Reid
National Instruments
Motion R&D
0 Kudos
Message 5 of 25
(9,261 Views)

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

Velocity_Amplitude_simulated.png

 

 With real axis (NI 9512)

Velocity_Amplitude_real.png

 

 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

0 Kudos
Message 6 of 25
(9,237 Views)

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:

 

Reset Position.png

 



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.


Thank You
Eric Reid
National Instruments
Motion R&D
0 Kudos
Message 7 of 25
(9,151 Views)

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).

 

 

Side_View.png

 

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.

 

 

Force_control_diagram.png

 

 

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.

 

 

Velocity_Zero_00.png

 

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

 

0 Kudos
Message 8 of 25
(9,122 Views)
Hello Reid,
beyond this discussion, our project is scheduled for release and consequently we need a robust solution in a short time.

Question (A)
What is the expected time that NI has planned for solving all issues we have discussed?

Question (B)
What could be an hardware architecture, alternative to the cRIO-9073 + 9515 + 9237, to build a robust system for tests controlled both in force and in elongation (with system features described in the previous posts)?

Thank You
Asper

0 Kudos
Message 9 of 25
(9,097 Views)

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.

 

Torque Control.png

 

 

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.

 

 

Message Edited by Eric_R on 02-11-2010 09:37 AM

Thank You
Eric Reid
National Instruments
Motion R&D
0 Kudos
Message 10 of 25
(9,079 Views)