struct.pack error at low sample rates about labjackpython HOT 11 CLOSED

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
...

from labjackpython.

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?

from labjackpython.

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

from labjackpython.

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.

from labjackpython.

#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.

from labjackpython.

#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.

from labjackpython.

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.

from labjackpython.

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.

from labjackpython.

@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.

from labjackpython.

Yep - that fixes things here.

from labjackpython.

Thanks. I'm going to close this out.

from labjackpython.