LabVIEW
Zebra ZD420 - checking for "downloaded" fonts
Solved!
@Mark_Yedinak wrote:
I think I need to look at Rolfk's suggestion so I can eliminate the need for the lvimptsl.dll file. This is a bug that NI introduced several releases ago. It has been reported but apparently NI isn't concerned about fixing it. I don't recall which version of LabVIEW broke this but at one point I never had to include the lvimptsl file in the build spec. Then they broke it and obviously given your experience it has not been resolved.
I'm not sure when and if it was safe to call the lvimptsl functions in a build application. It is located in the resource directory and all those DLLs are supposed to be also in the root directory in the LVRTE installation. However I can't see it in any RTE installation back to even 8.x and 7.1. So the other alternative is that it was before somehow added by the application builder to the built despite being located in there, maybe through special casing and it somehow unlearned to do that, or an even more likely cause, it was moved from the support VI library folder for the Import Library Wizard deep inside the resource folder into the top level resource folder and because of that fell under the Application builder exclusion rule to not add it to a built executable/shared library. And that fact got lost in testing, it's esoteric enough to not think about during that quick fix, to resolve for instance a problem where the LabVIEW IDE may have somehow searched for that DLL under certain conditions. Moving it into the resource folder guarantees that it is found almost immediately when the path to the DLL gets somehow hosed in the VIs, since that is one of the first locations LabVIEW actually looks for things. But that search doesn't apply recursively to all the subdirectories in the resource folder as that would make things very lengthy very fast.
The dirty solution would have been to add a special exclusion of the exclusion for files in the resource folder in the Application Builder for this file. The cleaner solution would have been to promote lvimptsl as an official part of the LV RTE and add it to the DLLs that get installed in its root folder.
But my solution is to avoid this shared library altogether by directly calling the LabVIEW MoveBlock function myself.
Going the VSA Driver Wizard path to talk to USB devices seemed like a great idea back around 2000, if and only if you could get the low level protocol specifications for a device. But it's not anymore.
What are your chances to use the driver that Mark posted? That route avoids the problem as it accesses the USB interface apparently through WinUSB rather than trying to install its own driver.
And you of course immediately ask why didn't NI use the WinUSB path themselves. And the answer is likely a combination of several reasons. First WinUSB was and still is not exactly the official Microsoft way to do USB business. They were initially very reluctant to properly document this, as they did not want to cement the interface in stone, to be able to modify it at a whim for their own purposes whenever they felt like. And NI already had been busy developing their own device drivers for all their hardware for quite some time, so leveraging that knowledge was not that a strange idea. Developments in the OS market made it however mandatory that device drivers needed to get signed to avoid the situation that some malware can easily install its own super power backdoor into the OS kernel without any notice by the user. Unless they can steal the private key from a well established software provider (such as what recently happened for several big Android software providers), the user at least gets a warning that an unsigned driver respectively a driver signed from an untrusted source is attempting to get installed. In Windows 10 it is even impossible to install unsigned drivers unless you start up the system in a special debug mode. And a VISA driver wizard driver is also simply a device driver, even if it is in fact only the INF file installing the VISA USB raw interface for a specific device and vendor ID.
The USB driver I uploaded earlier is pretty easy to deploy. You need to include the driver itself in your installer. Best place to put it is in the folder "C:\ProgramData\Zebra Tools\Drivers". I also include the file "lvlib.dll" in that same folder. Last item which needs to be part of your build spec is add the file "lvimptsl.dll" to your project. This file can be found in the "resource" folder in the LabVIEW folder ("C:\Program Files (x86)\National Instruments\LabVIEW XXXX\resource" for example). Create a destination folder called "resource" and place it under the root folder for your project. Then mark this as "Always Include".
This should be all you need to do. The hardest part to manage after that is getting the correct PID for the specific printer model. I have used USBview in the past to get this information. There are too many for me to post them all here. I generally use an ini file to store the USB settings for a specific printer. The library also has functions which can list all of the Zebra printers currently connected to a computer. If there is a single printer simply pick that as the printer and connect to it.
Use “LabVIEW”.(without quotes but case matters) as library name and LabVIEW will link to whatever is the current runtime library.
It’s LabVIEW.exe in the IDE but lvrt.dll or fflvrt.dll, or something else on non-Windows platforms but that special keyword as library name makes LabVIEW always resolve to the right thing.
@Mark_Yedinak wrote:
Where do I find this elusive DLL? I see that this function exists the the file lvrt.dll in the LabVIEW version specific folder (C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-time\LabVIEW XXXX") but this seems wrong since it is using a version specific file. There is also the NILVRuntimeManager.dll file in the "C:\Program Files (x86)\National Instruments\Shared" folder that has this call as well. This seems more generalized to use. But when configured I never see the label "LabVIEW:MoveBlock" as shown in your post. It always includes the name of the DLL file itself.
Also, those images in my post are snippets. Don't you have access to LabVIEW 2018 or newer to open them?
