LabVIEW
calculate the delay caused by the vi
If you are just looking for the loop iteration time, use a Feedback Node to record the "previous" iteration's time and subtract from the current time.
I envy everyone who can understand the concept of the feedback node. It seems I have a mental block about it; as hard as I try to understand it, my brains just says, "Nope, not gonna happen," and just shuts down.
@billko wrote:I envy everyone who can understand the concept of the feedback node. It seems I have a mental block about it; as hard as I try to understand it, my brains just says, "Nope, not gonna happen," and just shuts down.
A feedback node is literally exactly the same thing as a shift register. The only difference is that the feedback node does not have to be bound to a loop. Being a CLD, I sure hope you understand shift registers.
@rchkrishna wrote:How can I calculate this delay. Kindly help me.
Unfortunately, you cannot "calculate" that delay, because it depends on an infinite number of hardware and software parameters and will be different on every single computer. You actually need to measure it!
Tims's code is OK for measuring the loop time, the only thing I would do is wire the time also the the global feedback initializer. This way you get zero instead of a random very large number in the first iteration.
Some additional comments:
- I imagine you know that your case structure makes no difference and could be deleted without any change in functionality.
- There is absolutely no need for any dynamic data here. What new insights do you expect by converting a scalar boolean to dynnamic data then to a DBL (???) and a boolean array? Makes no sense!
- You are hammering the DAQ assistant as fast as the computer allows with boolean data even if the data did not change from the last call. You only need to write if the value is different.
- How long should the TRUE "pulse" be? Currently it is a random function of hardware. You might even accidentally skip pulses if the loop delay is longer than expected (e.g. during a windows update and such).
- What you need to do instead is use a timed loop and generate a "TRUE then FALSE" signal whenever a pulse should occur. You probably could even use hardware timing if your hardware allows.
- If you need better precision, you need to go to LabVIEW RT or even FPGA. Windows is not suitable.
@crossrulz wrote:
@billko wrote:I envy everyone who can understand the concept of the feedback node. It seems I have a mental block about it; as hard as I try to understand it, my brains just says, "Nope, not gonna happen," and just shuts down.
A feedback node is literally exactly the same thing as a shift register. The only difference is that the feedback node does not have to be bound to a loop. Being a CLD, I sure hope you understand shift registers.
LOL actually I just figured it out. If you apply the rules of dataflow, it can only behave in a very predictable manner. Mystery solved for me. I have no idea why it took me so long to figure it out. Like I said, mental block.
@crossrulz wrote:
@billko wrote:I envy everyone who can understand the concept of the feedback node. It seems I have a mental block about it; as hard as I try to understand it, my brains just says, "Nope, not gonna happen," and just shuts down.
A feedback node is literally exactly the same thing as a shift register. The only difference is that the feedback node does not have to be bound to a loop. Being a CLD, I sure hope you understand shift registers.
Also, I thank you for your vote of confidence after all these years on the forum. I see I've made quite an impression on you. So I will just hang out in the background while you field all the "tough" questions.
