Porter

I'm a bit late to the party, but this is a great use of the Tag Engine and muParser. Use cases like this were exactly what I had in mind when I released those libraries. I've also been asked several times about implementing something similar. One suggestion would be to always use labels rather than captions. Personally, I would never consider using captions for this purpose. I would also introduce a flag character, such as @, as the first character of the label to indicate that the control's value should be updated automatically. Another improvement would be to allow the user to specify whether a control should be updated on a tag value change event or on a periodic interval. For periodic updates, I'd have the control values refresh every X milliseconds (user-configurable), with the timer reset whenever a control value change event occurs. Perhaps the second character of the label could be used to indicate this option, with periodic updates as the default behavior. Why update periodically? In many systems, data arrives much faster than it needs to be displayed on the UI, so periodic updates can reduce unnecessary processing. I would also avoid writing directly to tag values. Instead, I would use a Tag SetRequest event. In my view, the UI should not write directly to tag values. Hmm... maybe use the third character of the label to decide this? Looks like maybe all of these flags need to be contained within some brackets. Parsing labels as expressions is a nice idea. It had never occurred to me to do that. My usual mindset is that if a value is important enough to be displayed on the UI, it should already exist as a tag. Anyway, all this to say. Thanks for sharing what you have done. Nice video. And it would be great if you could share the source code so that everyone can try it out and learn from it. And maybe even improve it.

Nice use of Tag Engine and muParser. I've done similar but without the nice UI. Is this an open source project?

Also if you could post or PM me a screenshot of your test code, I might get a better idea of what could be causing the problem.

Its worth noting that I kept the VISA locks in place only to (possibly) support multiple applications trying to access the same VISA resource. I implemented my own locking mechanism using a single element queue as a mutex for locking within a single application instance because the behavior of VISA locks (at the time) was erratic. You might want to try removing the VISA lock/unlock calls from the MB_VISA_Lock library and see if that helps. Another culprit could be the VISA flush in the TX ADU.vi. I have once come across a serial device that didn't like the flush command. Try replacing it with a read all bytes at port.

It should work as long as you have NI VISA working on the cRIO and you are using the correct serial port name. You should be able to use serial ports named with the ASRL#::INSTR format.

Glad to hear that it was useful for your test. Thanks for the feedback!

They did say that maybe Unicode support is coming to LabVIEW. I would give LabVIEW a plus for that.

Thanks for bringing this to my attention. Not sure why the dlls and so files were stripped out of the source distribution's always included list. This is now fixed in v3.1.2.1

Thanks Rolf for the thorough analysis. I axed support because cross compiling for 32-bit Linux was another hassle, and I suspect that nobody will ever need it. I also noticed that the produced .so was 3MB which seems to be abnormally large and I don't have time to figure out how to get the size back down to a reasonable 300-500kB.

Done. New error code offset is 515000. I also compiled muParser for cRIO RT Linux. You need to manually copy the .so file to /usr/local/lib/ on the cRIO then run ldconfig. Linux 32-bit support has been axed. There is no 32-bit LabVIEW for linux since 2016 if I'm not mistaken.

I would just post it. You can plaster it with a 0-Clause BSD license and walk away. Zero-Clause BSD – Open Source Initiative That way if someone likes they can just take over development without bothering you. It looks like an interesting project but I have no experience with xControls so I wouldn't be the best person to maintain it.

Seems like the 500 000+ range would be a good place for these standard but non-NI certified error codes to go. I will make another release that will be focused on improved error handling/reporting. I can see a few VIs that should be touched up in this regard.

1) That is indeed the expected behavior. Variable values must be explicitly specified. Their default value is NaN. Note that you are defining x,y,Z as constants in the above example. 2) I was using 5000 range because this package is not NI Tools Network certified and therefore I have no reserved an error range to target. If there is a better starting number, I am open to suggestions. I would not propagate an error code offset input all the way to the top level though. Best to just pick a range and stick with it. But I do understand that 5000 is commonly used at the top level of user applications.

I have uploaded the new release to vipm.io We are now at release v3.0.0 since this is a breaking change. I also started some documentation: LV-muParser User Guide.pdf

There is also Tango Desktop Project which is public domain.