Jump to content

Driver Development: TCP/IP Issue, Error Code 1: invalid connection ID?

Recommended Posts

I'm having some issues with a LabVIEW driver I'm writing for a Mensor CPC 6000 pressure controller.


  • I open the TCP Connection using the LV "TCP Open Connection" VI, and can then successfully read various values from the Mensor, such as "id", "gasDensity", etc., using the "TCP Write" and "TCP Read" VIs wired with the connectionID refnum. 
  • I save the connectionID in a shift register and want to use this connectionID to write and read values the next time the VI is executed, however as soon as I perform a "statusUpdate", "TCP Write" returns Error Code 1.

Tests already performed

  • I've confirmed that I'm not accidentally closing the reference in LabVIEW.
  • I've confirmed that the connectionID is saved correctly in the shift register (by casting it to type U32 and comparing outputs and inputs after each execution)
  • If I open a new connection and immediately perform my "statusUpdate" the expected values are returned

possible cause?

is LabVIEW or Windows automatically performing some clean-up in the background leading to an invalid reference, or is something with my hardware setup funky?



Hardware setup: PC running Windows 8 and LV2016, directly connected to Mensor CPC 6000 using a crosswired ethernet cable. 

Mensor IP Config: Address,, Subnet Mask:, Port: 6000

PC IP Config: IP Address,, Subnet Mask:, Default Gateway

The driver is a simple affair (see attached VI snippet for the VI which reads strings from the Mensor)

Any help would be appreciated!


Share this post

Link to post
Share on other sites
1 hour ago, PhilipK said:

is LabVIEW or Windows automatically performing some clean-up in the background leading to an invalid reference...?

Probably. LV's general approach to references is that they are cleaned up when the hierarchy they were created in goes idle or out of scope. The hierarchy is determined by the top level VI, so if you're running a VI to create the connection and that VI stops and you're then running the second VI, the value of the reference is still there, as you can see, but the underlying resource has been cleaned up because the VI has stopped.

Since you didn't show any code showing how you're testing this, I can't know for sure, but I'm guessing that's your issue. Another potential issue would be that your code is still running, but the reference was created in a hierarchy (i.e. a dynamically called VI) which did stop running.

Share this post

Link to post
Share on other sites

Yes that was the issue. I changed my testing VI so it didn't go into idle and now it works as intended.

