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

[PhilipK]

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

Issue

• 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?

 

Setup:

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

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

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

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


Any help would be appreciated!

[Yair]

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.

[PhilipK]

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