I'm writing some c# code to continuously read out the Labjack over wifi. I'm querying for samples with the built-in function eStreamRead. I reuse an array double[] aData as the output of eStreamRead. My code works for a while but then it seems like AIN0 -> AIN10, AIN1 -> AIN11, AIN2 -> AIN12, and AIN3 -> AIN13. Maybe something on the labjack side is failing? Like there is some ring buffer and the labjack loses track of where it is in the ring buffer. I was wondering if anybody has had an issue like this.
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
Previously, we've seen issues like that, but I believe they've been fixed in current versions of firmware and software. Please make sure you're running the latest software:
https://labjack.com/support/software/installers/ljm
Also, please update to the latest firmware using Kipling.
If it continues to happen:
What is your ScanList? What ScanRate are you using? Are there any errors output by eStreamRead? What is the LJM and device backlogs output by eStreamRead?
Lastly, there's a debug register named STREAM_DEBUG_GET_SELF_INDEX with address 4898 that always gives the index of the channel. (So if you add it as the fourth channel, it will always return the index 3—aData would look like [AIN0, AIN1, AIN2, 3, AIN0, AIN1, AIN2, 3, ...].) Please try adding that to your scan list. Then add a check to your loop to that makes sure every scan has every e.g. fourth value is 3.
Edit: Typo fix
I updated everything and got the same result. It is hard to tell if I'm making a difference because it happens after a day or so of running usually. The scan rate is currently 100 Hz. I'm getting no errors. It looks like I have an error in the scan list ScanListNames has AIN0, AIN1, AIN2 etc., but ScanList comes out 0, 2, 4, etc. I'm not sure if that would cause this problem. I'll try and output some of the things you asked for, so that I can tell you about it the next time things crash.
To make sure you're using the same version as us, please upgrade to the latest beta versions for both the software and the firmware.
That ScanList looks correct—AIN1 has address 2, AIN2 has address 4, etc.
I added the STREAM_DEBUG_GET_SELF_INDEX as one of the channels and the issue hasn't returned. It ran through the weekend. Is there any reason why including that debug register would change the behavior?
We haven't seen the issue you're seeing for quite some time. Please let us know if you see the issue again with beta LJM and beta firmware.
Based on your other thread, I'd like to replicate the issue you're seeing:
The scanlist is AIN0 through AIN13. I'm still using the same ScanRate. There don't appear to be any errors when this happens. The order changes for many calls of eStreamRead (~10000 calls). It still shifts by 4 channels each time; the original order is 0,1,2,...,13 and it goes to 4, 5,...,13, 0, 1, 2, 3 and then 8, 9,...,13,0,1,...,7. I'm reading out all the channels currently, but they aren't all connected to sensors, so I can connect one to ground and try the STREAM_DEBUG_GET_SELF_INDEX test again.
In the meantime, I should mention that we occasionally get customer reports of stream data scrambling or channel swapping, but it almost always turns out to be something in customer code. We had one instance in 2018 where a perfect storm combination of computer/software/configuration/time/etc. could expose a bug in our 3rd party TCP stack and result in channel swap, but that was fixed at that time. Current firmware does not have that issue.
I don't have easy access to connect one of the channels to ground, but there is some interesting behavior when I replace AIN13 with STREAM_DEBUG_GET_SELF_INDEX. I get a bizarre value around 33459 that shifts to around 27000 when the other channels shift. It seems like there is also some noise on top of these values like it is an open channel plus some large number.
I'm not sure what 33459 means here. Are you saying that it takes 33459 scans or 33459 eStreamRead calls before you see the issue? How are you getting a value around 27000? AIN0-12 should return basically less than 10 and STREAM_DEBUG_GET_SELF_INDEX should return 13 in this case.
What happens if you 1) zero aData immediately before calling eStreamRead and 2) count the number of 13s in every aData immediately after eStreamRead? See the following pseudocode:
while (streaming) {
for (sample = 0; sample < ScansPerRead * NumAddresses; sample++) {
aData[sample] = 0
}
eStreamRead(handle, aData, ...)
// Make sure you check for errors from eStreamRead
numberOfThirteens = 0
for (sample = 0; sample < ScansPerRead * NumAddresses; sample++) {
if (aData[sample] == 13) {
numberOfThirteens++
}
}
if (numberOfThirteens != ScansPerRead) {
// Since 13 is out of range of the AINs, this should never execute:
print "Unexpected numberOfThirteens: " + numberOfThirteens + ". Should have been " + ScansPerRead
}
...
}
Yeah, the return value should be 13, but I'm getting a double closer to 33459. Maybe that is just trouble in conversion from an int to a double? The change to 27000 must indicate that the value STREAM_DEBUG_GET_SELF_INDEX is changing. Zeroing aData doesn't seem to change anything.
So, I changed the firmware from 1.0255 to 1.027 beta firmware and now the channels make sense.
Is it working without issue now?
Yeah, it seems like with this firmware none of the issues I was having before have occurred again. I'll let you know if something comes else happens.
Now I'm getting the error LJME_NO_RESPONSE_BYTES_RECEIVED after a similar amount of time as this issue. Losing connection seems like a reasonable thing to happen, but it's suspicious that this is happening in the same timeframe as the other issues I've seen. It makes me think that I'm not actually losing connection.
Do you get the same issue if you use a direct Ethernet connection?
https://labjack.com/support/app-notes/networking/direct-connection-ethernet-app-note
I hooked up another labjack with ethernet and ran the same code only changing LJM.OpenS("ANY", "WIFI", "ANY", ref handle) to LJM.OpenS("ANY", "ETHERNET", "ANY", ref handle). It ran for a couple days without any issues. It seems to be a wifi specific problem.
For getting WiFi to work better:
What does WIFI_RSSI report for the signal strength? What does it report before a LJME_NO_RESPONSE_BYTES_RECEIVED error? You can set up a computer with a USB connection to read the WIFI_RSSI continuosly, even if the WiFi connection fails.
If you continuously ping the WIFI connection, does ping continue to work during a LJME_NO_RESPONSE_BYTES_RECEIVED error?
Can you collect a Wireshark network capture? If so, you can email it to us ([email protected]) and we can evaluate it to see what the lowlevel problem is. If you do, please use a capture filter or similar to prevent us from seeing any sensitive information.
There are some WiFi tips here:
http://labjack.com/support/app-notes/wifi-and-ethernet-t7-t4-t7-pro#wifi...
The easiest thing for me to try was running ping in powershell and outputing that to a file. It seemed to timeout relatively often. It timed out twice in a row once, so that might have corresponded to the LJME error. Otherwise nothing really stuck out as unusual.
That does sound like a connection issue. The WiFi tips link in my last post has some methods for improving the connection quality. Do they work for you?