execution tracer idea - labview

[labviewjoe]

Hi, I have been working with labview for the past month with hardware

and software.

I was wondering if there is a way to see the order of

execution of the vi....It would be nice to see on the block diagram a

trace system or numbering scheme or drop down flow that tells the order of

operation...I think this is all done behind the scenes in labview..It might

be nice to have a trace or label..maybe this exists..I am getting

the book for scientist(s) and engineers...so maybe it is there..any help..

FOR simple programs its not an issue....I have seen some complex vi's!!

I guess I am use to the old C programming...line by line..

maybe with time?

J

[TCPlomp]

---

labviewjoe wrote: 

I guess I am use to the old C programming...line by line..

maybe with time?

J

---

Probably time will make you wiser, how ever if you have issues because you have random results, make good use of the error in/out terminals of every function.

However just face the fact that if a function has all it's inputs updated it will run ASAP.

Ton

[RavensFan]

Like the Highlight Execution button?

Or the toolkit that NI sells called the Desktop Execution Toolkit?

[labviewjoe]

The highlight execution button is pretty nice..but things jump around so much

in a complex vi (look at timers and delays)...maybe the desktop exec toolkit...

I will look at this...

Thanks

LVJoe

[NitinD]

Alternatively, help yourself by creating a simple "Log results VI" that is connected after every major operation you are doing. LabVIEW essentially divides the codes in clumps, if you can figure out what clumps LV is dividing your code into, probably your job will be easier.

But I don't see how knowing the order of execution will help you. Even LabVIEW doesn't know it before hand. If your code is so execution-dependent perhaps you should use Frame Structures, that force sequential execution.

[rolfk]

---

NitinD wrote:

Alternatively, help yourself by creating a simple "Log results VI" that is connected after every major operation you are doing. LabVIEW essentially divides the codes in clumps, if you can figure out what clumps LV is dividing your code into, probably your job will be easier.

But I don't see how knowing the order of execution will help you. Even LabVIEW doesn't know it before hand. If your code is so execution-dependent perhaps you should use Frame Structures, that force sequential execution.

---

Actually LabVIEW knows it pretty well, but things like timers, delays and such can and will change the execution order between successive runs sometimes.

Also it is quite useless information to debug an application, because if the execution order of nodes matters in a program you have to force it (dataflow) or you will have a potential race condition, that can and will expose itself at the latest at the moment your application is installed at the other side of the globe and with no internet connection available to even attempt to do remote debugging.

Just learn to live with it and use its advantages. It is not hard to do correct code. Things like global variables and local variables are an ideal way to cause race condition so if you make it for yourself to a rule to never use them unless you have thought at least twice why they are necessary and how to make sure you have no race condition there, then you are already set for at least 50%.

You can have race conditions too in C, but there you have to explicitedly write multithreading code, which is kind of hard and therefore is only done when absolutley needed and usually by people who understand exactly what the implications are, and if they don't, they learn it fast during development, or abandon the project sooner than later.

Rolf Kalbermatter

Message Edited by rolfk on 08-30-2009 09:12 AM

[labviewjoe · Accepted solution]

I have plenty to think about, this case is solved..

Thanks for all the thoughts here..

J

[Ben]

Adding to the list above...

I sometimes (very rarely now) use the "One-Button Dialog" like I used to use "printf".

You can alos use break points.

Ben