lvb

Just booked my plans as well.  I am looking forward to meeting some more LAVA members at NI Week this year.

Looking forward to the BBQ.  A word of advice from a previous mistake: wear shorts!

The UML Sequence Diagram is pretty useful for documenting Actor interaction.  See the example I created at https://decibel.ni.com/content/message/46192#46192 for an example.

There is also a LabVIEW implementation of this at https://decibel.ni.com/content/docs/DOC-28748

I think every professional LabVIEW developer should take advantage of virtual machines.  Although, I do not recommend running VM's on your primary PC.  Some advice/tips:

• VirtualBox
  It has fantastic remote desktop support.  It is also free.
• P2V
  There are a few tools out there that allow you to do a Physical to Virtual conversion.  I have used this in the past to convert a "real" machine shipped to a customer into a "virtual machine" that I can fire up at any time for support reasons.
• Snapshots
  Allows you to instantly save the "state" of a machine and restore it (while the OS/application is running!)
  

We run a Linux server at my work that hosts multiple VirtualBox machines (one for every version of LabVIEW).  Developers access this over RDP.  I use these VM's on a daily basis.

I found a related topic on the idea exchange:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Need-a-way-to-visualize-VI-call-chain-hierarchy/idc-p/2351162

I would suggest that you open the BD of every VI whose state is Run Top Level and then manually inspect their BDs for subVIs with the green arrow. This would at least minimize the amount of VIs you have to check (unless you open many dynamic VIs).

That seems feasible.  Time to start hacking!

I should probably add this to the idea exchange.  I am really surprised this is not in VI server or scripting.  Seems like a really basic and common piece of information.

Things you can do -

1. Add special code to the VI so that it logs when it starts running.
   
2. Use the Desktop Execution Trace Toolkit, which should give you the VIs which are actually running. I think that it might also be possible to tap into that data yourself somehow, but that's not public knowledge. Maybe if you know the right people at NI you could get that info.
   

Those workarounds don't really satisfy my use case: I need to find out what VI (front panel hidden) is still running in a large application.  Often this code is written by multiple developers.

1. If I knew what VI was the culprit, I wouldn't need to add code because I could fix the bug.  

2. Tracing often changes the run-time behavior

Things I currently do - Open the front panel of EVERY VI and look at the run button state.

I was hoping that I could hack some scripting to grab the front panel window, but it does not return the toolbar.  Is it possible to get an image of the entire front panel window including toolbar?

Is it possible to get the actual execution state (running/waiting to run) of a VI?

The Exec.State property node returns "Running" if a SubVI is waiting to run or if it is actually running.

I would highly suggest the LabVIEW Task Manager.  You can see which VIs are running "RunTop" and either abort, open front panel.

I can share your pain.  I have run into similar issues with Actor Framework messages.  I think the Actor Framework exposes some of the corner cases for LabVIEW's error detection and compilation.  I would fully expect LabVIEW to provide a broken VI for your Send Message function.

I would suggest posting this to the Actor Framework forum on the dark side.

Thanks for the response.  I agree that the best way to relink is to always rename from a LabVIEW project with everything loaded into memory.

I am attempting to write a refactoring tool that can fix the "missing items".  This tool should be able to work with items that are no longer available.  The only way I have been able to resolve this within the LabVIEW IDE is to find the block diagram item and replace with... in the pallet or using quick drop replace.  A tedious process.

I have another post in the scripting forum with some issues on the replace missing method here.

I am attempting to create a scripting VI that will replace missing VI's and other LabVIEW objects (type defs, classes).  I would like to specify the fully qualified name of the old item and the path to the new item.  Any tips on how to do this?

At this point, I can Traverse for GObjects but am having some trouble identifying the properties of the missing VI's.  The scripting nodes return the following error at the VI Name property node when the VI is missing:

Replace SubVI Test.vi

If a library was renamed and some of the callers were not in memory/loaded, what is the best way for updating these?  It would be ideal if LabVIEW accepted an object with a different namespace in the "Searching..." window, but it does not.

That was easy, I just added an extra input

Just place the attached file in the Symbio-GDS folder:

..\LabVIEW 20xx\resource\Framework\Providers\Symbio_GDS

And make a VI like this:

Cheers,

Mike

Thanks, this is great!

Is there a way to create icons with the default options for an entire class/library? I have some legacy code with no icons that I would like to update and I would really like to use the GDS icon editor.

I noticed the same thing here. I haven't changed anything in my profile.

Looks great! I am looking forward to testing this out with some Actor Framework projects.

I've been using notifiers lately to post the state of a class throughout the application. This has become a very easy and convenient way to create some basic user interfaces and share class data asynchronously.

Just wondering if anyone else uses this technique (or User Events)? Any pitfalls?

Is there anything that would make you more "delighted" without covering every available right-click menu option?

How about a hook into LabVIEW to allow developers to add their own right-click menu items similar to the "JKI Right Click Framework"?

Oh, BTW, I forgot to mention this earlier, but the multi-select right-click not working in the Control Editor (and thus also for LVClass private data) is a bug that has been reported and should be fixed in a future version.

Thanks, I will take a look for the CAR

Even more confusing:

Select multiple items in LVOOP class private data. No right-click menu is displayed!

Based on the narrow scope of this KB article (Comparing Two VIs in LabVIEW), other platforms don't get a compare tool? That seems crazy, though, since it's only written in LV anyway (I think).

From here they do:

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/configlvcomp_thirdparty/

I am sure that someone has come across this problem before. What is the best method for determining the LVCompare.exe path? Is there a cross-platform solution?

I am looking to update some Hg tools to support cross-platform operation. My initial thought was to use the "Get System Directory.vi".

Does anyone know what the default paths are for Linux and OSX?

I have seen the similar issues creep up also. Non-FTDI serial interfaces became unreliable after an upgrade from 2010 to 2011.

I am very interested to see if your support request can get to the root cause.

Does anyon know if Norm's state machine has been born yet? I sure hope we don't have to wait 9 months after NI Week...

Rebirth of the LabVIEW state machine

8/6/12 (Monday 6th),4:30 PM – 5:15 PM,17 B

Norman Kirchner, Senior RF Systems Engineer, National Instruments

Well you are right that Flatten Variant doesn't work. I was mislead by a quick trial and had no time to verify further as I had to leave for private obligations. However I can't accept defeat so I remembered another post where someone wanted to have an VT_NULL Variant and investigating into the solution I have come up then showed an easy and totally official way to do it. The VARIANT memory layout is fully documented on MSDN and the LabVIEW Call Library Node supports explicitly the ActiveX Variant type. So simply passing the Variant as ActiveX Variant pointer to a C function that looks at the first two bytes in the structure is all that is needed to get at the VT_ values.

Enclosed are the VI to create specifically a VT_NULL variant and the VI to read the VT_ type. I haven't entered the entire range of VT codes into the enum and since those codes are in fact not continous it is probably better to use a Ring control instead but that is an exercise left for whomever is wanting to use this VI.

Very impressive. Thank you!

For others interested in rolfk's solution, check out the DevZone article on MoveBlock here.