Programmatic toggle of Highlight Execution

[Jim Kring]

When I try to write to the Highlight Exection property of VI ("VI::Diagram::Highlight Exection" property) I get Error 1044 (VI is locked). Why does this give an error? I can press the execution highlighting button on a VI's toolbar when it is running.

Anyone know how to this?

My use case: I want to create a custom probe that can turn ON/OFF execution highlighting on the VI in which the probe is placed.

[Jim Kring]

Here is an example VI (saved in LabVIEW 8.2.1) that attempts to enable execution highlighting on itself. If you run it, you will see the aforementioned error.

http://forums.lavag.org/index.php?act=attach&type=post&id=6695

http://forums.lavag.org/index.php?act=attach&type=post&id=6694

[MikaelH]

QUOTE(Jim Kring @ Aug 21 2007, 11:23 AM)

Here is an example VI (saved in LabVIEW 8.2.1) that attempts to enable execution highlighting on itself. If you run it, you will see the aforementioned error.

http://forums.lavag.org/index.php?act=attach&type=post&id=6695

http://forums.lavag.org/index.php?act=attach&type=post&id=6694

I've just tried it in 8.5 and it doesn't work their either.

I guess you can't set it on a running VI

//Mikael

[Ton Plomp]

QUOTE(MikaelH @ Aug 21 2007, 05:16 AM)

I've just tried it in 8.5 and it doesn't work their either.

I guess you can't set it on a running VI

//Mikael

Maybe from another App.instance?

Ton

[MikaelH]

If you try running it from another application instance, it will be even more "locked".

Especially if you open en reference to a class from several Application instances, it gets locked.

I have had lots of problems with this for the Project Tree Addon tool (GOOP Development Suite) I'm working on, since that code is running in a

"NI.LV.MxLvProvider" application instance.

Also you can get LabVIEW to crash when messing with too many open application instances ;-)

//Mikael

[brian175]

QUOTE(Jim Kring @ Aug 20 2007, 09:23 PM)

Here is an example VI (saved in LabVIEW 8.2.1) that attempts to enable execution highlighting on itself. If you run it, you will see the aforementioned error.

http://forums.lavag.org/index.php?act=attach&type=post&id=6695

http://forums.lavag.org/index.php?act=attach&type=post&id=6694

This works, but it may cause more problems since there doesn't seem to be a way to turn "off" the fake execution state. I guess that the best way would be to set the fake execution state back to 1 (running) since the VI is actually running?

http://forums.lavag.org/index.php?act=attach&type=post&id=6702

[PJM_labview]

Be carfull using fake execution. I found out it tend to make LabVIEW crash every so often (more so LabVIEW 8.2 than LabVIEW 8.0x).

But, yes toggling it back to 1 should work.

PJM

[Jim Kring]

I just heard through the grape vine that this error message will probably be "fixed" in a future version of LabVIEW. So, faking the execution state to avoid the error message is probably safe.

Here's a version with better error handling.

http://forums.lavag.org/index.php?act=attach&type=post&id=6705

http://forums.lavag.org/index.php?act=attach&type=post&id=6704

[brian175]

QUOTE(Jim Kring @ Aug 21 2007, 06:05 PM)

I just heard through the grape vine that this error message will probably be "fixed" in a future version of LabVIEW. So, faking the execution state to avoid the error message is probably safe.

Here's a version with better error handling.

http://forums.lavag.org/index.php?act=attach&type=post&id=6705

http://forums.lavag.org/index.php?act=attach&type=post&id=6704

The "Help" for the Fake Execution State Method only lists valid values as 1 - running and 2 - stopped so I would be careful in wiring the actual state back to the fake state. The help for the scripting props and methods are displayed in the DataAct Class Browser

Since there has been much support for this feature, here is an xnode that performs the task in a LabVIEW native way.

1. place the HighLightExecution.xnode on the block diagram

2. the xnode can be placed on any wire (the input terminal is wired directly to the output for flow control only)

3. click on the xnode to toggle between execution highlighting on and off

Open the "Example.vi" to see it in action

There are many possibilities for enhancements such as using the wire in for a conditional on (similar to custom probes), but this is a good start for now. I'm sure I sould add some additional abilities for copy and pasting, but it seems to handle it without.

