lvwutil32 & TS4.x with LV8.5 RTE

[Axel_DSR]

Attached is a test sequence in TS4.0 with only an Action step.

It works fine until you select the RTE8.5 Labview adapter.

Thanks, Axel.

[AdnanZ]

Hi Axel,

Thanks for the attachment. After working closely with R&D on this issue, we have come to the decision that it is a TestStand bug. This was reported to R&D (# 116249) for further investigation. There is no workaround right now, so you might have to wait until it's fixed for the next version. I apologize for the inconvenience and thank you for the feedback! Let me know if you have any questions/comments regarding this.

[Matthew_Kelton]

Adnan,

Do you have access to the source code for the lvutil32.dll?  If you search the archives for that specific error message, there are several instances of code making calls to certain LabVIEW components which do not work in the RTE, as the LabVIEW developers have blocked access from programs outside of LabVIEW.  As long as the call is made within the LabVIEW Development System, LabVIEW allows it.  When the RTE is used, then it is blocked (whether that should be the case is up to R&D to decide, but the behavior appears to go back several versions of LabVIEW.

So, it may be possible that the original author of the dll made some call to LabVIEW which is protected, then the source of the problem is there.

the work around is to call the WindowsAPI directly (many of the functions is the lvwinutil32 are fairly straigtforward API calls), or write your own C DLL to perform the task without calling any LabVIEW component.

[Josh_W]

Matthew,

We have found the original author of the LVWUtil32.dll, and are currently investigating why this behavior is occuring.  I will post back on this forum when we have any more information.

[DRock]

All,

After further exploration, we were able to determine the original author of the DLL.  After tracking him down, he explained to us that this DLL was developed and meant for use with an earlier version of LabVIEW and Windows (as Matthew correctly pointed out, it even predates LabVIEW's ability to build DLLs). 

Most of the functionality that the DLL in question exposed has been superseded by functionality built into VI Server.  For the features that the DLL included that is not accessible via VI Server, please interface with the Windows API as Matthew already recommended - between the VI Server and the Windows API, you should be able to achieve the same functionality and avoid the usage of the LVWUtil32 DLL - thereby clearing up everything with your deployment. 

Thanks again for the feedback!

[Speed Racer]

Is there an update to the lvwutil32 to take care of the issue? I just wanted to check before implementing the recommended 'VI Server' and 'Windows API' alternative. This involves some amount of code re-write from my part and I would rather have a fix from the lvwutil32 (if available).

[parthabe]

Maybe since you posted on an old thread, you didnt get any reply. As I was browsing for something related to this, I happened to see this today...

AFAIK from here, there seems to ne no update to the lvwutil32 to take care of the issue, except that it has been recompiled for LV 8.6.