Neil Pate

The difference in the Value output type can be caused by the mechanical switching mechanism that is configured on the boolean. I don't have LabVIEW on the PC I am on now and I can never remember their names properly, but only the top row of the mechanical switching mechanism will give you green boolean value.

Can you show us what the control on the sub VI is please. Also the Context Help window might provide some insight into why this wire is broken.

There is no need for the timed loop as the DAQ itself has a timing source. Just use a regular loop and ask the DAQ for a certain number of samples. This will accurately fix the loop rate. Also, to get up and running just try using a regular queue. Although you need to be a bit more careful on RT there is no good reason they will not work unless you really need to get every last ounce of performance from the system. I have never been a fan of shared variables, too much "magic" going on behind the scenes for my liking.

A Radio-button has a natural interlock mechanism. You can customise the booleans to be regular buttons and also change their positions to get a 2D grid type feel if that is what you want.

I did not try and translate any filenames. Only strings, numerics and booleans.

I have blocked out those painful memories...I did eventually get something working which is robust, but if I recall it was pretty ropey until it worked properly (lots of weirdness...).

Not true at all. I have an application I developed that includes on the fly translation to pretty much any predefined language using UTF8 string lookup files. It works fine on my English language Windows (developed on Win 7, works fine on Win 10). Obviously you need to have the correct language packs installed in order to get the fonts. Picture is a snippet from one of the translation files.

What do you mean by this?

Wow, that is keen!

🤣 sounds like a cash converter service...

I had a real struggle with some USB3.0 cameras and a Windows 10 PC. They were Basler cameras, and even Windows device manager sometimes did not pick them up. They would regularly just "not appear" in MAX. Never managed to solve the problem to my satisfaction and pretty much decided to not use USB hardware.

Now that I think about it, I also cache the This VI ref in another VI which I use as sort of an actor debugger to allow me to open the FPs and BDs of any running actors including clones (not AF actors, my own home rolled framework). I poll all the refs multiple times per second to get status about the clone name and running status, and have never seen any weird crashes which I have attributed to that.

I think the warning is related to the Open by name. I really hope so as I too use the technique you describe where the clones themselves get their own references so that they can insert themselves into a SubPanel (and do other stuff to the FP like title etc). Been using this architecture for five or six years now and never had any run-time crashes I can think of.

This works. Note in my example I do not wait for the command to complete, I test for the result in some downstream code not shown in this snippet.

Search the forums for calling a batch file from inside LabVIEW. Sometimes it can be a bit tricky to get the path right with the all the "" that you need. I dont have any code in front of me that does this right now, I can dig something up in a few hours.