We have a workaround for this, but just to let you know...
We're using a T7-Pro with the Mux extension, latest firmware (1.0287), LJM 1.2000. When we try to do a bulk read using eReadNames or eReadAddresses we get occasional bad results on the values for the MUX channels (AIN48 and up) if the names/addresses in the read array are out of order. This is verified by doing a eReadAddresses of the unsorted channels list and getting the wrong results, followed by doing a eReadAddresses of the sorted channels and getting the right results, and using a multimeter to verify which were the correct readings.
Specifically, we were reading AIN48, 49, 50, 51, 52, 98, 99, 101, 103, 113, 116, 122, 2, 3, 114, 115, 117, 118, 124, 125, 126, 127, 0, 1 in that order just because that's the order that various modules registered to read them.
Sorting the list first fixes it. I'm not sure if this a bug in how adjacent addresses are batched, or by MUX bank switching timing, or what's up. I don't see anything in the LJM docs or the Mux80 docs than say in-order address lists are required, though now I know it's a good idea anyhow because it will be slightly faster due to the batching.
.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")
As a bit more info on 'bad results', 116 would consistently go from 0.917V (the correct value) to 0.997V when it got the wrong answer, which is a considerable difference. On the other hand 122 held steady at 0.92 (the correct value) even when 116 glitched. I wish I had more info like exactly which others were off and their relative values, but once I got it working they are running that machine 24/7 and reluctant to give it up.
I ran a couple tests, but did not see what you are describing.
For my test I used:
I did not see a change in the value reported by AIN116 when the channels were read ordered vs. unordered.
Thanks for the reply - perhaps it's because we're using USB3 hubs to your USB2 here (I should have specified that, sorry) and it's having issues with the multiple packlets? This is not a high speed acquisition system, just once a second, so I wasn't worried the response taking a little longer. In any case, it's working okay here now with the sorting.
Could be that your signals are weakly driven and changing the sampling order is exposing the problem.
First thing to do is try to isolate whether the problem is with your signals or somewhere else.
1. Here is a test that uses signals that are known to be well driven, rather than your signal. Remove your signal from a channel that is having the worst problem, and instead jumper that channel to GND and see if it does the same thing. Further, you can jumper a bunch of channels to VS or GND and see if they read different depending on order.
2. Now tests on your signal using stream mode in LJStreamM to look for settling problems:
http://labjack.com/support/app-notes/SettlingTime#SettlingTests
I am out of town for the next two weeks, but will do this when I get back, thank you.