UE9 IP Communication Error with Labview

That is strange. I don't have much to go on, but here are a few tests the may give us some sort of clue:

Try using DHCP.

Try a different network with a static IP.

Try a different netowrk with DHCP enabled.

I'm having this issue too.  

I'll get a 6002 error (1002 if not using labview) 

This will either follow or precede a 7008 Error (1008)

Only way to fix it is a hard reset of the UE9.  This typically can be reproduced reliably if the UE9 is unpluged from the network and plugged back in.  However, it also seems to occur randomly without user interaction.

This typically can be reproduced reliably if the UE9 is unpluged from the network and plugged back in.

That seems a good place to focus on as I do not see that same behavior.  I just did a simple test at my desk.  I set up my UE9 with a valid static IP then ran LJLogUD.  It starts collecting data, and then I can disconnect/reconnect while running and it always comes back after a few seconds.  Try doing the same with LJLogUD.

UD 3.50
UE9 Comm 1.550
UE9 Control 2.260

Note that my UE9 Comm firmware is out of date, but I can't update at the moment.  Will update later and test with 1.58.

I've been getting the same behavior for over a year now.  We usually have to reset the Labjack and the problem goes away.  Things that produce the 6002, 7008 combo are:
 

• allowing the systems to idle for awhile
• switching to a different terminal to access the labjack
• unplugging the usb cord and plugging it back in for the same machine

So if you use the testing method described in post #4 (static IP and LJLogUD) can you cause a problem?

We followed the steps in #4, it reconnected without an issue, this did reproduce our problem.

So what did you do to cause a problem with LJLogUD, and what problem did you see?  We will try the same here.

We haven't had a problem with LJLogUD, so that question is not applicable.

We don't have a consistent way of reproducing the error, it just occurs sometimes.  It is really common under the conditions listed in #5.

This is the data that we always get with the 6002 error:

C:\...PATH...\Raw OutInx64.vi  NumBytes 24  0

What type of commands or functions can we send to the UE9 to probe it when it's in this state that might help to figure out what is wrong?

If you can't cause the problem with LJLogUD, then it suggests that your network configuration is good, and the UE9 itself is good, and the focus should be on what is wrong or unique about your program.  Are you using stream mode in your program?  If so you should try to cause the problem with LJStreamUD while it is streaming with the same configuration you normally use.

It is important to catch the very first error you get and look at that.  If you get an error and then go ahead and make another call any error from that subsequent call is confusing do to the previous error condition.

The description of errorcode 2 (6002 in LabVIEW) is here:

https://labjack.com/support/datasheets/ue9/high-level-driver/errorcodes

LJE_INVALID_CHANNEL_NUMBER

"Channel that does not exist (e.g. DAC2), or data from stream is requested on a channel that is not in the scan list."

I've seen mention of raw outin.  Why are you using raw outin anyway?  Are you doing something not supported by the UD library?

What type of commands or functions can we send to the UE9 to probe it when it's in this state that might help to figure out what is wrong?

It sounds like you can't communicate after you get the error, so does not seem like any functions will work.

You said that to start talking to the UE9 again you have to power-cycle it.  Confirm that instead if you just close all software and then open something simple like LJControlPanel or LJLogUD, they can't talk to the UE9 until it is power-cycled.

Have you considered enabling the watchdog at the beginning of your program (and disabling it at the end)?  You can have it reset the UE9 if it stops getting communication, which might do the same as a power-cycle and let your talk to the device again.  Not fixing the underlying problem, but at least might let things continue automatically.

https://labjack.com/support/datasheets/ue9/high-level-driver/example-pse...

Note that to pet the watchdog you have to send commands to the UE9.  Outgoing stream data does not pet the watchdog, but if you just have a stream read loop it is easy to add a simple command-response write in that loop (e.g. read FIO0).

Correction from last message:

This time the error occured when switching from the development enviornment to the executable environment (which i have see frequently)

First error 7008 which occurs at the eDO.vi.  The Open Labjack VI and the Raw out/in VI that occur in the code before the eDO.vi during the intialization process.

After the 7008 error occuring in the eDO.vi, the 6002 error occurs in the UDRawControlConfig.vi.  Digging down I can see that the Raw OutInx64 function generates the error.  It appears that the second call of the eGetPtr (or eGet S in the 32bit incarnation of Raw OutIn) is the source.  24 bytes go in, but only 0 or 8 are read.  (see attached)

