DLL functions or shared variables? Or something else?
I have a Labview 2014-64 executable (or I can build a DLL) that runs one piece of equipment, the X-ray. The other engineer has a large CVI Labwindows 2015 + MS Visual Studio 2012 (C++) executable that runs everything else. I want the Labview code to be a slave of the CVI code, accepting commands to turn X-ray On or Off, reporting failures, and the like. Translating the X-ray code into C++ would be possible in principle, but not fun.
Shared variables look easy, but I'm kinda scared of them. I would define all the shared variables in my LV code, since I'm more familiar with LV, then use them in both. There's a thread in here called "Shared Variable Woes" so maybe I should be scared. In the alternative, I tried building a proof-of-concept DLL in Labview, and calling its functions in CVI/C++, and it works, but it's kinda clunky. (I'm attaching it below in case you want to play, or advise.)
Your advice would be appreciated.
By Gan Uesli Starling
We have a gage supplied by a company that shipped it with a *.exe application targeted for LVRTE 2009. I need to retarget it for 2017, but don't have the source code. The supplier had said they'd gladly supply me with a copy of the *.LV source, but they have looked and cannot find their own copy in-house.
History of Need: Our global corporate mother ship's IT department, in their infinite wisdom, is mandating an upgrade from Win7 to Win10. That with yet even further constraints. They enforce a list of "approved versions" of "approved applications". And for LVRTE, they are insisting upon 2017, with 2009 being a red light.
So, then, my query. Is converting an app without the source for a higher LVRTE doable at all? File is attached.
If it is doable, instructions on how?
I'm trying to execute LPR.exe command to print some labels on a printer. However as its normal, problems occur. I could not find answer on any topic conneced with "sytem exec". I already tried all described methods (I think so). That's why I'm asking very kindly for any help.
When trying to execute or call the LPR.exe from System exec VI, I'm receiving error:
"'C:\Windows\System32\lpr.exe' is not recognized as an internal or external command, operable program or batch file."
Generally I would like to call function: "lpr -S 192.168.1.5 -P lp C:\test\do_druku.txt" which works from command window without any problem.
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