http://forums.lavag.org/index.php?act=attach&type=post&id=6706

[Jim Kring]

QUOTE(brian175 @ Aug 21 2007, 07:38 PM)

The "Help" for the Fake Execution State Method only lists valid values as 1 - running and 2 - stopped so I would be careful in wiring the actual state back to the fake state. The help for the scripting props and methods are displayed in the DataAct Class Browser

Since there has been much support for this feature, here is an xnode that performs the task in a LabVIEW native way.

1. place the HighLightExecution.xnode on the block diagram

2. the xnode can be placed on any wire (the input terminal is wired directly to the output for flow control only)

3. click on the xnode to toggle between execution highlighting on and off

Open the "Example.vi" to see it in action

There are many possibilities for enhancements such as using the wire in for a conditional on (similar to custom probes), but this is a good start for now. I'm sure I sould add some additional abilities for copy and pasting, but it seems to handle it without.

http://forums.lavag.org/index.php?act=attach&type=post&id=6706''>http://forums.lavag.org/index.php?act=attach&type=post&id=6706'>http://forums.lavag.org/index.php?act=attach&type=post&id=6706

Thanks, Brian. I think that a custom probe would be preferable (over an XNode) since it does not modify the code. But, in order to create a "universal" probe you would have to create a VI for every possible data-type (ugh).

[Ton Plomp]

QUOTE(Jim Kring @ Aug 22 2007, 05:11 AM)

Thanks, Brian. I think that a custom probe would be preferable (over an XNode) since it does not modify the code. But, in order to create a "universal" probe you would have to create a VI for every possible data-type (ugh).

Uhm scripting?

Ton

[brian175]

QUOTE(Jim Kring @ Aug 21 2007, 11:11 PM)

Thanks, Brian. I think that a custom probe would be preferable (over an XNode) since it does not modify the code. But, in order to create a "universal" probe you would have to create a VI for every possible data-type (ugh).

I was thinking that it should behave more like a breakpoint and should be able to be saved with the code. I haven't done it yet, but I believe that you could code the the HighLightExecution node to remove itself and "repair" the wire that it is on with a RCM "Clear Highlight Execution Point". I would also like to determine if the node is dropped on a wire and automatically "wire" itself in.

If a custom probe was needed, you could create a few for common data types (error, boolean, numeric,...) and that would work in most cases. Then at worst you would have to add a boolean constant and wire to a structure in order to use the custom probe.

QUOTE

Uhm scripting?

Unfortunately scripting won't help here since the data type must match statically. Although, it would be possible for an xnode to create a custom probe based on the wire type. I could add a RCM "Generate custom probe" that would create the custom probe that would work for the wire type currently attached.

[Ton Plomp]

QUOTE(brian175 @ Aug 22 2007, 01:37 PM)

Unfortunately scripting won't help here since the data type must match statically. Although, it would be possible for an xnode to create a custom probe based on the wire type. I could add a RCM "Generate custom probe" that would create the custom probe that would work for the wire type currently attached.

So you should create a library of Probes for a lot of datatypes!

It shouldn't be to much work to get all numerics (+1D and 2D arrays) + some clusters + Enums + Variant+.....

Ton

[brian175]

QUOTE(Jim Kring @ Aug 21 2007, 11:11 PM)

Thanks, Brian. I think that a custom probe would be preferable (over an XNode) since it does not modify the code. But, in order to create a "universal" probe you would have to create a VI for every possible data-type (ugh).

I have added 3 RCM options

1. Disabled - removes all code from the block diagram (should be able to call through scripting)
   
2. Replace With Probe - this ONLY works for error cluster data type now, but replaces the xnode with a probe. the next step is to dynamically build the probe with the correct data type (which is stored in the state). The execution highlighting can be turned off and on by toggling the custom button http://forums.lavag.org/index.php?act=attach&type=post&id=6751
   
3. Clear Highlight Execution - removes the xnode and repairs the wire
   

View of "Disabled" code

http://forums.lavag.org/index.php?act=attach&type=post&id=6752

Updated code

http://forums.lavag.org/index.php?act=attach&type=post&id=6750

I haven't tested this too much so I wouldn't actually use it, but it could be developed further.

Brian