After the 7008 error

Power cycling it usually works but if we continue to try to reinialize it, eventually the error goes away and it starts working again.  It always takes 3 or more reinitializations  to get it work.  But as the first commentor mentioned, 3 is most common.

The error can happen during streaming, but is not isolated to it.  During development today I havn't done anything other than work on the intialization VIs so I'm certain that the only functions run were related to that.

Raw OutIn is part the config VI and so it is why we call it.

Which version of Labview does Labjack support license?  I'll save the VIs off for an earlier version and send them.

So are you using "LJUD UE9RAW CommConfig.vi" perhaps?  Does it do something you need to do that you can't do through UD calls?

The latest LabVIEW version we have is 7.1.  Since the code is forward compatible, and does not need any special features from newer versions, using an older version provides support to as many people as possible.  We have no need for a newer version, and avoid even having newer versions around lest we accidently save our code base in a new version.

Sounds like you are using USB.  Do you see the same problem if you use Ethernet?  With Ethernet you can get a wireshark traffic capture, whereas it is not so easy to get a USB traffic capture.  That said, it is not easy to sift through wireshark traffic, so ideally we find the simplest program possible that causes the problem.

First error 7008 which occurs at the eDO.vi.  The Open Labjack VI and the Raw out/in VI that occur in the code before the eDO.vi during the intialization process.

If the 7008 error is always the first error you get, that is probably what to focus on.  Ignore other errorcodes unless you get them first.

How about making a simplified program that simply calls Open and then in an untimed (run-as-fast-as-possible) loop call raw out/in and eDO.  Then connect/disconnect while this is running and see if you can cause the problem.

Created simple program, and let it run more than 1000 iterations without an issue.

