Error 56 TCP READ

[shamo]

Hi all

I am hoping someone would be  able to help me figure this out: I am  trying to implement a simple code that will pass assembly language commands to a pressure transducer, and receive data back from it through a TCP connection.

I utilized a set of SubVI's provided by the transducer manufacturer to build my code. These SubVI's were originally written in LabVIEW 5.0. Currently I am using LabVIEW 7.1.

My code seems to work intermittently, i.e. it works for a little while and then stops working after that, giving an error code of 56. I tried to get to the bottom of this, and it seems that at the core of It one of the SubVI's used, a TCP READ times out, and causes everything to crash. 

To make things more confusing, the manufacturer's SubVI's come with a demo program that uses a bunch of them to read pressures from the transducer. This demo code seems to always work fine (using the same SubVI's) even when my own code crashes. Sometimes both my code and the demo will work fine too.

I am suspecting a problem to do with the version of the software being used. I say that because I noticed that when my code was working fine, and reading data, that by opening another VI which calls upon the same SubVI's, and closing it (pressing yes to "save changes to VI and called SubVI's") I immediately start getting error number 56.

I would appreciate any comments from anyone who wants to take a shot at this 🙂

Thanks

shamo 

[CoastalMaineBird]

I would never use LabVIEW, if I did not have to 

Not the best way to open a conversation, if you ask me.

I'm not sure what an "assembly-language command" is exactly. Didn't know you could send programming language things to a transducer.

Anyway, Error 56 is TCP timeout.  The functions TCP OPEN CONNECTION, TCP WRITE, and TCP READ all offer a TIMEOUT value: a number of mSec to wait before giving up.  By default that's 25000, but you can set your own value at any point.

If the manufacturer's master code works and yours doesn't, I would say the problem is in your code.  Look for a TIMEOUT value that's wired to the wrong place, wired to a global that's being changed unexpectedly, or some setting that's just not right.

Look where the mfgr gets a TIMEOUT value from, and find out why yours is different.

[shamo]

Thanks for your tip. I do realize it is a time out error, and indeed I tried to modify it to circumvent the problem, bit it did not work. When the code works (I mentioned it works intermittently) it takes less than 500 ms to complete the whole process. Default timeout is 25000 ms!

Some instruments, like controllers used in traversing systems, and transducers do use machine type instructions to carry out certain tasks like start/stop stream, clear channels, re-zero etc.

 And sorry if my signature offended you

Message Edited by shamo on 03-27-2009 08:00 PM

[CoastalMaineBird]

So what's the source of the error?  If you have a standard error dialog, then you should see the source of the error.

Is it at TCP READ?

Is it at TCP WRITE?

Is it at TCP OPEN CONNECTION?

Is it somewhere else? 

[shamo]

Actually it is the TCP READ. One the SubVI's tries to read the response from the transducer after sending a "power clear up" command. And to answer your earlier suggestion, the way my code calls these SubVI's is exactly the same as the manufacturer's master code. Here I mean all the same default inputs (like timeout, number of bytes to read etc.).

[CoastalMaineBird]

Perhaps the device requires a delay after a POWER CLEAR UP.

Perhaps the connection needs to be established again (probably not).

Perhaps it won't listen to any further commands for some period after that "special" command.

Wild guesses, all.