LabVIEW Idea Exchange

This is something that started as a way to get data back from Actors in non-actor code (for example, web services). I've never cared for the blocking nature of Reply Msgs and the only other built-in option for getting back data is to make everything an Actor, which is not always an option. Promises solve both of those issues.

The basic idea is an enforced single-writer, many-reader cross thread datatype. In the current implementation, they are not much more than a locked-down, single element queue but you can actually do some pretty cool stuff with just that.

In the message sender, we create the promise and return it. The idea here is that the Actor owns the promise and will fulfill it. This gives us very low coupling for free.

Wait on Promise will wait for the Promise to be fulfilled. It is a malleable VI so that a Default Value (for timeout) and Type can be wired. Using the timeout lets us do other things while waiting for data.

Inside the Actor, we can set the value with Fulfill Promise. Remember, once the Promise is set, that's it, no changing it again. In fact, Fulfill Promise will error out if called twice on the same promise.

Something else really cool we can do is fulfill a promise with another promise. This may seem pedantic at first but it can help keep your code cohesive by passing the responsibility of fulfilling a Promise to another process. For example, if you have a message broker that just forwards a message, you can have the message broker fulfill it's promise to the caller with a promise from the callee.

We can also reject a promise with an error message that will be returned by any Wait on Promise that tries to read it. Rejecting a promise does fulfill the promise so you still cannot set the value later and you cannot reject a promise again.

Finally, we have Destroy Promise. It does exactly what it says on the tin.

I'd love to hit some more of the design points from https://promisesaplus.com/ (mainly adding Then callbacks) but I figure it's at a pretty good spot to share and get some feedback. I'd also like to try to figure out network communication at some point but that's probably a ways away (without some help anyway ).

I'm hosting the code at https://github.com/kgullion/LabVIEW-Promise if you are interested in checking it out or contributing!

Please provide a setting to exclude unspecified folders.

I started a Mass Compile on one folder. Whoa, it did more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I was surprised that I gave it one folder to recompile and it saved called Vis even if they were in other folders above and outside of the one I had specified. I didn’t think to back those up.

NI's code should be excluded! Many VIs are installed as part of LabVIEW in the C:\Program Files (x86)\National Instruments\LabVIEW folder. These should NEVER be modified outside of installs/upgrades. I started a Mass Compile and, whoa, it did much more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I didn’t think to back that up. Now I fear my LabVIEW installation is dirty. NI SR#7722650 says "It does go outside of the specific folder if the VIs in the specific folder depend on another VI outside of the folder. When it goes outside, it is just opening the VI and resaving it in the current version of LabVIEW. Because your VIs depend on some VIs in the ... vi.lib it went and resaved them. But, they are already in LabVIEW 2015 SP1, so it will not change anything in them. It does this to ensure the VI is looking at the current version of LabVIEW and not an older version." If that is true, why would installation of a version of LabVIEW install VIs of older versions? Make sure all vi.lib VIs are already compiled for that version.

I found https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Force-Recompile-option-in-Mass-Compile/idi-p/2659839 which discusses whether or not LabVIEW Mass Compile changes files that are already up-to-date.

Mass Compile changes files that do not have a LabVIEW code extension such as ".ctl" and ".vi"! Why is it trying to load, check, and save files with extensions such as ".bak" and “.err”? The following example shows files that a prior mass compile found problems with and I renamed them and removed them from source code control.

  ### Bad VI:    "EditString.ctl.err"              Path="C:\cvs\r8000\labview\app\editor\controls\EditString.ctl.err"

  ### Bad VI:    "MCNavigate_old.vi.err" Path="C:\cvs\r8000\labview\app\remote_control\MCNavigate_old.vi.err"

Another example of this is described in https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Mass-Compile-should-not-touch-Subversion-files/idi-p/1081483 which says files with ".svn-base" are changes. Yes, there was a specific improvement made to ignore those, but really, that wouldn't be necessary if Mass Compile stuck to known LabVIEW file types.

We can get the top level VI using property nodes / call chain, and we can also determine the running state of any specific VI (given a path).

It would be really useful to know which VI was running as any point in time (without resorting to execution highlighting) - not really applicable to time critical applications of course.

Uses for this include:

1) the abilty to change a VI execution state from Modal to normal with custom created dropins - if required.

2) Automation - it would be really useful to retrofit projects with a tool/dropin for soak testing / debug which detected certain windows - normally these would be modal dialogs and entered data in them to allow the program to continue (I know these features can be built in at the start of a project, but dropping in later would be very powerful for pre-existing ones and allow the use of the NI dialogs.

3) simple debug - code is stuck, exection highlighting is not showing where. This would give the answer.

James