struct.pack error at low sample rates

[mickp]

Running

import u6

dev = u6.U6()
# Stop any previous stream to prevent Error 48. 
try:
    dev.streamStop()
except:
    pass
dev.getCalibrationData()
dev.streamConfig(NumChannels=1, ChannelNumbers=[0], 
                 ChannelOptions=[0], 
                 ResolutionIndex=0, ScanFrequency=1000)
stream = dev.streamData(convert=False)
dev.streamStart()
data = next(stream)
dev.streamStop()

yields the following traceback

  File "packerror.py", line 15, in <module>
    data = next(stream)
  File "site-packages/LabJackPython-2.0.0-py3.7.egg/LabJackPython.py", line 786, in streamData
  File "site-packages/LabJackPython-2.0.0-py3.7.egg/LabJackPython.py", line 316, in read
  File "site-packages/LabJackPython-2.0.0-py3.7.egg/LabJackPython.py", line 361, in _readFromExodriver
struct.error: pack expected 2496 items for packing (got 2560)

[mickp]

Seems to be good for rates from 1 to 822 Hz (haven't checked exhaustively), then bad for the following (inclusive) ranges:

1025 - 1041
1050 - 1066
1075 - 1092
1100 - 1117
1125 - 1144
1150 - 1168
1175 - 1195
1200 - 1219

The pack error is only ever on the first retrieval from the streamData generator after its construction; subsequent next calls work fine, i.e.:

stream = streamData()
next(stream) # fails with pack error
next(stream) # no error
...
next(stream) # no error
stream = streamData()
next(stream) # fails with pack error
next(stream) # no error
...

[davelopez01]

I haven't been able to reproduce the struct.error on Windows, Linux or Mac.

What operating system and its version are you using?

What firmware version is on your U6 (check with the configU6 method)?

If you power cycle your U6 and run your code, does it have the same issue?

[mickp]

Firmware v 1.39. Same problem under Manjaro & arch, on different machines. I'll try a firmware update and report back.

[mickp]

I still see the issue with the latest firmware, 1.45 Linux kernel: 4.19.69 python: 3.7.4 HardwareVersion: 2.0.0 LabJackPython.GetDriverVersion(): 2.0600.

[mickp]

111 is a one-line change that prevents the error, and the data looks good - if I configure FIO0 as a frequency output and sample it, I see no discontinuities or spurious points.

[mnaberez]

111 is a one-line change that prevents the error, and the data looks good

PR #111 looks similar to #106, which was previously rejected because the author did not respond to requests for more information. Thankfully @mickp has been very active on this ticket so hopefully the issue can be troubleshot and resolved this time around.

[mickp]

Yeah - #106 is the same behaviour change, to address the same issue. I've been unable to figure out the underlying cause (why are too few bytes being read?), but the workaround delivers what I believe to be the expected behaviour.

[davelopez01]

Thanks for the additional information. I'll see if I can reproduce your issue before accepting your commit.

As for the too few bytes being read, that would occur with the 1 second USB timeout and all requested data not being available. Responses come in 64-byte packets, so with your error the last packet wasn't available within the timeout period. Likely with a small delay after the stream start you wouldn't get the error.

[davelopez01]

@mickp , I made a commit to help prevent the partial stream read packets. Please try out the latest LabJackPython here on GitHub and let me know if this resolves your issue or not.

I didn't use your pull request's solution as I wanted to prevent the partial reads, and that error lets me know when stream code relating to read sizes needs fixing/tweaking.

[mickp]

Yep - that fixes things here.

[davelopez01]

Thanks. I'm going to close this out.