measure time lapsed from reaching threshold to execution

[altenbach]

If performance is key, stay away from dynamic data. For the compiler, peeling off the layers of the dynamic data to do the comparison is much slower than the comparison itself.

I have not idea why you do the inner comparison, because it gets "constant folded" at compile time and does not even exist in the code. In terms of speed, your VISA communication is orders of magnitude slower than anything else.

Where is this running (desktop, RT). Do you have an FPGA? That's where the reaction should happen.

The time limiting step if the outer loop rate. What is it?

Please don't attach blurry, truncated pictures. (We cannot debug pictures, we cannot see what's outside the visible region, we cannot see what's in the other cases and we cannot see how the express VIs are configured). Attach the actual VI if you want more specific answer.

[RavensFan]

Also, there usually isn't much benefit to using a timed structure in Windows.  They are meant more for real-time systems.  You should use block diagram cleanup because you have functions overlapping each other in that timed structure.

[nighthawk117]

The timed sequence structure was just for me to figure out how long it takes for the program to update its voltage reading and execute the voltage cutoff sequence.

I wasn't actually going to run this program to use it as a voltage cutoff control program. 

[nighthawk117]

I have read the documentation you suggested and have created two programs.  

In both files, inside the timed sequence structure, I have just the bare bone DAQmx API calls to measure voltage.  

The two files are different in that, outside the timed sequence structure, the first program (untitled 1_rst) has the identical the DAQmx API calls, whereas the second program (assistant) has a DAQ assistant.

I would have thought both programs will give me the same time reading (difference between tick counts) but for some reason, the one with a DAQ assistant outside the timed sequence structure (the second file) is much faster (4.689ms) than the other one (13.159ms).  Could you help me figure out why that is?  They have the exact same stuff inside the timed sequence structure. 

[altenbach]

A timed sequence is to control timing, not measure timing. A plain sequence would suffice.

You still have not told us if you are running this on a RT system or a desktop. Form the ticker, it look like RT, but how are you testing this during development?

I doubt your timing measurements are accurate or even meaningful.

Why are you creating a virtual channel on the fly instead of once before the loop?

[RavensFan]

The one with the DAQmx calls is slower because you are creating the tasks inside the loops on each iteration.  Worse, you are never deleting those tasks so after a long enough period of time, your program will crash.

DAQ Assistants aren't as bad as others made them out to be.  They generally are designed so they won't recreate a task, or open and close it every iteration, depending on what settings you picked.  (You can see what goes on in the code behind the DAQ Assistant by right clicking it and picking "Open Front Panel.")   But the problem with DAQ Assistants is that they hide what they do, they aren't as flexible as you might need them to be, and they use the Dynamic Data Type wire which also hides details, and conversions to and from it take time, and those conversions are sometimes wrong.  (e.g. you get a single datapoint when you were expecting a whole waveform).

[nighthawk117]

It is being run on a desktop.

I have a source meter connected to a BNC-2090A connected to the desktop.

Regarding creating a virtual channel on the fly, I don't know how to just have the voltage reading inside the timed sequence without having the virtual channel. 

One thing I would like to ask is, it seems, the "untitled" program does not seem to have their tick counts reset. I would appreciate it if you could tell me why they are not being reset. 

[altenbach]

You can create the virtual channel once before the outer loop starts, then wire it to the read voltage inside. Close if after the outer loop completes.

:tick count" never resets. It start at zero when the computer starts and rolls over whenever 2^32 is reached. Not sure what you mean by your statement. You are measuring differences, so the offset is irrelevant.

Why are you using RT tools on the desktop? (your tick count is not for the desktop, use "high resolution relative seconds" instead.)

[nighthawk117]

Thank you for your suggestions.

I have begun to use "high resolution relative seconds"  and made the virtual channel once before the outer loop starts, then wire it to the read voltage inside.

One last thing I would like to know is when I start running the program on the front panel, and set the voltage threshold below the current voltage to see what the time difference is (x-y) and repeat it, the x-y value just keeps increasing, instead of being reset. I understand the timers do not get reset. But, I think each run should give you the difference calculated from zero. 

In other words, if I set the threshold voltage below the initial voltage, every time I try to turn on the power source, it's going to be shut off immediately.  If I keep turning the power source back on, the x-y value that gets printed on the front panel tends to go up. (not for literally every iteration but most of the time, it keeps going up)

Not sure where I have made a mistake. 

[JÞB]

If you post a snippet inline I can look at it.  Right now I cannot open a VI (Installing NI Software upgrades today)