Leaderboard

So lets say I have a single project, and in it is two targets, a Windows host, and the RT. Many of the libraries I use in the Windows side, I also use on the RT side. But I think that this is causing lots of unnecessary "Compiling" of VIs over and over depending on which target I'm open the code from. Here's an example. I have a Windows Main.vi, and a RT Main.vi both under their appropriate targets. If I open the Windows Main.vi it opens relatively quickly, and loads about 2000 VIs and shows the main. But if I then open the RT Main.vi, it goes through and compiles about 200 of those VIs taking several minutes to open. So after both are open I perform a Save All, thinking whatever it needed to compile and do it should be done with. If I then close the project and re open it, and then open the Windows Main.vi it has to recompiles those 200 VIs presumably for the new target, and then if I open the RT Main it has to recompile those 200 VIs again. Is this how it is supposed to be? Every time I reopen a VI on a new target am I supposed to see it recompile for that target back and forth depending on where it was opened last? The project has a mix of VIs that have separate compiled code on and some with it off. Not sure which is better for this. My computer is relatively powerful, but lately doing LabVIEW development makes me feel like I'm using a 10 year old PC. Everything about my computer seems fast except LabVIEW development. Is there tips or tricks, or options I should be using to help make my LabVIEW development more responsive, and require less recompiling when switching targets? EDIT: It seems that the VIs that need to recompile all the time are VIs that are in a Polymorphic VI, so the majority of them are reuse and OpenG VIs. Double Edit: It seems this thread from an older post on LAVA claims that the compiled cache has separate entries for a VI on multiple targets, so I'm not sure why these VIs need to recompile every time...

The attached VIPM contains an extension of Messenger Library that is intended to add extended functionality to controls/indicators, via a background process that is launched and which registers for the events of the control (the background process is a Messenger-Library “actor”). This is meant to be an alternative to XControls. Included are two “Augments”, both with examples. See <examples>/drjdpowell/UI Augments/Examples/EXAMPLE Twin Cursor Graph Augment. This takes any graph with two cursors and draws a line between the two and displays summary info of the data between the two cursors: There is also a cross-section plotting for a 2D intensity chart: This package is in LabVIEW 2015, and requires Messenger Library (latest, in the LAVA-CR) and JSON LabVIEW and Shortcut menu from Cluster (both in the LAVA-CR). drjdpowell_messenger_ui_augments-1.0.0.8.vip

Crosspost Honestly not sure which thread has more discussion. (BTW Shaun I gave you a like)

For the record - my reply to the same question I received via PM: Waptia works as generic optimization algorithm - you have to provide a function on a number of parameters and algorithm tries to find such set of parameters values for which the function value is the highest. So you'd have to describe any face with a set of variables and write a function in LabVIEW which evaluates how well given set of their values describe face in the given picture. Personally I doubt Waptia is the right direction for such application and even if it is, it's only one of many blocks needed.

The best thing about UDP jokes is that I don't care if you get them or not.

Here's a VI that shows how to do the same thing, but with public properties/methods. Saved in LabVIEW 2012. Get Owning Project Name.vi