First time LAVA poster here with my first question. Why do some LabVIEW programmers insist on wiring the error cluster to the bottom of their VI as opposed to the sides as shown in most NI documentation. Is there any benefit to it? Is it 100% a preference thing? Is there a way to make LabVIEW connect error wires like this automatically?
I've only seen it in advanced LabVIEW code from experienced programmers and some parts of the Actor Framework.
Your insight and experience is appreciated!
The introduction of parallel, read-only access for DVRs in LabVIEW 2017 adds a great deal of flexibility to using DVRs to monitor values in parallel executions of code. Fo\The downside of this, of course, is the necessity of using the In Place Element (IPE) throughout your code simply to read the value. Having IPEs throughout your code just to read a value both takes up block diagram real estate and also takes more clicks than desirable to insert.
Similarly, though less frequently, there are times when you only need to update the value within a DVR without actually performing any logic inside of the IPE. This situation is less frequent, at least for me, as I am usually using arrays or classes with DVRs such that I actually need to modify the existing data rather than simply replacing it.
A more preferable solution to the above situations would be to have Read/Get and Write/Set VIs for the DVRs to simplify the process of working with them. This way, and IPE on the block diagram would only be needed when you were actually modifying the existing data within the DVR, rather than simply overwriting or returning the current value.
Thanks to the power of malleable VIs and the type specialization structure that is now officially released in LabVIEW 2018, a better solution is now available. I’ve created two malleable VIs, Read DVR Value (Parallel) and Write DVR Value that allow you to perform a write and a parallel read on any DVR data type.
Now, you can use a single VI that you can insert via Quick Drop to read or to write DVR values.
Download the attached ZIP file to access the two malleable VIs and example code, and please let me know your thoughts in the comments!
DVR Read and Write VIs 1.0.0.zip
I have a simple program which has only 2 buttons for the user interface. When the user clicks OK I want the program to get into the event structure case called "OK Button". Once it is inside there is a loop which continuously waits for 1 second until "Stop Button" is called from the user.
But because once the user presses the "OK Button" the program gets into the event and therefore I can not call the "Stop Button".
Is there a way to call the "Stop Button" even if the program is inside the event ?
By A Scottish moose
TL;DR - Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework? I've got some library code that would be valuable but the project itself doesn't justify AF.
I'm brainstorming ideas for a tester that I'll be building over the next few months. The project that I'm currently winding down is an Actor Framework test system that has come out really nice. Part of the project was an actor built to handle all of the DAQ and digital control. The main actor spins it off an tells it when and what tasks to launch. It send back data and confirms commands, uses Dynamic events to keep up with the generated signals, and uses actor tasks to ship the data back to the controller. Works amazing. Nothing revolutionary for sure but very handy.
This next project doesn't really need actor framework, it's much smaller and has a lot smaller list of requirements. That being said I'm curious about integrating my DAQ actor (Dactor, because who can resist an amalgamation?!) into the project. Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework? Is this even possible based on how the AF tree is designed to work?
Thanks for reading!
Here's a heads-up for any LabVIEW developers in Central Texas, or any Certified LabVIEW Architects coming to Austin for the CLA Summit next month. I will be teaching Actor-Oriented Design in LabVIEW, Sept. 13th - 15th, in the training center at NI's corporate headquarters. Come take the class, enjoy Austin for the weekend, and stay over for the Summit! Details on the course offering here:
Actor-Oriented Design in LabVIEW
There are offerings in October as well, in MI, MA, and Santa Clara, if those locations are more convenient.