I'm using Labview to control a lower limb orthosis. What I did is to record in a spreadsheet the values of the two angles in a random walk. The control model is made well because I tested it by giving two sinusoidal waves with different frequency and the system responds by following the trajectories. The problems start when instead of the sinusoidal waves I put the experimental values of the angles reading it with the "Read from measurement file". I can't vary the speed of the system by varying the timing of the while loop. The speed is always the same.
In the attached vi is possible to find this part in the upper left corner of the while loop.
I'm using windows 7, labview 2013 and cDaq-9178.
Thank you in advance for the reply.
Solved! Go to Solution.
Your DAQ is limiting how fast you can run this loop. You are taking 100 samples at 1kS/s. That means you are acquiring 100ms of data. So 100ms is the fastest your loop will be able to run.
It doesn't look like you are doing anything with the data other than sending it to a graph. Try using Continuous Sampling and get fewer samples to increase your loop rate.
first of all thanks for the quick reply.
I did your advices but I can't manage properly the process speed and the minimum value of the period that I can obtain is 20 s. The main problem that I cannot understand is that if I sobstitute the values read by the "read from measurement file" with those of the sinusoidal trajectories, mantaining the parameters of the daq assistant equal, the system works properly, I can vary the speed easily changing the frequency of the sinusoidal signal. I can obtain also a 1s time period! Only with the introduction of the "read from measurement file" instead of the "simulate signal" the program starts to work bad.
Try to check that the values "dbl" output from the block "Convert from Dynamic Data" are the values that you expect. It 'possible that incorrect data conversion causes this slowdown. To standardize the cycle time you should replace the block "wait" with the block "Wait until next ms multiple".
I checked the data and I think they are correct also because I take just one datum per time after the "index array" and the device follows that trajectory. I tried to substitue the "wait" with the "wait until" but nothing...the speed remains always too slow. I don't know if there is another way to recall the data in the text file, maybe somthing that create less problems.
I removed all the DAQ VIs and the Read from Measurement File.VI and ran your code with the Profiler. I takes about 2.7 seconds to run 185 iterations. The Profiler shows the Simulate Signal VIs as taking the most time - almost 350 ms. The Profiler adds some code to extract timing data and this changes the timing of the program. However, it is usually good at showing relative timing.
There is no need to run Simulate Signal four times to generate DC. Create a waveform with the Y array containing 100 elements = 1.0. 100 elements because that matches the timing of the signal you are simulating. Then use Multiply to multiply the waveform by the outputs of the Force-Pressure muscle calculations. You may not need a waveform at all. If the DAC device you use has static outputs, you only need to write one value. It will be retained until the next value is written.
Replacing the Express Formula VIs with subVIs using LV VIs, functions, and primitives is faster. Some of the constant calculations can be moved outside the loop since the values never change. This may not make much difference because the compiler is probably smart enough to fold everything into constants. For the Force-Pressure muscle calculations I used the Polynomial Evaluation.vi with the polynomial coefficients passed as arrays of constants.
Replacing the Express Simulate Signal VIs with Sine Waveform.vi is somewhat faster.
I replaced the comparisons following the Newton-Euler calculations with In Range & Coerce. It probalby is not much difference in speed but seems cleaner.
All of these changes make the VI run about 30% faster. There are usndoubtedly other optimizations which could be done. Replacing the DAQ Assistants with standard DAQmx VIs is one, but I do not have DAQmx or any hardware so cannot evaluate that. It might be worth considering separating the DAQ Read and DAQ Write into parallel loops so that the timing is independent.
I will improve all your precious advices, as it is obvious I am not an expert of Labview ....
But I think that the main problem remains unsolved: are there some conflicts between the DAQs and the "read from measuremnt file" vi? Why when I simulate the signals with the sinusoidal waves all works well and not happens the same with the read trajectory?
I suspect that the real problem is something else. I cannot see any way that the data read from the file should affect the speed of the loop.
Please post the version of your program which works the way you want with sinusoidal signals without the file read. Maybe someone can spot a subtle difference to explain what happens.
As suggested by Lynn I attach the vi that works well. The only difference with the other is, as I said before, in how I give the signal to the system, in this case just giving two "simulate signal". I hope this can help to find a solution, I am desperate because I practically lost 3 weeks of work
I see something different between the two VIs. Whether it relates to your problem, I cannot tell.
The VI using the simulated sine waves takes the segment of the sine wave generated in the current iteration of the loop and converts it to a scalar. The Simulate VI produces 100 samples of the waveform which is sampled at 1000 samples per second. Since you have the frequencies set to 1 Hz, each iteration has 1/10 of a cycle or 36 degrees. The scalar value selected by the Convert From Dynamic Data nodes is the last element in the segment. So on the first iteration the value is sin(36 degrees). The second iteration uses sin(72) and so on. The other 99 values in each segment are discarded.
The VI using the file reads the file one time and then uses every value in the file (one at a time, on successive iterations). I have not seen one of your files. If the data in the file does not correspond to the one data point every 100 ms in the simulation mode, it makes sense that the two VIs would behave differently.