TCP read/write at different rates

[CoastalMaineBird]

Ravens Fan's idea is the one I use, except that I have it in a separate VI and I also trap 64 and 66 errors to catch disconnects and handle them separately.

Anything that's not 56,64, or 66 is left alone: those three go out to three separate boolean indicators, but  the error cluster is set to NO ERROR.

[Peñata]

Hi htmech,

I just wanted to add on to Ravens Fan and CoastalMaineBird's posts. If you need to trap and react to multiple error codes, this can also be done by unbundling the error cluster and wiring the "code" element directly to the case selector of a case structure. Then you can have a case for each code you need to trap and can set up your code to react accordingly. It would look something like this:

The "0, Default" case would function like the False case of the suggestion Ravens Fan proposed, where you would just pass the data thru. I hope this is helpful!

Thank you for choosing National Instruments.

Aaron Pena

National Instruments

Applications Engineer

http://www.ni.com/support

[htmech]

Thanks for quick responses. This is what I ended up implementing, probably more complicated than it needs to be.

I used a Feedback Node (pink block) to store the value from a previous "valid" TCP read, and when it throws a code 56, the Case Structure will send out the last stored value. The comparison checks are just to make sure the error out status is also TRUE when it throws an error code.

Just curious, my "unbundle" and "clear errors" VI icons look different than the ones from Ravens Fan and Dr. Horrible. I'm using LabVIEW 2009. What version is yours?

[CoastalMaineBird]

This is way more complicated than necessary. 

Testing a boolean value with an IS EQUAL(TRUE) is superfluous; it always yields the original boolean value.

I believe you can safely assume that the error CODE will not be 56 unless the error STATUS is TRUE, so the second test is also unnecessary.

The CLEAR ERROR function is pointless if you don't wire something to it's input, just use a default error cluster in the 56 case.

You're testing for code = 56 in two places, when just one test would suffice.  If the case is 56, pass TRUE out to the NO DATA indicator, and FALSE in the other case.

Do you really want to report the same value again, if you don't get a new one?  If so, then document that fact on the diagram. 

If you use the NO DATA signal outside this VI, then it seems like you don't need to remember the previous value here.  I would just pass out an empty string (which you already get from TCP READ) in case of timeout.

Message Edited by CoastalMaineBird on 11-05-2009 08:01 PM

[htmech]

Thanks, Steve, for your inputs and for pointing out there is no input to the Clear Error VI; surprised LabVIEW didn't complain. Here is the cleaned up version:

I cannot use the empty string from TCP Read because that string gets converted to an integer for a DAQmx Digital Write downstream. Each time there is a TCP Read timeout, the integer value is 0 and I can't have the digital output signal toggle between non-zero values and a zero. The easiest solution is to have it hold the last value until a new valid TCP Read comes in.

[CoastalMaineBird]

I cannot use the empty string from TCP Read because that string gets converted to an integer for a DAQmx Digital Write downstream.

Then what is the point of the NO DATA output?

I would consider using that signal to stop the digital WRITE downstream.

But, you know more about what you're doing than I.

Personally, I use this sort of paradigm all the time: I check for TCP coming in, with ZERO timeout.  If it timed out (meaning I don't have the whole message received yet), that is NOT an error.  I do nothing. 

[htmech]

The No Data Indicator is just to tell me the other end of the TCP connection (source of incoming data) is sending too slow, and I can either speed up the sender or slow down this TCP Read.

This design is part of a multiple rate TCP read/write timed loop supplying data to DAQmx analog and digital reads/writes. This project ideally should be multi-threaded, which can be easily implemented in C running on VxWorks, but we have to use this NI-PXI RT system with only 1 processor. It gets more complicated.

I have no prior LabVIEW experience until a week ago. So far it's been fun, but sometimes it takes more effort to implement a simple function in LabVIEW than it takes to do it in text code.

Thanks to all for your help.

[CoastalMaineBird]

This project ideally should be multi-threaded, which can be easily implemented in C running on VxWorks, but we have to use this NI-PXI RT system with only 1 processor. It gets more complicated.

I've never heard a claim that multi-threading is easier to implement in C than in LabVIEW.

Place two while loops on your diagram - you have two independent loops.

One can do TCP communication, the other can do DAQ, or UI stuff, or whatever.

Place 8 loops on the diagram - you have 8 independent loops.

Put each loop into a subVI and they can be operated on different execution systems.