10-02-2019 05:31 AM
Hi All,
I've been trying to get the LabVIEW scripts that are provided by Newport for their Model 6100 Laser Diode Driver to function with the piece of equipment - their software and LabVIEW samples can be found at the below link.
https://www.newport.com/p/6100
I can get the Newport software to work with the instrument connected via usb (as seen in the Test USB screenshot below), however the LabVIEW does not work due to an Error 1097 associated with the usbdll.dll file.
As this is a fairly common error, I've done the usual things like updating the drivers, checking for correct inputs and changed the calling convention to C (see attached images).
I'm using a 64bit PC, LabVIEW 11 (32bit) and the usb drivers are designed to run 32bit on a 64bit PC.
I'm not sure how to solve this problem, and would very much appreciate any help or guidance.
Thanks,
K
10-02-2019 06:06 AM
Changing the Calling Convention for a driver provided by the instrument manufacturer is almost 100% not the right thing to do. If anyone knows how that DLL was compiled it is the manufacturer!
Since the driver was provided by Newport it would be their responsibility to make this work. Have you contacted their tech support? They may try to avoid the issue (they don't seem to like to work with LabVIEW or NI generally) but it is their responsibility and avoiding LabVIEW in their industry is pretty much a no-go!
As a quick suggestion: Change the calling convention back to what it used to be. Chances that this was the right setting are probably higher than your change based on random suggestions you picked up from other posts in these forums. That calling convention change can be an issue if a user created his own DLL and basically has no idea what he was doing. Otherwise it's not a good idea to change it on a hunch.
Where the newp_usb_send_ascii function is called try to increment the value you get from the String Length node by 1 before passing it to the Call Library Node. This should be save to do since LabVIEW actually passes a pointer to a string to the DLL that has an extra 0 character appended, since that parameter is configured as C String pointer.
10-02-2019 07:04 AM
Thanks for the reply Rolf.
I contacted Newport and am currently waiting for a response. I've also changed the Calling Convention back to its original setting as you suggested.
I'm unsure as to what you mean by 'Where the newp_usb_send_ascii function is called try to increment the value you get from the String Length node by 1 before passing it to the Call Library Node.' and also what this is meant to achieve. Could you possibly explain in more detail?
Thanks,
K
10-03-2019 05:08 AM
Basically what I meant is to add a +1 node in the wire where the red circle is.
The idea of that is to give the DLL function the length of the string including the terminating NULL character. Depending on how the software is programmed underneath this might fix an issue or it might not. In any case it is worth trying.
10-03-2019 07:13 AM
@rolfk wrote:
Basically what I meant is to add a +1 node in the wire where the red circle is.
The idea of that is to give the DLL function the length of the string including the terminating NULL character. Depending on how the software is programmed underneath this might fix an issue or it might not. In any case it is worth trying.
I tried this and unfortunately it hasn't solved the problem - I get the exact same error. Still haven't heard anything back from Newport either.
Let me know if anything else comes to mind that may help solve this problem.
Thanks,
K
12-16-2019 06:57 PM
Hello, has this problem been sloved? I meet this problem too.
12-17-2019 06:27 AM
Well, can you give us more details?
Which of the two Call Library Nodes actually causes the error? Looking at the actual driver VIs now I suspect it is at the second on the right side of the diagram.
Does it happen with all commands you try to send to the instrument or only with certain commands? Which commands do you try to send?
12-17-2019 11:13 AM
Have you tried downloading their full software package and installing it?
If you can confirm that you can communicate with a device using the manufacturer's standalone software, that goes a long way towards proving that it's a LabVIEW-specific issue and not an issue with the device, your OS, your drivers, the cable connecting the device, etc etc...