LabVIEW Softmotion Slow performance, FPGA also not functioning

[bpg101]

Hello

I am currently working on a force controller that uses softmotion to move a linear Z stage to apply force off of a real time CompactRIO. However, when running the Loop, we noticed that it was updating at an incredibly slow rate of 510ms per loop.

Initially, we tried moving over to the FPGA for motion, but everytime we activate the FPGA on our cRIO device, we get an error from the softmotion engine timing out if we switch back to the real time program, the error number that comes up is -70229  in the gain tuning panel for the  softmotion axis. The only way to fix this is to format the cRIO entirely and reinstall everything.

The loop works by reading in  an ADC value from a NI 9205 Module, then running it through a PID controller, then using Softmotion straigh line move on a NI 9516 module. When timing the elements individually, I noticed that the ADC scan in took 10 ms, the PID calculations took 10ms, and the softmotion module took 45ms.

Is there anyway we can fix the performance on our machine? If possible, we would like to either do motion with just the FPGA and not have to rely on softmotion, or improve the update loop timing of the RT softmotion loop. I am not entirely sure how to use NI FPGA to control the NI 9516 module so any advice helps. Here is a list of what we are currently using

• LabVIEW Development Module 2014 SP1
• NI CompactRIO Model 9074
• NI 9516 C Series Module
• NI 9205 C Series Module
• NI CompactRIO Software version 15.0
• LabVIEW Real Time Module 14.0
• LabVIEW FPGA Module 2014 SP1(Though nothing is installed on the cRIO from NI Max)
• LabVIEW softmotion module 2014 SP1
• Newport UTM150CC Linear Travel Stage

Attached is an image of the Vi and the Vi itself, we have never done motor control without softmotion, so if any tips can be had to make it faster then please tell

Thank you

Brian

[RIObotics]

Hi Brian,

The way the 9516 module works is that on the FPGA side, all the motion control algorithms are neatly tucked away, in fact they are hidden from the user.  When using the 951x series modules, you should really only concern yourself with the RT SoftMotion VIs.  So, with this being said, let's dive into your problem.

1. "Initially, we tried moving over to the FPGA for motion ... "  you really shouldn't have to move anything over to the FPGA side, while using 9516 modules.  You probably are doing this in trying to solve the slow 510ms problem.  So let's simplify things a bit and just deal with the RT side of things.

2. From your attached png, it looks like you are trying to implement PID control with an RT loop.  I wouldn't use a Straight-Line move, as it this VI implies that the motor has to accelerate and decelerate ...  this ramping up/down speed is actually taking up time, probably up to 500ms per iteration.  Try changing this VI to the SoftMotion "Write" Express VI and pick "position setpoint".  This will let you immediately override the position target, which is what you need.

3. Did you know that 9516 can internally take care of the PID control for you?  These settings can be accessing from the Softmotion axis configuration settings.  You should find the "position loop" settings for your particular axis, as in this picture.  Check out this video for an intro: 

https://www.youtube.com/watch?v=bBH5L1FHHOM 

You should be able to get your motors to move by using the Interactive Test Panel.  I feel if you get this right, you won't need to implement another PID in your RT VI.

Lastly, you may or may not know this, but NI has deemed 951X modules obsolete.  They will not be providing any support for these products.  Will you be doing a lot of motion development work?  If so, you might need to think about replacing this equipment to something more up-to-date.

-John

[bpg101]

Thanks for getting back to me John

I have class throughout the morning and afternoon, but I will look at implementing what you said

The reason I am currently using straight line move is solely because the last people to develop on that system used it and I just modified what they were using.

I did notice however, that switching from the express Vi to the function block seemed to speed up the loop timing, but the issue then is it would only run once.

At this point, the only thing needed is a motion loop that updates faster, so we are fine with keeping the same hardware. Also the interactive test panels do already allow motion, we just have never implemented with constant updating motion.

--Brian

[bpg101]

Hey John

The write command completely worked, and now the loop time is down to 10ms which is great! I just have a few more questions.

The write command writes to the position, and has the motor move at it's top speed I believe, do you know if there is a way we can slow down the velocity of the motor?

Also, regarding the PID implementation on the 9516, I looked into it and wanted to ask how implementation would be done

You see, the value is read in from the 9205 device and then converted to the current force in newtons from the load cell, that is what we are using as our variable while our desired value is programmed by the user. Can we implement the PID on the system with the outside data source as a variable?

Brian