Change velocity from rotation to linear in Velocity Control (closed loop) example for NI 9505?

[PumpGuy]

I have a linear actuator and an NI 9505 working with the Velocity Control (closed loop) example I found when I searched for "9505" in the example finder. The example is used for rotational motors, not linear actuators. Though that is the case, I can still run the program and have the actuator move at various velocities. The problem is that though I've put in numbers for velocity Setpoints, I don't know what they relate to in terms of linear motion.

My question is, how do I change the block diagram so that it takes linear velocities instead of rotational (RPM)?

If needed, I should be able to provide the example vi.

[Highland_Controls]

The first question I would ask is: "Do you want to run a linear actuator in velocity mode?".  My answer would usually be no.  Linear actuators, by their nature, are typically used for positioning.  You probably want to figure out how to use positioning function blocks.

To answer your question, it is just a matter of scaling.  Your linear actuator will have some kind of spec for distance moved for every rotation of the input shaft.  If you have a gearbox, you need to take that into account also.  Just basic math after that.  Post some more details for your system if you want some solid numbers.

[PumpGuy]

It's a voice coil, I guess I should have mentioned that initially. It would make my job infinitely easier if this is done with velocity function blocks. Without giving too much detail, I basically have a list of velocities I need the actuator to move at. It has to move following the first velocity for, say 100ms, then switch to the second and move at that velocity for 100ms and then switch to the third and so on.

I'm not sure what details of my system would help out. 

The main issue I have is that I don't really know how to do this basic math with labview. I was hoping someone had possibly done this before or was willing to give it a shot to help me save time. On this point, if you or someone else is willing to lend a hand with tackling this, I can provide the vi.

Hopefully I'm not stepping over the line with this question.

[NathanK]

Do you already know the ratios to convert the your linear velocity to rpm and you just don't know how to write the LabVIEW code to do it?

Nathan

Motion R&D

[PumpGuy]

Now that I've looked at the code more, I'm not really sure what the ratios should be. I originaly thought it was basic, but now I really can't say.

[ColdenR]

Once you have the ratios, you can do the scaling by simply multiplying the output numbers by the required ratio. So from the block diagram, just open up the functions pallete, navigate to Programming --> Numeric and then use the multiply function or the other basic math blocks to perform whatever scaling you need.

[NathanK]

PumpGuy,

I want to understand your system better. I realized I wasn't answering the original question.

You are using the closed loop example. I assume that means that you have some sort of velocity feedback.

There is nothing in the logic of the FPGA of that example that assumes the velocity is rotational. The RT VI does some conversions for you to change from encoder counts to RPM. You would need to replace that code to convert your encoder counts to linear velocity units.

Those conversions are really just to put the setpoints and the feedback to the user in convenient units. It isn't required for the example to work. The velocity control loop will take in your velocity setpoint and feedback and try to make them match. As long as the fixed point datatypes are sufficient to hold your values no scaling will be required.

In other words, to answer you question: "how do I change the block diagram so that it takes linear velocities instead of rotational (RPM)"

You don't have to do anything to the FPGA VI to get it to work.

If you want the convenience of using real units in your RT VI then you should replace the scaling code with a simple multiplication. Just multiply the encoder counts by the linear distance per count of your feedback device.

If you have further confusion it would be helpful to know what kind of feedback device you are using.

Nathan

[PumpGuy]

I'm just using a linear encoder. I don't know if this will be helpful for you, but one count equals .5 microns.

When I was controlling the actuator with a Galil controller before, I was using velocity setpoints of like 50,000 and 100,000. I guess I was thrown off because I used setpoints of like 100-1000 with this vi. I wasn't sure how these numbers related to velocity values that are more convenient.

[NathanK]

PumpGuy,

The FPGA VI tracks the velocity in the most useful units for itself- "ticks/count". That is, the number of encoder pulses for each execution of the velocity loop.

These units are not very useful to real people. Therefore, In the RT VI you will see a section of code that converts between RPM and "ticks/count" just for the convenience of the user.

In the example- the "encoder cycles per mechanical revolution" is multiplied by 4 to get "encoder pulses per revolution". The velocity loop rate is divided by 60E+6 to get the loop rate in minutes. The setpoint is then scaled by these values to convert it from RPM to "encoder pulses per velocity loop rate". The reverse is done on the other side to display the observed velocity.

Your code can be simpler. You just have to convert from the units you want (I used cm/s) and encoder counts per velocity loop.

My take on what your changes would look like is below. The value of the "Encoder Cycles/cm" constant would be 20000 or .5 microns per encoder count.

Notice that we convert to seconds instead of minutes and simply multiply the encoder pulses by the number of pulses in 1 cm for your encoder.

FYI- This code is for your education. I haven't tested it.

[PumpGuy]

Nathan,

Thank you for this. Sorry I haven't replied to this sooner, but I was busy with another project.

I do plan on using this to learn, more-so than just copying the code like I usually do. Thank you for taking the time to go into detail, it is really appreciated. Hopefully this is the solution that I'm looking for.