LabVIEW
Resolver Signal Simulator
- last edited on by
Content Cleaner
I have a cRIO 9048 and I am simply trying to implement the given Resolver Signal Simulation and Measurement in LabVIEW FPGA. Thus far, the only change I've really made are in the RT VI. This is aside from adding my cRIO in place what was already present and migrating VI's. Aside from that, I just changed the respective analog out/in terminals so they matched my hardware. I compiled, ran, and all seems well at first. Oscilloscope shows that signals are being output as expected, but the position being read in is always 200 degrees as shown on the front panel. It fluctuates, but not by much. Upon reading in the "Excitation In" signal and displaying that on the front panel, I get a very jagged signal. I suppose this has something to do with sampling rates, but I'm not sure exactly what needs to be done. Any input would be greatly appreciated.
If you are trying to simulate a resolver, then I hope it is clear that you are trying to generate two waveforms, given an input waveform. Your Excitation In is going to be at a pretty high frequency. Put your scope on the Excitation In signal and look at it. It should be a clean clear Sine wave at some frequency and amplitude which doesn't change.
Now look at the code which is sampling this signal. Sure on the FPGA you are running in a 100KHz loop, but on the RT side you are sampling that reading at 100ms and updating your UI and graph one sample at a time. Practical use of Nyquist says you should sample at 10 times your signals sample rate to get a good idea of the waves shape. This means your Excitation should not be faster than 10Khz for the FPGA to work well with it. But to view this properly on the RT side at the 100ms sample rate, that would mean your input wave can't be faster than 1000ms or 1Hz. I don't know your hardware setup but based on my experience your resolver is going to be much faster than that. This is why the graph isn't going to look normal. If you really want to view the wave as it is sampled from the FPGA you'll need a DMA like a LUT to store a bunch of values into on the FPGA side, and then periodically read a bunch of samples at once on the RT side and graph those.
For starters I'd put all three signals on the same scope and look at them. Are they the right frequency, amplitude, and phase for the position you are simulating? I'm guessing they aren't. Look at the Frequency and Amplitude settings of your RT VI, does it match your Excitation In? Other than messing up these settings, or the IO selection which you said you changed there isn't much else to checkout.
After making some changes in software and hardware, I've managed to get a functioning resolver simulator working on the cRIO. However, once I get to frequencies above 2-3 kHz, I don't seem to be generating enough samples (which these modules are capable of doing). The sine values are generated in the RTOS and sent to the FPGA.
Following is the block diagram for the sine LUT generation:
AO frequency defaults to 1E6, I assume this refers to the rate at which the FPGA runs? In which case, the timers are set to 100 kHz on the FPGA's end. Either way, how should I go about getting it to generate the proper amount of samples per the desired output signal frequency? At the current state, the actual generated signal is off (short) by a factor of 10. If you add in that factor of 10 in your desired signal, you have too few samples (since the AO freq is set to 1E6).
This is an interesting task, but should probably be made into it's own thread. The original post was asking about creating the resolver signal to convince other hardware that it was plugged into a real motor. You appear to be asking how to take the outputs of a resolver, and determine the position.
For that I'd suggest a simultaneously sampling AI card. Most DAQ hardware have a single analog to digital converter, and this is shared among all the channels. What this means is that most hardware cannot take a reading from two analog inputs at the same exact time. They will instead read one, then read another very quickly. This time delay between readings is often very small, but when you are trying to sample three sine waves at once, any time delay will mean errors in your calculation. It might not change enough to matter, and the shifted amount might be able to be compensated since the time delay is known, and the frequency should be static. But to do it right I'd suggest getting a simultaneous sampling AI DAQ. If you have some generate purpose DAQ hardware you can take the three readings and see what the signals look like.
As for the software. Look earlier in this thread and you'll see the waveforms that will be generated for a given position. You basically need to know the amplitude, and phase between the three waves and this will tell you position. Sorry I don't have any example code of this, because I've always been on the other side of it creating the resolver with an FPGA.
