We have been using the UE9 in our test applications for about 10 years now. We have a lot of experience with it and have not had this type of problem before.
We are updating our production line testing applications and so compiled a new version of our software with bug fixes and updates in LabVIEW 2017. Previous version was compiled in 2016. No changes were made to the LJUD Open S or the other low level function calls for configuring the Ue9.
We are able to run the application in the
- 2017 Development enviornment on a Windows 7 machine
- 2018 development environment on windows 7 machine
- 2016, 2017, 2018 runtime enviorment on windows 7 machine
The production targets are Windows 10 machines that use the runtime application. The older compiled version continues to work without issue but the newer compiled 2017 and 2018 runtime applicaitons will not read back information properly.
We are able to open an instance and retrieve a handle with out error, then utilize a LJUD configuraiton VI but it only returns 0s. Most other funciton calls result in 6005 errors.
I'm providing the code, the application and the installer, the installer is too large and so I'll provide a link.
If the program works on your windows 10 computers at support, then we'll take a different route for troubleshooting.
This particular installer and the application are not production programs for our company. Once we started having issues they were whipped up as a very basic example of the issue to use for troubleshooting.
https://cognision.sharefile.com/d-s9054dbe8a1c44ad9
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
I ran your LabjackDefaultConfig.exe and saw that only the open call was causing communications with the UE9. I didn't see ControlConfig packets.
I don't have a newer version of LabVIEW on hand to look at your VI code, but one potential issue I see looking at your VI names is that you are using "LJUD_eGetS NNX (U8 Array).vi". The eGetS call is not 64-bit safe for arrays, so if you switched from a 32-bit application to a 64-bit application that call is a problem. Pointer addresses are being truncated to 32-bits with the long x1 parameter, which is a problem with 64-bit application using 64-bit pointers. Switch to the 64 and 32-bit safe eGetPtr call, which is provided by "LJUD_eGetPtrS (U8 Array).vi" in our current LabVIEW download:
https://labjack.com/support/software/examples/ud/labview
If you have other code that was using AddRequest, eGet, or ePut with arrays, switch them to using AddRequestPtr and eGetPtr instead. Common functionality using arrays with those functions are low-level command-response (raw output/input), stream mode reads, Async/I2C/SPI serial communications, user memory writes/reads and calibrations constants reads.
Thanks!
I bet this is it!
I am not seeing a Raw OutIN.vi that contains the 64bit supported eGetPtr calls, I can switch them manually but before I spend time doing that wanted to check that I hadn't missed a LabJack 64bit package that had updated all of the vi's for 64bit support.
Do I need to switch they manually or is there a complete package of 64bit ready VIs?
The LabVIEW_LJUD_2017_09_25_0.zip download from my previous link has the latest VIs. It looks like that "Raw OutIn.vi" is still using eGet. Manually replace the "LJUD_eGetS (U8 Array).vi" with "LJUD_eGetPtrS (U8 Array).vi" in "Raw OutIn.vi".
Only was able to find the LJUD_eGetPtrS (u8Array).vi and the LJUD_eGetPtrS (double).vi VIs.
Where would I find the AddRequestPtr, eGetPtr, or ePutPtr VIs.
AddRequestPtr is not in that code when I download it.
For eGetPtr, there are the VIs you found:
LJUD_eGetPtrS (DBL Array).vi
LJUD_eGetPtrS (U8 Array).vi
In LabVIEW the array type needs to be defined when using a Ptr function.
For AddRequestPtr, that function is available in the UD library but I don't see Ptr array VIs for it.
For the ePutPtr, there is no function for it in the UD library. One of the LJUD_eGetPtrS VIs can be used in its place based on the array type needed.
Note with the Ptr version of functions/VIs, they are only compatible when passing an array to the x1 parameter ("void *" pointer). If your are not passing an array, use the existing, non Ptr versions of the VI where a value is passed to the x1 parameter (long value).