Outputting sine wave to motor

[matthewg]

Thanks Chris_G for the extensive help. I came across another example, One-Axis Contour Move (ROM Buffer).vi, which can be modified (attached) to write the sine waveform to a buffer, which can get executed at a frequency that I specify ("Requested Interval"). This seems to be a more promising method because I can directly control the execution rate.

But when I run this program a number of times, eventually I get the error message shown below. It seems that all of the buffers have been filled up? When I go into MAX (version 4.6.1) and click the Onboard Memory Manager tab, MAX suddenly becomes really slow. Everything else on my computer seems to run fine in the meantime, so it seems to be a problem just with MAX pulling up the Onboard Memory Manager (I can explore other MAX features just fine). Eventually, it does pull up, and I can see 32 buffers.

When I right-click a single buffer and select Delete From Flash, the buffer eventually disappears (MAX responds very slowly), and I can successfully run my VI again once. I can't run it another time without deleting another buffer.

I see there's an Oject Memory Management.flx block at the far right. Shouldn't this be deleting the buffer at the end of the program? Is there a different version of MAX that wouldn't freeze up?

Thanks for your help.

[Kristen_K.]

Hi matthewg,

Does this error occur at the first instance of Config Buffer? 

Kristen H.

[matthewg]

Hi Kristen,

I think the problem was that I wasn't letting the VI finish execution. It would complete the last move then pause for a few seconds, at which time I would assume that it frozen and so I would hit the stop button. But it needed those last few seconds to clear the buffer. Having a little more patience solved the problem.

Now I'm having a new problem. I'd like to generate a Bode mag plot for the motor by exciting it with different sine waves up to about 50Hz. But when I use a modified version of the One-Axis Contour Move (ROM Buffer).vi example (attached), the shortest interval that can be attained between sampling points is 10ms. A 50Hz sine wave sampled at 10ms intervals no longer looks like a smooth wave. So, at desired frequencies greater than about 30Hz, the waveforms are sampled so coarsely that I'm sending the motor a really low quality waveform (see below), and I won't be able to get a good Bode plot.

Is there a better method for looking at the frequency response of the motor? Is there any way to send commands to the motor faster than 10ms apart (100Hz)? 

Thanks for your help.

[matthewg]

Should I instead use LabVIEW Real Time? Is this possible with the PXI-7358 controller? I don't have an embedded PXI controller, just a MXI 4 connection to my computer.

[Kristen_K.]

Hi matthewg,

While the motion controller can run in a real-time system, it will not make anything run faster.  Real-time operating systems are for deterministic applications, where you have to guarentee something will occur in a specific time frame. 

I took a look at the VI.  Why do you have the Time Delay in the code?  I'm not sure I followed the logic in that.  

Kristen H.

[matthewg]

Hi Kristen,

I put the time delay in because the first 200ms or so of motor response data didn't look very smooth and wouldn't really produce a good Bode plot. It's delaying the time when high speed capture starts capturing positions.

So there is no way to send a target position to the motor more frequently than 10ms? That's the fastest I can get with the current strategy. Would creating an onboard program with a buffer help? Do you know of any other methods that have been used to get frequency response data (i.e., a Bode plot) for a motor? 

thank you.

[johnsold]

How about a different approach?  I do not have any of the motion control stuff, so I cannot comment on your specific questions regarding the performance of that system.

You want to measure the frequency response of the motor, right?  Set the frequency to the starting value.  Run the motor at that frequency for a fixed time period or fixed number of cycles of the waveform.  Measure the response.  Change to the next frequency (and amplitude).  Repeat until you have covered the entire frequency range.

This will be slower than the continuous sweep your were attempting earlier, but probably more meaningful.  Unless you are dealing with a very low inertia servo-motor, changing the frequency more than once every several revolutions probably does not tell you much about the motor.  Brushless motors are usually a three phase motor.  Until the motor has rotated at least 120 degrees, it has not gone through the entire variation of magnetic fields and torques.  Depending on the inertia of the motor and load and the available torque it might take several revolutions for the motor to respond to a change in its drive.  This is why I suspect that changing the frequency every 10 milliseconds is probably not particularly meaningful.

Lynn 

[matthewg]

Thanks Lynn for the suggestions. Right, I'd like to get the frequency response of the motor, for frequencies up to 50Hz. But the problem is, I can't send positions commands to the motor more frequently than 10ms with my current VI strategy. Since a 50Hz wave has a 20ms period, then I'm only able to send two position commands per period to the motor at 50Hz, which wouldn't represent a very good sine wave, and wouldn't allow me to very accurately compare input and output magnitudes at that frequency.

You're right, the best way would be to try one frequency at a time, and start recording the waveform after the rotor has rotated a little bit.

Is there any better way to excite a motor at 50Hz with a sine waveform?

 Thanks.

[johnsold]

I was not thinking in terms of position commands to a motion controller.  I was thinking of the frequency of the voltage applied to the motor.

If your motor controller allows you to set the position of the motor, try sending it step changes of various sizes, particularly fractions of a revolution, and monitor the position with time.   Allow plenty of time between steps so the motor settles into its final position before sending the next command.  This will give you a measurement of the step response of the motor/controller combination, not just the motor.  The step response is related to the frequency response.

If the combination settles in significantly less than 10 ms, then maybe it makes sense to try to speed up your program.  If the settling time is, say, 200 ms, then changing things every 10 ms does not tell you anything.

Lynn 

[matthewg]

Thanks for your help Lynn. I measured the step response of the motor to a step of size 50 encoder counts (my encoder is 2000 counts / rotation) and the settling time looks to be about 20ms. When I excite the motor with a 50 Hz square wave (highest freq I can obtain with current VI strategy) of amplitude 50 counts, my output magnitude is 20.

So the motor loses some amplitude with a 50Hz square wave, but it still responds. Now I'd like to look at a slightly higher freq like 75Hz. But this would require better than 7ms between position commands, and this VI can't seem to do better than 10ms.

-Is the PXI-7358 limited to 10ms?

-So I wouldn't be able to improve the speed by using real time control? (I read that real time control is useful for deterministic applications, and sending position commands to the motor is something that I would like to be deterministic.)

Thanks.