LabVIEW
Labview RT cRIO9057 timed loop behaviour
@rikimancio98 wrote:
I don't understand why the presence of many shift registers should affect computational time. I would expect higher memory usage, but not an increase in calculation time..
I did not say that it will fix your timing, it was an out of band comment about how to simplify the code to make it more manageable and have fewer places for bugs to hide. You use pre-allocated arrays so the memory is nearly identical (very slightly less for the 2D array at the advantage that all data is contiguous in memory. (only a potential problem for gigantic datasets!))
One of your shift registers is just a glorified output tunnel because you never use the previous value. There are many hints at ""code smell" that can mean there could be problems outside of what you showed.
Your hardware runs just an ancient 11 year old dual core intel atom, a very (very!) weak CPU with only two cores. Maybe you are simply exceeding its capabilities.
You have not addressed my main point to analyze what the loop data nodes say about all that. Note that whenever an iteration is slow, the system tries to catch up my making the next one faster (if I read the data correctly). What else is running in parallel to that code? What does the library function do?
@rikimancio98 wrote:
Sorry Bob I can't show my entire VI because of my company policy.
If you need more detail I can explain to you what I did in my VI.
Clusters used in VI are buildt before the loop and only modified (or used like constant) as pointer to struct inside the library.
Clusters don't have a shift register in where they are stored.
Shift registers are only for arrays in which I store the values of the Library Outputs one to one.
I hear that company policy excuse a lot here but quite often it is really a cheap excuse.
A thousand words of good explaining can NOT replace a look at a VI. And most explaining done in these forums by end users are not exactly good. Remember, it is you who wants help here. The least you can do is do all possible effort to help us to help you.
The screen shots you posted show clear indications of non-optimal code (to formulate it nicely) but often hide other substantial facts that would be needed to understand what your VIs do.
You have some LabVIEW heavyweights here spending their time trying to help you make sense of your problem. I think it would be beneficial for you to not stress the patience of these people to much.
You have not addressed my main point to analyze what the loop data nodes say about all that. Note that whenever an iteration is slow, the system tries to catch up my making the next one faster (if I read the data correctly). What else is running in parallel to that code? What does the library function do?
The VI is running alone, nothing is running in parallel.
The library funcion is a Simulink model compiled as .so and this is the execution Time in ns (max. execTime = 20us).
My timed loop is configured like this
I think that the system try to recover the delay to maintain the mean time at 125us because I unchecked the Discard missed periods flag.
@rikimancio98 wrote:
The VI is running alone, nothing is running in parallel.
The library funcion is a Simulink model compiled as .so and this is the execution Time in ns (max. execTime = 20us).
No modern running computer systems only has exactly one task. Can you tell us how you created this graph? (I assume a three frame flat sequence around the node with high resolution timers, not something that the node reports from an internal measurement)
You have that "acquisition graph" progress indicator. First of all, it has the wrong representation. Can you explain where this is displayed? Would the timing improve if you get rid of it?
I would still recommend to reduce it to two shift registers, an orange one with six columns and a blue one with 2 columns. This way the new data will be adjacent in memory and not scattered all over. (And get rid of that blue scalar shift register!!!)
What are the datatypes (SGL or DBL?)
Did you notice that you are running one too many iterations? The size of your arrays is 10k, but the index of the last element is 9999, so you are trying to replace a nonexistent element. (not a serious problem, but contributing to code smell.)
@rikimancio98 wrote:
I think that the system try to recover the delay to maintain the mean time at 125us because I unchecked the Discard missed periods flag.
And does seem to be able to catch up without permanent drift. Since you have full timing information of all data points, it would be trivial to resample the final data for constant dt (by interpolation) with very little loss in information.
Probably I found the problem.
In my VI there was an acquisitionPhase node that is a progress bar in the Front Panel. My RIO is ethernet connected to the company LAN so to see this progress bar I probably had a refresh time that caused the delay.
Now this is the graph of the execution of the Loop
Furthermore I notice that removing the call library function Node and simplifying the VI, changes in execution time are no relevant (same graph).
This is my VI now.
Is it possible that the remaining 20us of delay that I see in the graph is caused by jitter of the system?
Or Is there something else that I'm not considering?
@rikimancio98 wrote:Probably I found the problem.
In my VI there was an acquisitionPhase node that is a progress bar in the Front Panel. My RIO is ethernet connected to the company LAN so to see this progress bar I probably had a refresh time that caused the delay.
Well, I pointed that out in my message right above, Did you find it independently? . 😄
@rikimancio98 wrote:
Furthermore I notice that removing the call library function Node and simplifying the VI, changes in execution time are no relevant (same graph).
Can you explain your use of the term "relevant"? Relevant for what? Are you saying you get the same jitter with a basically empty loop?
