I have a DAQ for Temperature measurment. I take a continuous sample rate and after DAQ, calculating temperature difference per minute (Cooling Rate: CR) during this process. This CR and temperature values are inserted into the Matlab script for a physical model running (predicting the temperature drop for next 30 sec). Then, I record and compare the predicted and experimental values in LabVIEW.
What i am trying to do is the matlab model is executing every 30 sec, and send out its predictions as an output from matlab script. One of this outputs helps me to change the Air Blower Motor Speed until next matlab run( eventually affect the temperature drop for next 30 sec as well, which becomes a closed loop). After 30 sec while main process is still running, sending CR and temperature values to matlab model again, and so on.
I have a case structure for this Matlab script. And inside of case structure i applied an elapsed time function to control the timing for the matlab script, but this is not working.
Yes. Short answer: I believe (one of) the reasons the program behaves weird on changed timing are several race conditions present in the code.
The part of the diagram presented shows several big problems with the code:
Local variables lead to race conditions. Use dataflow. E.g. you are writing to Tinitial local variable, and reading from Tinitial local varaible in the chunk of code with no data dependencies. It is not known whether reading or writing will happen first. It may not manifest itself badly with small delays, while big delays may be an issue. Solution: rewrite you program using the following example:
From Bad:
To Good:
(nevermind broken wires)
Matlab script node executes in the main UI execution system. If it is executing for a long time, it may freeze indicators/controls as well as execution of other pieces of code. Change execution system of other VIs in your program (say to "other 1") and see if the situation improves.
Related
When i execute my code using Matlab parallel toolbox it gives me two different time execution between first and second time.
In fact the first time is very slow (more than CPU version) however the second time is faster and logical, and subsequent runs are the same as the second time. Why does this happen?
That is correct, and expected.
When you call it for the first time, it needs to initialize the GPU ("turn it on" in some sense), set up the CUDA contexts, etc etc. The second time you run it the GPU is ready to take anything you throw at it.
On top of that, depends on how you wrote the code, maybe the first time it requires to move some data to the GPU, and perhaps in the second time the memory is already there.
Often doing gpuDevice(1) will initialize the context enough, but otherwise just throw a small matrix multiplication to it to initialize.
All this is somehow true for other parallel computing paradigms in MATLAB, e.g. if you want to use parfor you need to initialize the parallel pool or it will take very long the first time.
I have made some measurements with an NI6024 acquisition card using Simulink, with the following model:
I have run the simulation with simulation time = "inf" and a fixed time step of 0.2, in order to collect real time data from the card. But I didn't realize that the values that "Clock" gives do not correspond to real-world time. More specifically, I have run the experiment for about a minute but the data in the variable "t" range from 0 to about 50000, which is clearly wrong. I have saved the workspace data, and I have access to the recorded data (the variables "t" and "h"), but have no means to reproduce the experiment.
Is there any way to retrieve the real world time of the simulation?
You've basically got two choices.
Run your model in real time, using for instance something like Simulink Real-Time, or other real time OS. In this case the (wall clock) time will represent time since the model was started.
Write an S-Function to slow down the simulation so that it fakes real time. There are multiple examples of doing this on the File Exchange. See Real-Time Pacer for Simulink for one such example.
This is a very basic question. I can't simulate a PWM file, in system time, from its FPGA VI file.
Details
For a NI cRIO-9067 + LabVIEW 2016 + Windows 8 system, under FPGA Interface Mode, I have the Test VI No.1.vi NI LabVIEW file and the corresponding FPGA Desktop Execution Node block file Test VI No.1 DEN.vi as suggested in the Getting Started information [1] [2].
In both files, the Low Pulse and High Pulse Numeric Controls are filled with the 1000 value. The Loop Timer block is set as "mSec" Counter Unit and "32 Bit" Size of Internal Counter.
The compiled FPGA version of the first file executes a square wave changing each 1 second, as expected, after 7 minutes of local compilation.
Under Simulation (Simulated I/O) as Execution Mode, and for reproducing approximatedly and by trial and error the square wave timing every 1 second, I need to put the value 1750 in the Clock Ticks field, from the FPGA 40MHz Onboard Clock reference clock, shown in the block options.
I dont understand this block, and why i should not put any close divisor of 40,000,000 at the Clock Ticks field, or simply, the value 1. Basically i dont understand how to "time" these FPGA simulations.
The desktop execution node is designed for time based simulation you are definately on the right track.
What you are setting at the top is the number of cycles that are executed each time you call the node. In your case you have 1750 ticks so around 43.75us of simulated time per iteration.
To simulate in real time you need to make sure that you execute the same amount of simulated time as the simulation loop takes to run. In your case, you have no timing in your simulation loop so why 1750 works for you is because that is probably how long that loop takes to execute.
If you put a loop timer in of 1ms and set the clock ticks to 40,000 (1ms simulated time) then I think you will find that it also works.
In some cases it may be beneficial to execute faster than real time so you would just have to account for that in your maths. For example if you set the clock ticks to 40 (1us simulated time) then you can count the number of iterations and multiply by 1us to get the actual clock time.
As a student I am currently working on a Matlab Simulink project. I am quite new to using Matlab/Simulink (few weeks).
I want to implement and run a Matlab “.m” file with which I can open Simulink and start the simulation. The aim is to do a 24h Test with a load cell cut into 1h “pieces” and to save the data to different sheets of an excel file each hour. So my simulation runs for 1h, stops and starts again, and so on. Through Matlab and a “for” loop I do the measures 24 times.
Between measuring steps I have to wait for simulink to finish its measures and saving the file in order for the Simulink window to be able to get closed by close_system('Thesis_SerDatTransm_Simulink').
So I tried to implement the delay with a while loop and by checking if the measures I get fit into an array of the size bigger than 449 (I measure 449 values):
for k=0:1:24
% Load Simulink
load_system('Thesis_SerDatTransm_Simulink.slx')
% Open Simulink
open_system('Thesis_SerDatTransm_Simulink.slx')
% Start Simulation
set_param('Thesis_SerDatTransm_Simulink', 'SimulationCommand', 'Start');
% Save Data
my_cell = sprintf('A%d',k);
xlswrite('file.xlsx',y,my_cell)
% Wait for Simulation
while 1
test=size(y)>=449;
if (test)
close_system('Thesis_SerDatTransm_Simulink')
break
end
end
end
The Problem now is, that program gets stuck at the while loop. Simulink is started, but no simulation or data gathering is done.
So I wondered if anyone could check if something is wrong with my While loop, since the rest of the programm works all fine without the loop (but receiving an error message, that during the simulation, Simulink window can't be closed).
I know there is a way to create a delay with waitforin matlab and create another function which I could call, but I couldn't figure out how to do this yet.
thanks
Regards
hohmchri
The right way to do this is to use the sim function to run your model (not the sequence of load_system, open_system and set_param that you have).
sim will block the execution of m-code until the model completes executing. Data can either be returned into the workspace (when used with no output arguments) or returned as an output from the call to sim. (And then you can write it to Excel as you've done.)
The only reason not to use sim, and perhaps use the commands you have, is if the model takes a long time to initialize, and you don't want to to open and close it every time through the loop. However, even in this case your code isn't correct. The load_system would be outside the loop; the open_system is not required; in your while loop you would poll the model's SimulationStatus property to see if it is still running (not the size of the y variable); and the close_system would be after the loop (as indicated by #m_power in one of the comments).
As written you should use the matlab pause command. This stops your execution for X seconds.
You should also look to optimize your code as m_power states
Is there any way to show the execution progress (even a rough estimation) of a Matlab instruction?
For example let's say I am computing distances using pdist:
D = pdist(my_matrix,'cosine');
and this computation takes hours, does Matlab provide any way to show periodically the execution progress?
Not intrinsically. You can of course do after-the-fact checking with the profiler or tic/toc.
If this is something you will be doing a lot for a single function, you could consider modifying the function and saving it in your path with a new name (I have a directory called "Modified Builtin" for just this purpose). In the case of pdist.m, you might save pdist_updates.m. Looking a the function, the actual distances are calculated starting around line 250 with a series of nested loops. Add in a line like:
disp(sprintf('Processing pair %d of %d',i,n-1));
at line 265. If you really wanted to get fancy, you could use tic and toc to time each loop and provide an estimate of how long the entire calculation would take so you would know how long you had to run to the coffee machine.
Of course this will cause problems if you end up cancelling your Statistics Toolbox license or if Mathworks upgrades the toolbox and changes the functionality, so use this approach sparingly.