Took your advice to try and excise the Ue9 issue and was able to get a 7008 followed by 6002 error immediatly from disconnecting the etheret connect to the ue9.  (the ue9 uses ethernet, we use usb for visa calls from labview, but there shouldn't be any usb traffic to the labjack.)  The 7008 error occured after the eDO, the 6002 error occured after the UDrawControl Config (RAW out/in).  The LJUD openS never generated an error.

I plugged the ue9's ethernet back in and cycled the program 2 more and the 6002 error cleared.

I repeated the procedure, but the 6002 error will not clear.  In this situation, the number or read items by the raw out in returned -1 which is different from when it was returning 0 or 8.

I can compile this to see if the same problem occurs when switching between development enviornment and runtime environment on the same machine.  I can also check to see if the problem occurs when switching betwen work stations. 

I'm not sure why when it was disconnected a 7007 error didn't occur.  I'm also not sure why the problem persist after it's plugged back in to the network or why the 6002 error occurs at all since we are not making any settings related to streaming.

What did this test tell us?  

Please see attachements, we are unable to save VIs for 7.0, 8.0 is the earliest supported version for reverse compatability.

Created simple program, and let it run more than 1000 iterations without an issue.  Took your advice to try and excise the Ue9 issue and was able to get a 7008 followed by 6002 error immediatly from disconnecting the etheret connect to the ue9.

Just to be clear, the simple program ran fine with the Ethernet cabled connected, but then when you disconnected the Ethernet cable while running the simple program behaved as described?  So the simple program is having a problem similar to what you have in your real program?  If so we will recreate it in 7.1 so we can try it here.

Yes, that was what we experienced (minus my spelling errors) , and it was reproducable.

 

I have 2 LabVIEW 7.1 examples attached.  I tested with firmware 1.59/2.29 and UD 3.50.

With eDO loop, when I disconnect Ethernet I get error 7008, and when I connect Ethernet it starts working again.

With eDO & CTRLCFG loop, when I disconnect the first error is 7008 if eDO is first to execute after the disconnect or 6002 if ControlConfig is the first to execute after the disconnect, and then subsequent loops always return 6002 since ControlConfig is first in the loop.  When I connect Ethernet it starts working again.

So both seem to run fine, in that they come back when the cable is reconnected, but I still have to wonder why you are calling ControlConfig?  The raw functions are not meant to be intermingled with UD functions.  There are various issues with doing this, but one that jumps out at me is that we get a raw errorcode 6002 which means number of bytes read not the amount expected, but if you pass this to the UD error handler it tells you what 6002 means to UD which is different.

Couple of questions:

• If we are disconnecting the connection to the labjack, why isn't it producing a 7007 error?

I'm inferring that once the handle is assigned any instance where the Ue9 isn't available (such as network failure for this experiement) it will produce the 7008 or 6002 error instead?  Is that because the driver is instead serving those errors when it can't find the Ue9.  That may explain the next 2 questions.

• Why would these errors occur when the network is fine and the only thing that is occuring is switching between development environment and runtime environment on the same PC?
• Would these error occur when the computer or ue9 have been idle and the handle has expired?
• With your code slowed down to 1 loop a second it looks like it takes 2 to 3 loops to correct the error after the the network connection has been restablished.
• Why does the 6002 error persist sometimes and othertimes only take 3 calls to dispell?
• Why can't we perform a remote reset when these errors are being received?

Finally, something for a separate forum thread perhaps?  I'm going to need a lengthy explaination to understand what you are meaning when you have repeated to indicate that there is something unusual about how we are communicating with the Ue9?  The software was written about 8 years ago, and I didn't see a difference in the way the functions intended between raw and UD.  What does UD mean?  Why can they not be intermigled, what is the difference and what should we be doing instead?  How would using the raw or intermigling them cause this issue?

-Jwhite @ Cognision

If we are disconnecting the connection to the labjack, why isn't it producing a 7007 error?

I'm pretty sure 1007/7007 LJE_LABJACK_NOT_FOUND is only thrown by the open call when it is first opening the device.  After that functions are getting a valid handle for a device that the driver thinks is open, so when it tries to talk it just sees that the write or read failed.

Why would these errors occur when the network is fine and the only thing that is occurring is switching between development environment and runtime environment on the same PC?

Are you saying that if you run one of the examples I attached as a VI and as an EXE you see different behavior?

Would these error occur when the computer or ue9 have been idle and the handle has expired?

I'm not sure if Windows will close an idle socket after some time, but it is certainly possible.

With your code slowed down to 1 loop a second it looks like it takes 2 to 3 loops to correct the error after the the network connection has been restablished.

I notice that from when I plug the Ethernet cable in it takes 2-3 seconds for the connection to start working again.  I suspect this is time for the TCP stack to fire up on the UE9 and on Windows and for Windows to be ready to talk to the device.

 Why does the 6002 error persist sometimes and othertimes only take 3 calls to dispell?

I'm not seeing this.  For me the connection recovers every time I reconnect the Ethernet cable.  Are you seeing different?  With the simple eDO example too?

I have seen once or twice where I reconnect and communication starts going again, but then some seconds later I get a brief error even though the Ethernet cable is connected.  Of course it is possible for Ethernet to have an error now and then for no obvious reason, but this one seems suspect of the raw function not handling something as well as the UD.  I have never seen this with the simple eDO example.

Why can't we perform a remote reset when these errors are being received?

You can't send a command to the UE9 to tell it to reset if you can't talk to it.  Once communication is regained, you could send a command to reset if you wanted.

What does UD mean?  Why can they not be intermingled, what is the difference ...

UD is the high-level library for Windows:

https://labjack.com/support/datasheets/ue9/high-level-driver

The raw functions are sending raw low-level packets:

https://labjack.com/support/datasheets/ue9/low-level-function-reference

They are 2 totally different interfaces and are not designed to be mingled.  It is possible to mingle them, but not the design of either interface and thus not easy.

and what should we be doing instead?

I recommend you just use UD if possible.  Let me know what you are doing with the raw VIs and we can see if those same things can be done through UD instead.

How would using the raw or intermingling them cause this issue?

The unknowns are the questionable issue, but here are a few more specific thoughts:

1.  One example is that the raw functions have their own errorcodes which overlap with UD errorcodes.  There has been confusion in this thread because we were interpreting 6002 as a UD error when in fact it was a raw error with totally different meaning.

2.  The UD functions are designed to work with each other and work as a system.  When you call UD functions some things are happening in the driver layer and some things in the hardware layer.  When you call raw functions they have equal access to the hardware layer but have no knowledge of the state of the UD driver layer.

3.  The raw functions are very raw with trivial error catching and handling.  They are designed to be a thin pass-through for the low-level interface.  The UD is designed to be more user-friendly.