Thank you very much for your help


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.

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 IpsoFacto
      I've got some weird stuff going on with a cRIO project I'm working on wanted to get some opinions on it. The basic architecture is a set of classes that do some process. That process registers with a server. The internal data of the process is held in a DVR and the server get's access to that DVR. Clients use TCP to ask the server to do something, the server makes a call against the classes DVR and returns a response to the client.
      To simplify the issues I'm seeing I created a class that internally just increments an integer every 500ms. The client asks the server what's the current count, the server asks the Counter class and returns the answer to the client. This works perfectly fine when running the VI in the IDE. When built it connects, will get the JSON message back, but always gets a default value from the DVR call (zero, in this case). As soon as I open a remote debug panel to the cRIO, everything is working. The count is correct, the client calls work, just like normal. As soon as I right-click, close debug, it goes back to zero. Open debug works, close debug, back to zero. I know the DVR isn't getting dropped because the count continues to increment while not in debug, the process is still running happily with no issues.
      Here's a few screenshots of the code;
      Count Class process (get the count, increment, write it back to the DVR) - Counter Class process
      You can see the DVR vi's are actually vim's using a cast. I can't imagine that's the issue.
      Server Side call - Server Side calls
      All this does is get the count from the DVR (same as above) and wraps it in JSON and passes it back to the client as a JSON string.
      I also implemented an Echo class that ignores the process and DVR's, it just takes whatever string you sent form the client to the server and passes it back with a prepended "@echo". This works when running as an executable with the debug turned off so I know the client, server, and the server/class calls are all working as expected.
      Any thoughts here would be welcome, thanks.
      edit: I added the any possible errors coming from the variant cast to the JSON reply. When the debug is open there are no errors, when the debugger is closed it throws error 91, but the in-place element structure reading the DVR does not throw any errors. How can a variant not exist until a debugger is opened and than it magically exists?
      edit: the internal data dictionary is a wrapper around a variant attribute, I wired out the "found?" terminal all the way out to the JSON reply and if the debugger is open the attribute is found, but not if the debugger is closed. Anyone have issues with Variant Attributes in Real-Time?
    • By pysenberg
      Hi all,
      So I'm working on making a certain vi a remote panel. However this vi is quite complex with a lot of property nodes events which makes remote panel connection can be a bit unreliable cross-site because of the amount of data being transferred.
      What i'm trying to do to solve this is use a secondary vi that grabs an image of the first vi's front panel at a given frequency so that any changes are seen with out having to send too much data back and forth between the server and client. Basically all we should see is the change in pixels. When a user clicks on the image on this secondary vi i would like to simulate a click on the first vi at the same co-ordinates which should give me full control. I would use the secondary vi as the remote panel instead. I'm guessing this is how remote desktop would work?
      I have looked into simulating mouse click events using the User32.dll and it works great > http://digital.ni.com/public.nsf/allkb/9BB3211F3469623649257360000E272C
      However my problem is that this vi may not be the top vi or may be transparent at times. So my question is, is there a way of simulating a mouse click on a specific vi even if its not on top or hidden?
      This idea may be too crazy to work and in that case any suggestions are welcome.
      Thanks in advance.
    • By pysenberg
      I am currently developing a scope that displays live data from a test rig. The scope is accessible via remote panels. Tests normally run for many hours at a time, when monitoring the scope after several hours of running I notice that the data on the chart displayed via the remote panel is not in sync with what can be seen on the actual 'server' vi. The delay also seems to be getting bigger as time goes on. I also display the current data points in an indicator; however these seem to be in sync and 'current'.
      The scope is part of a built application and I am using labVIEW 2012 f3 to develop it.
      I know that there is an issue with synchronizing front panel appearances when using remote panels in built applications but I think I have got around that by re-applying panel changes when a new client connects. Also on every execution of the VI, I defer panel updates make all my updates to controls including the chart in question, force draw the chart and then re-enable panel updates.
      I would really appreciate if anyone that has experienced this sort of issue could share a possible solution/work around.
      Thanks in advance.
    • By 20Syl
      Hi everybody,
      I am wondering whether or not it is possible to call the functions of a dynamic library over a LAN connection, without needing to control a VI on the server using the LV remote server (my server is Win7 embedded on an SSD, so not much resources to waste running the RTE). Does the "Shared library file is not on the local machine" checkbox allow that when using the Import Shared Library wizard? Is there any easier solution than implementing a protocol over a TCP connection to access my DLL's functions?
      Thanks in advance,
      Sylvain F.
    • By Mechatroner
      LabSocket enables LabVIEW applications to be easily accessed using a web browser, without the need for browser plug-ins or run-time engine on the client.
      The latest release of LabSocket includes support for Waveform Graphs and Charts, XY Graphs and MultiColumn ListBoxes.  An option to integrate LabSocket with the Moodle CMS is available as well.  A detailed User Guide and downloadable demo of this release are at: http://labsocket.com/userguide_demo.html.  Below is a screenshot of a test VI (left) and its representation in a browser (right).
      LabSocket-RT, a special version of LabSocket for the LabVIEW Real-Time environment (eg. cRIO), is also available: http://labsocket.com/RT.html.  A live demo of LabSocket-RT operating on a cRIO-9025 can be accessed at http://labsocket.com/Demo2.php, until approximately Oct 4.
      Other links of possible interest:
      Documentation on a "Remote Cascade Lab" developed by KTH Royal Institute of Technology in Sweden that uses an earlier version of LabSocket: http://www.energy.kth.se/proj/projects/Remote_labs/RL/RL_website/RCL/RCL.html Screenshots of support for MultiColumn ListBoxes: http://labsocket.com/MCLB.html Presentation to Orange County (CA) LabVIEW User Group Meeting titled "LabSocket System - Plotting Capability and Sample Applications": https://decibel.ni.com/content/docs/DOC-30313

      Any questions or feedback about the system are welcome.
      -John Bergmans

  • Create New...

Important Information

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