Need help with LabVIEW code for motor control.

[Sasidhar]

Hi,

My name is Sasi. I am a BME grad student working on my thesis topic of evaluating spine implants for low back pain. For this I am building a test machine that would apply pure moments to a spine specimen. I am using LabVIEW 8.5 to implement control of a brushless AC servo motor. My requirement is,

Step 1: Initialize the motor.
Step 2: Start moving it at a uniform RPM to the right (This RPM value too user can enter).
Step 3: While doin Step 2; simultaneously read torque cell data (Using DAQ asst.). DAQ o/p is from 0 V to 10 V; 0 V being -10 Nm n
            10 V being  +10 Nm
Step 4: When Torque value reaches +10 Nm, i.e 10 V, the motor stops.
Step 5: From the position where motor stopped (i.e no need to reset to initial position) Start moving in the opposite direction at the same
            uniform RPM as in Step 2 while reading torque cell data.
Step 6: Once again when torque reaches -10 Nm, i.e. 0 V, the motor should stop.
Step 7: Repeat 'Step 2' to 'Step 6' 3 times.
Step 8: Reset motor postion.

Till now I have managed to get the motor to move forward n backward @ a desired vel, accl, n deceleration for 3 cycles. I am attaching my code. I am having problem inserting the code for reading DAQmx amidst all this. Can anyone help me out.

Thnks,

Sasi.

[MattBradley]

Sorry I can't look at your code right now (this PC has the wrong version of LabVIEW), but I think I can still help.

Are you using the same board to read the Torque as the DAQmx?  If you are, are you using Express VI's?  If you are -- that's probably the problem.  I had the same thing happen to me a couple of weeks ago.  You have to get a bit clever with starting and stopping tasks, but it isn't too bad compared to the Express VI's.  If I'm wrong about your setup, let me know and I'll see what I can think of.

[johnsold]

Sasi,

I would make the input (read  torque) and output (set motor velocity) separate, parallel operations.  Put each in it own while loop.  The user interface and master control could be in a third loop.  Communicate among the loops with queues.  Make sure each loop has a short wait so that it does not hog the CPU.

How fast does the response need to be?  You have no control over operating system latencies unless you are using a real-time OS.  The OS latencies can make such programs unstable, unsafe, or just unusable if  your system demands response times which are too short.  Latencies of tens of milliseconds or more will be seen with desktop OSes.

One way to calculate this is to decide how much overshoot past the 10 Nm your system can tolerate.  Then determine how much time it takes to stop the motor at maximum speed.  Calculate how much overshoot occurs during that time.  If this is greater than your overshoot tolerance, you need to send the stop command at a lower torque or get a faster motor controller.  If it is less than the tolerance, then the difference is how much time the software, including the OS, can take to interpret the Torque data and generate the stop command.  You may need to use hardware to get enough speed.

Lynn 

[Sasidhar]

Hi Lynn,

Thanks for the reply, but it is kind of confusing and I am not able to correlate what you mentioned to the code I have at hand. I am attaching a screenshot of the codes I have. One is a simple 1-axis move with position edit where I want it to go not by position input but by torque input. The other is what I got using NI-Motion asst. It is a simple straight-line move of the motor forward n backward by specified duration. Here again i can tweak in the DAQ code and ask it to keep moving forward until voltage corresponding to +10 Nm reaches ad then turn backward until voltage corresponding to -10 Nm reaches. This happens for 3 cycles. Can you help me?

Thanks.

Sasi.

[Wes_P · Accepted solution]

Hi Sasidhar,

I took a look at your problem and I think I have a workable solution for you.  I definitely agree with Lynn's suggestion of using parallel loops.  This will allow the DAQmx portion to run uninhibited by the motion portion, and vice versa.  Plus, you only need to iterate the motion loop whenever the voltage level crosses a threshold.  So, by iterating on the motion code in the same loop that you are iterating on DAQmx code, you are essentially wasting processor.

I created a VI that should do what you are wanting.  I tested it out myself and it works great.  You might have a tweak a few things to apply to your system (like motion board ID and DAQmx physical channel, etc.).  I used two parallel loops and event-based programming.  Basically the motion loop starts the motor spinning at the specified velocity.  Once the motor is spinning, it waits for the DAQmx loop to tell it that the voltage value has crossed the threshold.  When the voltage value exceeds the maximum threshold (which I set to a value slightly less than 10 to allow for jitter and saturation), the DAQmx loop signals the motion loop that it can finish its iteration.  The motion loop stops the motion, reverses the direction, and starts the motion again.  Once motion has started, it again waits for the DAQmx loop to tell it that a threshold has occurred, but this time, it is looking for a minimum threshold.  I used "Occurrences" to implement the event-based programming in LabVIEW.

I have commented the code rather thouroughly, so hopefully the comments will answer any remaining questions.  The benefit of using event-based programming for this is that you save processor time, and your motion is more closely synchonized with the DAQmx.  Instead of iterating the motion loop as fast as you can, checking for updates each time, you just pause it, and wait for the other loop to tell you when to start up again.  In the mean time, the processor doesn't have to worry about iterating that loop over and over again.  Also, when the occurrence does occur, you catch it immediately, instead of having to wait until the next iteration.  Thus, you are more closely synchronized with the DAQmx portion of the code.

I hope this will help you.  Please post back if you have any questions about the code or its implementation.  Good Luck!

Message Edited by Wes P on 02-03-2009 05:18 PM

[Sasidhar]

Hi,

Thanks a lot for your help with the occurence logic motor control code earlier. It works perfectly okay. With your inspiration I have managed to get on with LabVIEW, now I am okay with it. I am trying to implement the same logic using State-machine architecture, just to make it more modular for improvements in the future. However, I am having trouble with the logic. Can you please help me? I am attaching the vi for your reference.  The problem is that it is not going through the complete cycle. I mean the motor starts moving in the clockwise direction untill it hits lower limit, then changes direction, but doesn't go till upper limit; instead comes back again. I feel there is something wrong in the Compare DAQmx state.

Thanks.

Sasidhar.

[MattBradley]

You might want to start a new thread for this request -- Most people don't bother looking at threads that already have a solution.

[Sasidhar]

Actually I wanted to send that to Wes P as he is aware of my project, but could not find his contact, hence had to post it in the forum. Thanks anyways.

Sasi.

[BCho]

Hey Sasi,

Matt is right, your latest question will get more attention in a new thread. In terms of figuring out what is going astray in your code, have you taken a look at some of the troubleshooting features of LabVIEW? Highlight execution, breakpoints, and probes can be powerful tools in figuring what what is going on in your code. There is a little more information on these features in this Tutorial. There is also more information in the LabVIEW help document on these features.

Perhaps a better understanding of what signals are being sent where and when will allow you to figure out what is causing the strange behavior in your code.

Hope this helps!

-Ben

Message Edited by BCho on 05-21-2009 11:04 AM