Custom device calling dll

[kevin.key]

Hello,

I am trying to create a custom device using a third party .dll and labview library vi's. To get started, I developed a Real Time Labview project to control the power supply. I got that working and was able to control the power supply successfully.

So now, I've been trying to go from there and create a custom device. Using the custom device template tool I generated an asynchronous project. Without modifying anything I built the custom device and deployed a system using it. The system defintion deployed without error so that seemed to work. Then I added all of my subvi's, the llb from the third party, and the dll's from the third party to the custom device project. I incorporated controlling the power supply with constants just to see if it would work. After including all my files into the engine and building again, I tried to deploy the updated system and I got this error message:

Error 1003 occurred at _RT Engine v6.vi >> Launch Custom Devices Async.vi

Possible reason(s):

LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
=========================
NI VeriStand:  
Custom Driver: c:\ni-rt\VeriStand\Custom Devices\Chroma Power Supply\Chroma Power Supply Engine.llb\Chroma Power Supply RT Driver VI.vi failed to load.

The RT Driver vi's run button is not broken in LabVIEW so I'm not really sure what the problem is. I suspect its something with the way I'm trying to link the dll but I don't know.

Any help would be greatly appreciated.

Thanks,

Kevin Key

[Jarrod_S.]

My first suspicion is that your custom device VI can't find the third-party DLL. Have you copied the DLL to the RT Target running the VeriStand Engine? Try copying your DLL to c:\ni-rt\system and try to deploy again. That might fix the problem.

There are also ways that Custom Devices provide to help keep track of dependencies like your DLL to make sure it automatically gets deployed to the RT Target. You could statically have it copied and waiting in c:\ni-rt\system on the target, but having it be part of the deployment will make it much easier to port this Custom Device to some other RT Target in the future.

The first thing to do is to make sure the Custom Device Project that the Custom Device Template Tool generated has the third-party DLL as part of your build specification, so that it will get copied along with your custom device files whenever you rebuild them. This will also ensure that a copy of the DLL resides next to your custom device files that NI VeriStand uses, so it's easy to find.

Once that's done, there is a function in the Custom Device API you can call called NI VeriStand - Add Custom Device Dependencies. Pass in the reference to your custom device. Then you specify the source path for your dependency file and the destination on RT. Again, for a DLL I'd recommend that to be c:\ni-rt\system, but you could also put it next to your other driver files.

Let me know if you have any questions about this!

[kevin.key]

Hey, thanks for the reply.

I've had the .dll's copied to the RT in c:\ni-rt\system because I needed them for running the real-time project.

I want to go the route of having the dll's apart of my deployement, but I'm slightly confused about some options. The first step of adding the .dll's to the build specifications. I have added the .dll's to my project under the .lvlib--is that the correct spot? Then I right click the Engine build specifications and go to properties. I set the .dll's to be always included and I put them in the support directory.

Then I added the NI Veristand - Add Custom Device Dependencies. I connected it into the device reference in a random spot--don't know if it matters where. Then I added a constant for the dependencies. I put 3 different .dll's in it, one example is chr52912.dll:

source->path: chr52912.dll

source->type: To App Data Dir

RT Destination: c:\ni-rt\system\chr52912.dll

force dlwonlad: true

I'm not sure that I'm doing the paths correctly--if they should include the file name or not. I'm not sure that the "To App Data Dir" is the correct option. I'm also pretty new to labview so I'm not sure the sequence of operations all of the time, but I was wondering if it mattered. I have an asynchronous custom device type, and I have a subVI being called outside of the loop that uses the .dll. Do I need to ensure that the NI Veristand - Add Custom Device Dependencies gets called before the subVI with a sequence structure or something?

Any more clarification would be greatly appreciated. My initial attempts to follow your instructions for adding it to the deoployment have netted the same results I was getting.

Thanks,

Kevin Key

[kevin.key]

Hey Jarrod or anyone else, do you have any advice to offer to help me?

Thanks,

Kevin Key

[DiscoBall]

Hi Kevin,

I am sorry I have not had a chance to pitch in yet....I will have a more full post here in a couple of minutes.

[DiscoBall]

Hi Kevin,

