Jump to content
boochbrain

VISA errors occuring only in executable (not development)

Recommended Posts

Hi All,

 

This is my first post on LAVA, so here it goes:

 

I am creating an application that involves reading data on two RS-422 serial ports. Everything was going just dandy until it was time to build my application into an executable. I've spent time debugging my issue and have been able to narror down where the source of the error is coming from, but I can't figure out why it's happening or how to fixt it. I created a simple VI that clearly demonstrates the error.

 

The VI  first configures two serial ports using VISA. It then gets the number of bytes at the port and reads from VISA resource in a loop. Finally the resource refs are closed. Before building into an executable (development mode), everything works fine. When I build this single VI into an executable, there are errors anywhere there is an Instr Propert Node. The error code is -1073807246 (which I can't find anywhere).

 

Does anyone know why I'm having this issue? Is this some sort of dependency issue? Maybe I'm not really including some VISA functions in my dependenices?

 

 

Serial Read.vi

Share this post


Link to post
Share on other sites

Here's the error description as stored in LabVIEW (help->Explain Error..):

 

 

Error -1073807246 occurred at an unidentified location
 
Possible reason(s):
 
VISA:  (Hex 0xBFFF0072) The resource is valid, but VISA cannot currently access it.

Where are the errors comming from? I suppose from the 'Open VISA resource'.

Is this running on the same computer as the Development enivronment?

 

You might need to wait a little bit before calling the VISA open function. Try to add a wait of 10 seconds before the open VISA session.

 

Ton

Share this post


Link to post
Share on other sites
Is this running on the same computer as the Development enivronment?

If this is true close LabVIEW entirely to ensure that it isn't holding the resource.  This isn't always necessary but if cleanup is not done properly this can be an issue.

  • Like 1

Share this post


Link to post
Share on other sites

If you are deploying on a different computer, then you need to include the NI-VISA Runtime 5.3 installer when you build the installer.  Might be necessary to include the NI-Serial 3.9.1 too.  These are under the additional installers tab in the installer properties.

Share this post


Link to post
Share on other sites

Thank you all for responding. Ton got it right. I had a different VI that wasn't closing the refs and so my LabView environment was still holding the resources.

 

I want to pose another question - Is the open Visa function necessary when reading from serial ports? I have only been using the VISA configure function in some cases, and it has been working fine.

Edited by boochbrain

Share this post


Link to post
Share on other sites
Thank you all for responding. Ton got it right. I had a different VI that wasn't closing the refs and so my LabView environment was still holding the resources.

 

I want to pose another question - Is the open Visa function necessary when reading from serial ports? I have only been using the VISA configure function in some cases, and it has been working fine.

 

It's not strictly necessary since LabVIEW does an implicit open on a VISA resource when it does find that that resource hasn't been opened yet. LabVIEW stores the internal VISA handle that belongs to a VISA resource with the resource itself in a global list of VISA resources.

 

However suppose you didn't use the VISA Open in your executable: The implicit Open would have failed too, but possibly without a good way to report that error. So I really prefer to always explicitly open VISA resources anyway. Costs nothing when writing the code, but makes it much clearer what is happening and possibly improves error detection.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By RMowatt
      I am experiencing numerous VISA Lock Errors (-1073807345) on resources I haven't explicitly locked.  This is happening on TCPIP connections to keysight N6700 power supplies and keysight N5242 PNA fairly regularly.
      I have simultaneous loops in the application communicating to the different instruments, using a sequencer of sorts to pipe commands one at a time to each of my various loops.
      Has anyone seen the locking error pop before while not actually using the Lock and Unlock VIs?  This issue has gotten worse lately and it has come time to find the root cause.  My only thoughts are that it may have something to do with having NI MAX and Keysight Connection Expert both installed and possibly trying to "ping" these devices.  Every once in a while me sending commands and these "pings" may clash and cause the locking error.
      Error reads as follows:
      "Specified type of lock cannot be obtained, or specified operation cannot be performed, because the resource is locked. VISA error code -1073807345 (0xBFFF000F)"
      We are using LabVIEW 2013
      Thanks in advance!
    • By Lipko
      Hi all!
      I'm new to the forum and I have a strange issue with reading TDMS custom properties with Labview.

      Creating user properties is working fine using TDMS Set Properties.vi, but I can't read them with TDMS Get Properties.vi. I can read the "standard" properties, and also I do see the properties in DiAdem (dataportal and using script) and also in Excel when I use TDM(s) importer. The property names are not listed when calling TDMS Set Properties.vi without the property name and data type terminals connected.   
      There is no simultaneous file reading or writing.
      I solved the problem with loading DiAdem and running a script, but that's very slow and also not all target machines have DiAdem installed (and no licence either, obviously).
      I also tried with property names such as User Properties\Device_ID, User_Properties/Device_ID in whatever combinations (I look for the property "Device_ID") without success.
      Thank you for any hints in advance!
    • By Dawid
      I'm trying to execute LPR.exe command to print some labels on a printer. However as its normal, problems occur. I could not find answer on any topic conneced with "sytem exec". I already tried all described methods (I think so). That's why I'm asking very kindly for any help.
      When trying to execute or call the LPR.exe from System exec VI, I'm receiving error:
      "'C:\Windows\System32\lpr.exe' is not recognized as an internal or external command, operable program or batch file."
      Generally I would like to call function: "lpr -S 192.168.1.5 -P lp C:\test\do_druku.txt" which works from command window without any problem.
       

      print.vi

    • By Benoit
      Hey guys,
      Can you take a look at this?
      The only work around I found is to dynamically open the connection with an external VI to make it fail so the second time it works.
      If anyone has an instrument that communicate trough TCP-IP with VI, please try on your side with LabVIEW 2018 and visa 18.
      https://forums.ni.com/t5/LabVIEW/VISA-error-with-TCP-IP-BK-precision-2190E/m-p/3876316
      Thanks
    • By szewczak
      I wanted to cross post metux's discovery here asap, and have a separate discussion.
      Metux's original post:
      The recent Linux driver package introduces a CRITICAL security vulnerability:
       
      http://www.ni.com/download/ni-linux-device-drivers-2018/7664/en/
       
      It adds additional yum/zypper repos, but explicitly disabling package signing and using unencrypted HTTP transport. That way, it's pretty trivial to completely takeover the affected systems, by injecting malicious packages.
       
       
      DO NOT INSTALL THIS BROKEN SOFTWARE - IT IS DANGEROUS !
       
      CERT and BSI are already notified.
       
       
       
       
       
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.