dpenkler
commented
8 months ago Hi Tobias, I remember a long time ago we had a "quirk" setting for Rigol but we found that it was no longer needed and removed it. Not being familiar with python I have written a C program you could use to test the driver taking a screendump from your scope. Please compile and run the attached program. It should place the screen dump into a file called screendump.png. $ cc -o rigol rigol.c $ ./rigol cheers, -Dave
On Thu, 29 Feb 2024 at 15:14, Tobias Binkowski @.***> wrote:
``Hello,
first of all I'm not really familiar with USB and TMC but with drivers. I use a Rigol DS1054Z which is known to be somewhat limited in regards to downloading screenshots as it always chunks response data to 52 Bytes of payload. See [PyViSA-Issue(https://github.com/pyvisa/pyvisa/issues/481 https://github.com/pyvisa/pyvisa/issues/481#issuecomment-1477334673).
I had the same problem with PyVISA and it's pyvisa_py usbtmc implementation. In this code I were able to Monkey-Patch the RECV_CHUNK size down to 52 Bytes ( source https://github.com/pyvisa/pyvisa-py/blob/main/pyvisa_py/protocols/usbtmc.py#L302
from pyvisa_py.protocols.usbtmc import USBTMC as USBTMC USBTMC.RECV_CHUNK = 64-12
I tested this driver and I think I run into a similar issue, at least related. When trying to download data the first packet (which includes some binary header) is ok, all others are rejected by the usbtmc_read function:
[691990.970573] usbtmc 3-2.1.4:1.0: usbtmc_write(size:26 align:40) [691990.970606] usbtmc 01 01 fe 00 1a 00 00 00 01 00 00 00 3a 64 69 73 ............:dis [691990.970616] usbtmc 70 6c 61 79 3a 64 61 74 61 3f 20 6f 6e 2c 6f 66 play:data? on,of [691990.970622] usbtmc 66 2c 70 6e 67 0a 00 00 f,png... [691990.970650] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2 sema=15 [691990.970712] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total size: 40 [691990.970804] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=40, retval=0, urbstat=0 [691996.716002] usbtmc 3-2.1.4:1.0: usbtmc_read(count:131072) [691996.716262] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0), actual(64) [691996.716277] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(36013), bTransAttr(1) [691996.716292] usbtmc 02 02 fd 00 ad 8c 00 00 01 00 00 00 23 39 30 30 ............#900 [691996.716294] usbtmc 30 30 33 36 30 30 31 89 50 4e 47 0d 0a 1a 0a 00 0036001.PNG..... [691996.716295] usbtmc 00 00 0d 49 48 44 52 00 00 03 20 00 00 01 e0 08 ...IHDR... ..... [691996.716296] usbtmc 02 00 00 00 d2 65 9e a2 00 00 00 0c 74 45 58 74 .....e......tEXt [691996.716317] usbtmc 3-2.1.4:1.0: usbtmc_read(count:131072) [691996.716519] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0), actual(64) [691996.716533] usbtmc 3-2.1.4:1.0: Device sent reply with wrong MsgID: 65 != 2
After some first try to debug (basically ignoring most error cases in usbtmc_read which are related to data buffers and doing the debug print before error checking I get the follwing trace as received data:
[692565.224716] usbtmc 3-2.1.4:1.0: usbtmc_write(size:26 align:40) [692565.224737] usbtmc 01 01 fe 00 1a 00 00 00 01 00 00 00 3a 64 69 73 ............:dis [692565.224742] usbtmc 70 6c 61 79 3a 64 61 74 61 3f 20 6f 6e 2c 6f 66 play:data? on,of [692565.224745] usbtmc 66 2c 70 6e 67 0a 00 00 f,png... [692565.224762] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2 sema=15 [692565.224800] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total size: 40 [692565.224878] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=40, retval=0, urbstat=0 [692568.226105] usbtmc 3-2.1.4:1.0: usbtmc_read(count:4096) [692568.226378] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0), actual(64) [692568.226400] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(4096), bTransAttr(0) [692568.226404] usbtmc 02 02 fd 00 00 10 00 00 00 00 00 00 23 39 30 30 ............#900 [692568.226407] usbtmc 30 30 33 36 30 30 31 89 50 4e 47 0d 0a 1a 0a 00 0036001.PNG..... [692568.226408] usbtmc 00 00 0d 49 48 44 52 00 00 03 20 00 00 01 e0 08 ...IHDR... ..... [692568.226410] usbtmc 02 00 00 00 d2 65 9e a2 00 00 00 0c 74 45 58 74 .....e......tEXt [692568.226478] usbtmc 3-2.1.4:1.0: usbtmc_read(count:4096) [692568.226570] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0), actual(64) [692568.226591] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(1375761007), bTransAttr(73) [692568.226595] usbtmc 41 75 74 68 6f 72 00 52 49 47 4f 4c e7 88 8c c9 Author.RIGOL.... [692568.226598] usbtmc 00 00 00 11 74 45 58 74 53 6f 75 72 63 65 00 44 ....tEXtSource.D [692568.226601] usbtmc 53 5a 20 73 65 72 69 65 73 3f 5a 1d 97 00 00 00 SZ series?Z..... [692568.226603] usbtmc 29 74 45 58 74 44 65 73 63 72 69 70 74 69 6f 6e )tEXtDescription [692568.226658] usbtmc 3-2.1.4:1.0: usbtmc_read(count:4096) [692568.226752] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0), actual(64) [692568.226757] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(1769099359), bTransAttr(110) [692568.226761] usbtmc 00 44 53 5a 5f 50 72 69 6e 74 69 6e 67 20 65 71 .DSZ_Printing eq [692568.226763] usbtmc 75 69 70 6d 65 6e 74 20 6f 75 74 70 75 74 c1 a5 uipment output.. [692568.226766] usbtmc 35 c1 00 00 00 1c 74 45 58 74 43 6f 70 79 72 69 5.....tEXtCopyri [692568.226769] usbtmc 67 68 74 00 52 49 47 4f 4c 20 54 45 43 48 4e 4f ght.RIGOL TECHNO [692568.226823] usbtmc 3-2.1.4:1.0: usbtmc_read(count:4096) [692568.226900] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0), actual(64) [692568.226905] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(350442309), bTransAttr(97) [692568.226910] usbtmc 4c 4f 47 49 45 53 e3 14 61 af 00 00 8b d6 49 44 LOGIES..a.....ID [692568.226913] usbtmc 41 54 78 01 ed bd 2d 98 24 d7 95 ad 9d 40 a0 81 @. [692568.226916] usbtmc 40 01 81 02 02 05 04 1a 08 34 30 28 20 50 40 a0 @........40( @. [692568.226919] usbtmc 81 41 03 83 02 02 02 06 02 03 04 06 08 0c 68 70 .A............hp [692568.226999] usbtmc 3-2.1.4:1.0: usbtmc_read(count:4096) [692568.227069] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0), actual(64) [692568.227074] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(4213234343), bTransAttr(216) [692568.227079] usbtmc e2 e8 98 09 a7 da 20 fb d8 76 b3 06 b2 d9 8b 48 ...... ..v.....H [692568.227082] usbtmc 13 37 45 89 e3 9d 79 58 ee b1 25 d7 fc ac 45 80 .7E...yX..%...E. [692568.227085] usbtmc c5 d0 43 23 a9 82 bf e1 12 f0 52 ca 08 12 c8 d5 ..C#......R..... [692568.227089] usbtmc 15 3c c1 b6 0a 1b 45 20 b9 fb 2c f3 f3 d7 59 d2 .<....E ..,...Y. [........]
However this also does not really work. So the question I have in the moment is, is this device sending correct data frames (with pyvisa_py's usbtmc implementation it works) and is the code making too simple assumptions here?
From the dataframes I would expect that the usbtmc_read function would need to handle this kind of chunked data where no header information is available?
As this is not really reproducible on your side I expect, please ask if you need any kind of dump (not sure if I could trace the USB traffic?)
Thanks for your support & Regards, sessl3r
— Reply to this email directly, view it on GitHub https://github.com/dpenkler/linux-usbtmc/issues/8, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASAZ3M6OA3AIS6YZO3MPWDYV43TPAVCNFSM6AAAAABEAAQW2SVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE3DCMZWGY2DANI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
sessl3r
``Hello,
first of all I'm not really familiar with USB and TMC but with drivers. I use a Rigol DS1054Z which is known to be somewhat limited in regards to downloading screenshots as it always chunks response data to 52 Bytes of payload. See PyViSA-Issue.
I had the same problem with PyVISA and it's pyvisa_py usbtmc implementation. In this code I were able to Monkey-Patch the RECV_CHUNK size down to 52 Bytes ( source ).
I tested this driver and I think I run into a similar issue, at least related. When trying to download data the first packet (which includes some binary header) is ok, all others are rejected by the usbtmc_read function:
After some first try to debug (basically ignoring most error cases in usbtmc_read which are related to data buffers and doing the debug print before error checking I get the follwing trace as received data:
However this also does not really work. So the question I have in the moment is, is this device sending correct data frames (with pyvisa_py's usbtmc implementation it works) and is the code making too simple assumptions here? I expect the second as the USBTMC specification states for multi-transaction Bulk-IN transfers where only the first one includes the header.
From the dataframes I would expect that the usbtmc_read function would need to handle this kind of chunked data where no header information is available?
As this is not really reproducible on your side I expect, please ask if you need any kind of dump (not sure if I could trace the USB traffic?)
Thanks for your support & Regards, sessl3r