New config tokens in 8.6 to help you tap into exec hilighting

[Aristos Queue]

Last year, user vugie posted VIpreVIEW

http://forums.lavag.org/VIpreVIEW-Interact...iew-t10211.html

It allows you to create a Flash application from your VI, so you can post your VI to the web and people can still flip through the frames of the case structures to see all your code. Kind of neat.

Someone commented that it would be cool if you could record a VI running and create a movie playback of the execution highlighting. Well, that turned out to be a hard problem given the access you have into LabVIEW. So I slipped in a bit of code right at the end of the 8.6 release cycle to help with this situation. And then I forgot to post about it when we released 8.6. :-) So here it is... It isn't the easiest to use, but the runtime engine has a very restricted set of information available, so the hook I'm providing, while primitive, is about as advanced as you can hope for.

This is an .ini token you probably already know about:

DPrintfLogging=true

If this is in your config file, then LV will log a whole bunch of information to the same log file that DWarn dialogs get saved to. It's a huge amount of junk and most of the time you don't want to read through it. (Side note: Trust me when I say these logs are boring. I sometimes wish that customers would edit their log files before they send them to NI to include some salacious gossip or poetry or a really good joke just so that when I'm reading through the logs trying to debug something I could hold out hope that something interesting would be included instead of the mind-numbing stream of hex addresses and object IDs...)

I have added a new token. The new token only works if you have DPrintfLogging turned on. The token is

ExecHiliteTracing=true

When this is enabled, LV will print to the log file information about execution highlight drawing. Every line starts with this text:

ExecHiliteTrace

and is then followed by a single character that indicates how to interpret the rest of the information (described below).

When execution highlighting begins on a given VI, LV will print a line like this:

ExecHiliteTrace+ 0xABCDEF01 c:\foo\bar.vi

The hex number is a unique ID generated for each VI, guaranteed to be the same as long as that VI stays in memory. The path is the path to the VI that is highlighting. If the VI is unsaved, this will print out NULL, so the info is useless for unsaved VIs, unless you know for sure that only a single VI is currently highlighting. Reentrant clones will each have their own index, but the paths will be the same as the real VI. Note that this line may be printed multiple times while execution highlighting is running. This indicates that LV has switched back to this VI to update it some more. If multiple VIs are executing in parallel, you'll get one of these lines every time LV switches to a different diagram.

Every time that an execution hilite dot draws, we will print out

ExecHiliteTrace: 0xABCDEF01 x y

where x and y are screen coordinates where the execution highlighting dot drew. You'll have to figure out which signal is at these coordinates. A pain, I know, but there's not much I can do to help it because there's nothing else I can print out that has any meaning at the G level where this information would be parsed. I can't return any refnums because that would require allocating them, and that's not safe to do during exec highlighting.

When the exec highlighting needs to change which frame of a structure node is visible, you'll get this:

ExecHiliteTrace~ 0xABCDEF01 frame top left bottom right

where frame is the frame index that needs to display and top, left, bottom and right are screen coordinates of the corners of the structure node. I can't print anything that can be more directly mapped to which node -- you'll have to search through the struct nodes of the diagram and figure out which one is the one to change frame. This should always be a structure node that is already visible, which means there will always be a unique node that these coordinates map to. The only exception to this uniqueness could be if you're using lots of nested sequence structures -- we might have lots of sequence structures all flip to show frame zero at the same time. But honestly, I'm not too worried about making this work for people who have lots of nested sequence structures. :-)

When execution highlighting is turned off on a VI, you'll get

ExecHiliteTrace- 0xABCDEF01 c:\foo\bar.vi

Ok... so what do you do with all these print outs? Open the LV log file and remove all the lines except those that start with ExecHiliteTrace. "grep" is a spectacular command line tool available on Mac and Linux and you can download versions online for Windows. Now use the remaining lines to generate playback information for a VI. VIpreVIEW could use this to actually create a movie of the VI running. I've always wanted to build an exec highlighting flight simulator, where the nodes are shown in 3-D and you have a "first person view" of being the data going down the wire, with barrel rolls whenever you switch to a parallel wire, and the nodes exploding as you fly over them. Someone could use this info to build such a movie. You're free to brainstorm your own...

Summary:

QUOTE

+ starts exec highlighting for a given VI

: is a dot of highlighting drawing

~ is changing which frame of struct is visible

- ends exec highlighting for a given VI

Enjoy!

[Yair]

Personally, I can't say I see the use in this feature, although it's definitely nice to have R&D people take some free time they have left and use it to do something for the users which would probably not get done otherwise.

Now, if NI was to create functionality which would make the sharing of code easier (like the tool you mentioned or like the CCT), that would be something, but would obviously take more effort.

[vugie]

QUOTE (Aristos Queue @ Jan 23 2009, 05:55 PM)

Last year, user vugie posted VIpreVIEW

It allows you to create a Flash application from your VI, so you can post your VI to the web and people can still flip through the frames of the case structures to see all your code. Kind of neat.

I would like only to mention that VIpreVIEW project is not dead but suffers from sickness called "notimeness". I have some children who demand my attention louder than it...

[Tomi Maila]

To really be able to visualize block diagrams online with Flash etc, the block diagram structure would need to be exported to something like XML and images for each object within the XML would then need to be exported individually. Then a flash application could construct an interactive preview of the block diagram, where user could browse case structures, event strctures etc and maybe even get context help. Is there an XML schema for VI structure used by NI internally?

Tomi

[Aristos Queue]

QUOTE (Tomi Maila @ Jan 26 2009, 03:10 AM)

Is there an XML schema for VI structure used by NI internally?

Nope.

[Tomi Maila]

QUOTE (Aristos Queue @ Jan 26 2009, 06:07 PM)

Nope.

Good, then specifying a new VI schema would not be duplicate work

[Yair]

QUOTE (Aristos Queue @ Jan 26 2009, 06:07 PM)

Nope.

QUOTE (Tomi Maila @ Jan 26 2009, 06:39 PM)

Good, then specifying a new VI schema would not be duplicate work

Ziiing!

Actually, 8.6 does ship with some vi.lib VIs (in _script) which use some sort of schema for scripting VI elements. I'm assuming that this isn't complete, but it could probably serve as a base for something like this.

[jzoller]

QUOTE (Aristos Queue @ Jan 23 2009, 09:55 AM)

... (Side note: Trust me when I say these logs are boring. I sometimes wish that customers would edit their log files before they send them to NI to include some salacious gossip or poetry or a really good joke just so that when I'm reading through the logs trying to debug something I could hold out hope that something interesting would be included instead of the mind-numbing stream of hex addresses and object IDs...) ...

The token is obviously capitalized incorrectly. It should be "DPrintFlogging".

This looks very cool, will check it out.

Thanks Aristos!

[hooovahh]

QUOTE (Tomi Maila @ Jan 26 2009, 04:10 AM)

To really be able to visualize block diagrams online with Flash etc, the block diagram structure would need to be exported to something like XML and images for each object within the XML would then need to be exported individually.

That would be really cool in that from there we might be able to produce some kind of open source standard for saving a LabVIEW VI. I heard there was a topic a while ago to save a VI as ASCII art, but it didn't go anywhere.

[Aristos Queue]

Actually, 8.6 does ship with some vi.lib VIs (in _script) which use some sort of schema for scripting VI elements. I'm assuming that this isn't complete, but it could probably serve as a base for something like this

Those VIs are just a way of declaring instructions for what to script. They do not constitute a save format at all.