Leaderboard

It’s only 1d 8hours left http://livestream.com/accounts/4609552/events/4211315

Sweet. Check back next week for version 2.0.0.

This will let you connect any 1D array if you really hate polymorphic VIs and xnodes

I find this thread quite interesting as this is a good problem that we have all been facing for a long time. Our team did some research last year to try to create a unified error handler similar to the SEH that would meet all of our requirements but in the end, after testing a few different flavors, we chose to integrate our error handling as a separate state in our templates. We do this in a very similar way that JKI State machines template but we include a few more parameters such as which case was the error generated in (to facilitate debugging) as well as automatic logging and display in a non blocking manner. Based on the error code, we can either let a default behavior programmed in a Sub VI or override the handling of any specific code or range of error codes on a "per code module" basis. We could not find any other way that would offer us the flexibility and reliability that we need in our projects. We find that by including it in this way, as part of our template, our developers were much more inclined to add the proper error handling code as it was easy to do so. Moreover, that specific code is visible on the BD (not hidden in an Express VI.) With this approach, it is easier to handle specific errors in each module/driver and it is almost "synchronous" (in between each cases). This seems to be better than generating an event when an error occurred which would still only be handled when your code gets back to the event structure. As for the format, we find that the current cluster offers enough information even though the default "tags" in the Source element are not obvious at first. The idea of objects and more complex error handler built in a smarter subVI is nice but we have given up on finding the silver bullet and went for a practical approach that work well in our code. We'll definitely keep our eyes open in case something better comes around...

I did something similar, but no LVOOP http://forums.ni.com/t5/LabVIEW/Plink-PuTTY-works-30-of-the-time-using-System-Exec-vi/m-p/3006795#M860452

Local means the same application instance, so separate projects in the same LabVIEW should be remote. Though there is probably some sharing going, on given what hooovahh posted.

So I did a quick test out of curiosity. I created two projects, in the same version of LabVIEW. So this should be two different application instances. In one project I got a reference to a boolean control, then used type cast get the array of bytes that the reference represents. In the other project I typed in the array of bytes then used type cast to convert the data back to reference. Then I registered for the reference on a value change. To my surprise I could actually register for the control, and it worked as expected. I tried the same thing on two different versions of LabVIEW, but that didn't work. It stated the reference was invalid. Not sure if this helps clear up, or muddy the definition of local objects or not.