UDP Close resulting in Error 1

[mlam13]

Hello,

I'm creating a UDP connection, writing and reading data from that connection, but get Error 1 when I close that connection.  A post similar to this (http://forums.ni.com/t5/LabVIEW/UDP-close-causing-error-1/td-p/355173) suggested using shift registers for the connection ID, which I have done to no avail.  I've attached my VI for reference. Any suggestions?

[crossrulz]

Could you post your actual VI?  I suspect a wiring issue, but it is really hard to tell from a picture.

[mlam13]

No problem.  Attached the vi.  Do want to mention, that I've only recently had this problem. This vi has been working fine for months, and now I'm suddenly encountering this issue.  The vi also starts out working and after like 10-30 mins encounters the error.

[mlam13]

So the problem seems to be alleviated if I add a clear Error 1 after opening the UDP connection, just inside the while loop. This doesn't seem to make to much sense to me. Am I masking the problem or is there soemthing I'm not quite getting?

[WireWeaver]

Hi,

Error 1 usually means an input parameter is invalid. Try probing the inputs to the UDP Close and work your way back through the dataflow to see where you are getting an invalid input from.

[crossrulz]

---

@mlam13 wrote:

So the problem seems to be alleviated if I add a clear Error 1 after opening the UDP connection, just inside the while loop. This doesn't seem to make to much sense to me. Am I masking the problem or is there soemthing I'm not quite getting?

---

Using the Clear Error is just masking the problem.  I recommend running with highlight execution turned on and watch to see when the error actually occurs.  I would also setup your loop to stop if there was an error.

[altenbach]

According to your posts, it is not udp close that generates that error, but one of the functions upstream. I assume that the subVI that you failed to attach clears timeout errors but does not touch any other error. Once any of the UDP functions returns an error, subsequent functions will just returns the previous error and will no longer do anything useful, and since you use a shift register for the error, any non-timeout error will persist until the end of the program.

DOes the program actually work correctly if you constantly clear the error?

You even wire the error-in. Could it be that the error already exists when you call this subVI? Typically, a well written subVI will bypass most of it's code if called with an error condition. Yours doen't.

The exact error message should tell you which function generated the error. Can you quote it here?

What is the value of the IP address global variable? Could it be malformed? Maybe you think it is empty, but it actually contains a linefeed or some other non-printable character. Make sure the control where you enter it is set to "limit to single line", for example.

(BTW, you could simplify your code by using a FOR loop with a conditional terminal.)

[mlam13]

Crossrulz: That's next on my list if there's no other options to try since it takes forever to get into that error condition, and I'll have to sit there and stare at it.

Altenbach: The subvi originally only cleared out the timeout error, but I added in to clear out error 1 while trying to work on this problem. It kinda appears that way, except the error message always pointed at UDP close as the vi that caused the error.

Yes, it appears to work fine now when I constantly clear the error.

I don't believe this to be the case since the initial write/read in the loop would have been unsuccessful, and the error message I received would indicate that this error occured during one of those steps and not at close.

Running a long test, so I can't stop it and revert to get the exact error message, but it basically said "Error 1 at UDP Close.vi.  Input paramter invalid" or something along those lines.  When I get the chance I'll try to get the exact error message.

The IP address is set through user input, but is set to a default value if there is no user input. This value is not changed during the duration the program is ran. If it was malformed, wouldn't the initial UDP open have a problem? If that's the case, that shouldn't be the problem since the program runs fine for a period of time before encoutering the error.

Ah, you are absoultely right.  Looks nicer too. Thanks!

[crossrulz]

Another debug tool that should be useful here is a Custom Probe.  It works just like a normal probe, but with more functionality.  Just righ-click on your error wire and go to the Custom Probe menu.  One of the options should be a Conditional Probe.  You can actually make the VI break where there is an error.  Do these in the right places and you can figure out what errors are being thrown where.

[champ065]

Did you ever figure out that was causing this error 1 out of your close UDP? I'm getting this error, however it's intermittent, and I don't have the input error handler wired up.