What can cause a UDP Connection ID to Stop Working?

[StoneTrees]

I've run out of ideas so I'm looking for a little guidance on isolating a UDP connection ID issue.

When upgrading some software from a prior developer which involves a UDP connection I ran into an interesting conundrum.  Previously, opening a UDP connection, reading the UDP packets, and closing the connection were all in seperate subVIs and linked together at various points in the main VI.  As part of my improvements and updates, I combined these into a single VI with the connection ID stored in a shift register.  Now for a long time, this setup worked, and then suddenly...it didn't.

I can't attach the code since it includes some proprietary details, but it's pretty simple to understand.  It works in three major functions:

1. Initialize (open UDP connection, write startup commands, store connection ID in shift register)
2. Read (read UDP data packet)
3. Shutdown (write UDP shutdown command and close UDP connection)

So step 1 works fine, but when I get to the Read step, I get error 1 (bad input) out of the UDP Read function.  I've spent many hours verifiying inputs and insuring that this code behaves in the same manner as the old code and the new code did work previously.  The only reasoning I can come up with for this error is that the connection ID is suddenly no longer valid or was never valid in the first place.

Can anyone suggest a reason why the connection ID would suddenly go bad or that the open UDP connection function would generate an invalid connection id without creating an error message?

Thanks in advance!

Andrew

LabVIEW 8.6 Pro

[Mark_Yedinak]

First, do you check for erros on the open? If so, did the open occur error free? It would also help if you could post a paired down version of your VI with just the basic construct and UDP stuff that you are doing. It is hard to debug stuff without seeing the code.

[StoneTrees]

I've attached a stripped down version of the subVI which handles the UDP connection.

In the Init and Disconnect cases, I've had to remove the startup and shutdown commands as that's protected info, but they are just fixed U8 arrays.  The subVI does not have any incoming errors when executed by itself or as part of the main VI nor does the Init case generate any errors.  Also, the UDP Open and UDP Write functions process a nonzero Connection ID.

Let's see, what else?  The Init and Disconnect cases operates just once at the beginning and end, as you might expect.  While the Read case operating at 1x/sec during normal operation.

Let me know if there's any more insight I can provide.

[tst]

I didn't look at your code, but one common reason for something like this is that if the hierarchy a reference was created in goes idle or out of memory, the reference is automatically destroyed.

In this context, a hierarchy means the place where the reference was created, going up all the way to the top-level VI. When the TLV goes idle, that's when the ref is destroyed. If you have dynamic VI calls in your code or VIs which are called and then stop, that would be a likely source.

The solution for something like this is usually either to make sure the reference is created in a hierarchy which will stay in memory or to add automatic error handling to the subVI, so that if the reference has certain errors, you automatically close it and obtain a new one.

[Mark_Yedinak]

The default value of your Action control is Disconnect. Are you sure you didn't call it somewhere without the action wired? I would recommend making that connection required to ensure you always wire something to it.

[StoneTrees]

Thanks for the feeback tst, but I'm confident that's not happening.  The Connection ID is created in the subVI and stays there in the unitialized shift register.  The only thing the top level VI does is tell the subVI to initiate (which replaces the connection ID in the shift register), read UDP data, or disconnect.

[nathand]

Not sure this will help fix the problem, but a couple of minor points:

1) Don't store the connection ID into the shift register after closing the UDP port.  Store an empty refnum instead (for example, set the "Use Default if Unwired" option on the tunnel out of the case structure).  Consider temporarily putting a dialog box in the Disconnect case so you can verify that it only executes once at the end of the program.

2) Two style points: don't use that connector pattern, stick with the 12-terminal one (4 on the left and right edge, 4 in the middle).  Put front panel terminals (the Function input) on the top-level of the block diagram (outside the while loop) - this is slightly more efficient in subVIs.

[Mark_Yedinak]

Not sure what to say. I don't see anything obvious that would cause a problem. Have you tried running the stripped down version? Does it work? One thing I do when I encounter this type of strange behavior is to make sure the wiring is corrct for all the terminals and I don't have two of them on top of each other which can happen if you aren't careful with your wiring.

[StoneTrees]

Yeah, I was worried it wasn't a glorious oversight on my part and that something subtle is occuring.  The stripped down version doesn't work for me either.  Still get that Error 1 out which simply doesn't make sense as this subVI is the only place where connection ID is used.  Thanks for taking the time to look.  Maybe someone will see some deal breaker, nothing I've seen suggested explains this behavior.

Cheers.

[nathand]

Any chance that you have an error on the input when you try to initialize, so that the socket never gets opened?