Let me reply piece-by-piece. Once you have the DLL in the .lvlib file for the custom device's .lvlib you should not need to add it to the Always Included section of the Build Properties. If you look inside the build .llb file that is placed by default in the VeriStand Custom Device folder you should find the DLL inside there.

Even more so, if you use the Call Library Function node to call the DLL when you build a source distribution (the Engine under Build Specifications) the DLL will be copied to the build folders data directory. LabVIEW has gone and check the VI for any dependencies and have added them automatically. However, you have run into the downside is that the VI may refer to the incorrect path on the RT target.

Add the DLL to be explicitly included by adding it to the Always Included will not break anything and is actually helpful in that you are ensure that the DLL does make it into the built files every time. All this is to say that is really preference on how you manage the DLL, so long as it gets to the RT target in the correct location….which leads to the NI Veristand - Add Custom Device Dependencies.vi.

In LabVIEW the sequence of events does matter. I would use the NI Veristand - Add Custom Device Dependencies.vi near the beginning of the RT Driver VI since it is an initialization task and only needs to be called once. You seem to have the basics done correctly in that if you use the To App Data Dir then the DLL should be found in the data directory. The To App Data directory is the directory from which the VI is running from (in this case the Custom Devices folder libraries) and To Base is defined in the NI VeriStand Workspace Settings tab name Paths . Absolute is explicit and requires the full path.

[kevin.key]

Hey,

Thanks for the reply Josh. I am still uncertain, and maybe it'd clear things up if you could give me a concrete example. When I build my project the .dlls are not included in the .llb, and the data directory doesn't go into my National Instruments\VeriStand\Custom Devices\ folder. It goes into a builds folder which is created next to my project folder by the custom device, but what do I do with that builds folder--do I have to do anything?

I included a test custom device with the subVI's and .dll's I need to control the chroma power supply so that maybe you could show me how to get these dependencies linked correctly.

The subVI's are:

Everything in chr52912 folder

End.vi

Initialize.vi

Measure.vi

SetVoltage.vi

The dll's:

chr52912.dll

chr52912_wrapper.dll

cvi_lvrt.dll

I'm not sure if chr52912_wrapper.dll is actually being called. I'm pretty sure that the subvi's are using chr52912.dll, and cvi_lvrt.dll I think is being called because the RT was giving an error message that it was missing at first when I was just trying to get a real-time application to run.

Also, you might see an IP in the rt driver vi, I eventually want to use the NI VeriStand - Get Engine State vi, but does that need to be called in the configuration to pass the value in to the rt driver vi?

Thanks for your help,

Kevin Key

[kevin.key]

Ok, so I've figured out how to use the Add Custom Device Dependencies vi.

Instead of calling it in the RT Driver VI, I added it to the Main Page, and verified that the files are now being downloaded to the RT when I deploy the system definition to c:\ni-rt\system. The only trouble is that the custom device still returns that the VI is not executable so the error must be with the actual calls being made to the .dll and how they're intending to link to it. I'm not sure how to fix this so any help would be appreciated.

Thanks,

Kevin Key

[DiscoBall]

Hi Kevin,

My mistake about the placement of the dependencies VI. You may need to check the DLL's dependencies to ensure that it can run on a LabVIEW Real-Time target, see KnowledgeBase 3BMI76L1 How Can I Verify that My DLL is Executable in LabVIEW Real-Time for more detail. I ran the utility and I have attached the log....the chr52912.dll contains many references to Window's system32 DLLs, most of which will not run at all on a LabVIEW Real-Time target. Unfortunately it appears that the DLL will need to redone to make it LabVIEW Real-Time compatible.

[kevin.key]

Those function calls look maybe like calls contained in cvi_lvrt.dll, maybe. I have ran the dll checker on chr52912.dll before (which is the important dll specific to Chroma, I acutally obtained cvi_lvrt.dll from the LIN custom device). The dll checker told me that there were some stubbed functions, but I have successfully used the .dll in a Real-Time Project that I have deployed and ran successfully on the RT and I have compiled it into a .rtexe file and ran it as the startup program on the RT and that ran successfully. So shouldn't those facts prove that the .dll works correctly on the RT?

Thanks,

Kevin Key