I have labview programs running on two different computers, it's two halves of a
system and they need to communicate with each other.  Let's call them Alice and
Bob.  The communications are nothing fancy, it's mostly just to ensure that Bob
is ready before Alice executes certain actions.

Specifically, Alice sends a series of laser pulses to Bob to trigger a port on
Bob's NI-6534 (NI digital I/O card) to latch data.  There is a possibility that
one or more of these laser signals will not ever be received by Bob, and the
result would be that the port's buffer doesn't fill completely and the program
hangs until the port read times out, and an error is generated.  I need to have
a way for Alice to determine if the port has not filled, and if so Alice will
send more laser pulses until it has filled.

I've decided the best way to do this is to use a TCP connection.  Once Alice has
finished sending the pulses, I will put a TCP read with a short timeout.  On
Bob's end, after the buffer read has completed, there will be a TCP write.  If
the TCP write does not execute, because the buffer has not filled and the buffer
read vi is waiting, Alice's TCP read will timeout and return an error.  When
this occurs Alice will send more laser pulses, hopefully triggering the buffer
enough times to fill it.  When the buffer is filled Bob's TCP write will occur,
and Alice's TCP read will not return an error, and program execution will
continue as normal.  I plan to ignore the actual error and simply use the
"status" boolean from the error out cluster of Alice's TCP read to determine
which action to take.  My questions are: is there a problem with this plan, i.e.
purposely triggering (or not triggering) an error in order to control program
flow in this way?  And, can anyone think of a better way for Alice to determine
whether or not Bob's buffer read has hanged?  Can anyone think of a better
solution to this problem?

I'm using Labview 7.0 Pro on Alice, and Labview 7.0 Standard on Bob.  Thanks to
anyone who can provide any feedback at all, I'm sure it will be useful.

Alex

Reply via email to