Channel readout changes order | LabJack
 

Channel readout changes order

17 posts / 0 new
Last post
eashaw
eashaw's picture
Channel readout changes order

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.

LabJack Support
LabJack Support's picture
Previously, we've seen issues

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

eashaw
eashaw's picture
I updated everything and got

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.

LabJack Support
LabJack Support's picture
To make sure you're using the

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.

eashaw
eashaw's picture
I added the STREAM_DEBUG_GET

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?

LabJack Support
LabJack Support's picture
We haven't seen the issue you

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.

LabJack Support
LabJack Support's picture
Based on your other thread, I

Based on your other thread, I'd like to replicate the issue you're seeing:

  • What is your ScanList? (Is it three channels—AIN0, AIN1, and AIN2?)
  • Are you still using ScanRate = 100?
  • Are there any errors output by eStreamRead? If there are, stream will stop running unless the error returned is LJME_NO_SCANS_RETURNED.
  • When you see the channels change order, does the next call to eStreamRead still have an incorrect order? Every aData[0] should be the first channel of stream.
  • If you add an extra channel and connect it to GND, does that channel show a different value from ~0? This is like the STREAM_DEBUG_GET_SELF_INDEX test above, but uses a real AIN.
eashaw
eashaw's picture
The scanlist is AIN0 through

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.

LabJack Support
LabJack Support's picture
In the meantime, I should

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.

eashaw
eashaw's picture
I don't have easy access to

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.

LabJack Support
LabJack Support's picture
I get a bizarre value around

I get a bizarre value around 33459 that shifts to around 27000 when the other channels shift.

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
}

...
}

 

eashaw
eashaw's picture
Yeah, the return value should

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.

eashaw
eashaw's picture
So, I changed the firmware

So, I changed the firmware from 1.0255 to 1.027 beta firmware and now the channels make sense. 

LabJack Support
LabJack Support's picture
Is it working without issue

Is it working without issue now?

eashaw
eashaw's picture
Yeah, it seems like with this

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.

eashaw
eashaw's picture
Now I'm getting the error

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.

LabJack Support
LabJack Support's picture
Do you get the same issue if

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