Closed sessl3r closed 7 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: @.***>
Hi Tobias, There was a bug in the previous version - not allocating a large enough buffer. Here is the corrected version. cheers, -Dave
On Fri, 1 Mar 2024 at 19:56, dave penkler @.***> wrote:
Hi Toni, 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: @.***>
Hi Dave, I do not see the attached rigol.c you mentinoned? Have you attached it?
Hi Tobias, It seems github removes the attachment so here it is in-line:
#include <sys/ioctl.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <linux/usb/tmc.h>
int fd;
char *sdfn = "screendump.png";
/* Send string to scope */
void sscope(char *msg) {
write(fd,msg,strlen(msg));
printf("sscope: %s",msg);
}
/* Read string from scope */
int rscope(char *buf, int max_len) {
int len = read(fd,buf,max_len);
if (len < 0) {
perror("failed to read from scope");
ioctl(fd,USBTMC_IOCTL_CLEAR);
return 0;
}
buf[len] = 0; /* zero terminate */
return len;
}
int main () {
int len,n;
int i;
int sfd;
char buf[256],*gbuf;
unsigned char stb;
/* Open file */
if (0 > (fd = open("/dev/usbtmc0",O_RDWR))) {
perror("failed to open device");
exit(1);
}
/* Send device clear */
if (0 != ioctl(fd,USBTMC_IOCTL_CLEAR)) {
perror("Dev clear ioctl failed");
goto out;
}
sscope("*CLS\n"); // clear status regs
sscope("*ESE 1\n"); // set operation complete in the event status enable reg
sscope(":DISP:DATA? ON, OFF, PNG;*OPC\n"); // For Rigol scope
// sscope(":DISP:DATA? PNG, COL;*OPC\n"); // For Keysight scope
rscope(buf,2); // read first 2 bytes of header block
if (buf[0] != '#') { /* Check that we have a valid header */
fprintf(stderr, "invalid IEEE488 # binary block header\n");
goto out;
}
n = buf[1] - 48; // get the number of digits in data length
if (n < 2 || n > 9) {
fprintf(stderr, "Invalid block length in IEEE488 BB header\n");
goto out;
}
rscope(buf,n); // read data length
len = atoi(buf);
// check status byte for operation complete i.e. ESB set
if (0 != ioctl(fd,USBTMC488_IOCTL_READ_STB,&stb)) {
perror("stb ioctl failed");
goto out;
}
n = 0;
printf("Waiting for OPC\n");
while (!(stb & 32)) { /* wait for ESB */
n++;
if (n==10) {
fprintf(stderr,"Timed out\n");
goto out;
}
sleep(1);
if (0 != ioctl(fd,USBTMC488_IOCTL_READ_STB,&stb)) {
perror("stb ioctl failed");
goto out;
}
}
printf("Reading %d bytes of display data\n",len);
gbuf = malloc(len + 1); // +1 for null termination in rscope
n = rscope(gbuf, len);
printf("%d bytes read\n", n);
if (n != len) {
fprintf(stderr, "Short read\n");
goto out;
}
rscope(buf,1); // read last byte (linefeed)
if (buf[0] != '\n') fprintf(stderr,"Expected newline at the end\n");
sfd = open(sdfn, O_RDWR | O_CREAT, 0660); // open png file
if (sfd < 0) {
fprintf(stderr,"Failed to open %s\n",sdfn);
goto out;
}
write(sfd, gbuf, n); // write png data
close(sfd);
printf("screen dumped to %s\n",sdfn);
out:
close(fd);
}
Hi Dave,
thanks for the code. Tried it as follows with linux-usbtmc e32bbea built with DEBUG
$ sudo insmod usbtmc
$ dmesg -w &
$ echo "*idn?" > /dev/usbtmc0 && cat /dev/usbtmc0
[364445.378187] usbtmc 3-2.1.4:1.0: usbtmc_write(size:6 align:20)
[364445.378216] usbtmc 01 01 fe 00 06 00 00 00 01 00 00 00 2a 69 64 6e
............*idn
[364445.378221] usbtmc 3f 0a 00 00 ?...
[364445.378235] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2
sema=15
[364445.378313] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total
size: 20
[364445.378370] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=20,
retval=0, urbstat=0
RIGOL TECHNOLOGIES,DS1074Z,DS1Z**********,00.04.04.S
[364445.381547] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(64)
[364445.381554] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(55),
bTransAttr(1)
[364445.381557] usbtmc 02 02 fd 00 37 00 00 00 01 00 00 00 52 49 47 4f
....7.......RIGO
[364445.381559] usbtmc 4c 20 54 45 43 48 4e 4f 4c 4f 47 49 45 53 2c 44 L
TECHNOLOGIES,D
[364445.381560] usbtmc 53 31 30 37 34 5a 2c 44 53 31 5a 00 00 00 00 00
S1074Z,DS1Z00000
[364445.381561] usbtmc 00 00 00 00 00 2c 30 30 2e 30 34 2e 30 34 2e 53
00000,00.04.04.S
[364445.381589] usbtmc 3-2.1.4:1.0: usbtmc_read(count:131072)
[364445.381701] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(4)
[364445.381709] usbtmc 3-2.1.4:1.0: Device sent too small first packet: 4 <
12
$ ./rigol
sscope: *CLS
sscope: *ESE 1
sscope: :DISP:DATA? ON, OFF, PNG;*OPC
[364472.203668] usbtmc 3-2.1.4:1.0: Sending INITIATE_CLEAR request
[364472.203982] usbtmc 3-2.1.4:1.0: INITIATE_CLEAR returned 1
[364472.203989] usbtmc 3-2.1.4:1.0: Sending CHECK_CLEAR_STATUS request
[364472.204219] usbtmc 3-2.1.4:1.0: CHECK_CLEAR_STATUS returned 1
[364472.204661] usbtmc 3-2.1.4:1.0: usbtmc_write(size:5 align:20)
[364472.204674] usbtmc 01 04 fb 00 05 00 00 00 01 00 00 00 2a 43 4c 53
............*CLS
[364472.204687] usbtmc 0a 00 00 00 ....
[364472.204695] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2
sema=15
[364472.204744] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total
size: 20
[364472.204786] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=20,
retval=0, urbstat=0
[364472.204877] usbtmc 3-2.1.4:1.0: usbtmc_write(size:7 align:20)
[364472.204882] usbtmc 01 05 fa 00 07 00 00 00 01 00 00 00 2a 45 53 45
............*ESE
[364472.204883] usbtmc 20 31 0a 00 1..
[364472.204890] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2
sema=15
[364472.204950] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total
size: 20
[364472.204978] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=20,
retval=0, urbstat=0
[364472.204995] usbtmc 3-2.1.4:1.0: usbtmc_write(size:30 align:44)
[364472.204999] usbtmc 01 06 f9 00 1e 00 00 00 01 00 00 00 3a 44 49 53
............:DIS
[364472.205002] usbtmc 50 3a 44 41 54 41 3f 20 4f 4e 2c 20 4f 46 46 2c
P:DATA? ON, OFF,
[364472.205004] usbtmc 20 50 4e 47 3b 2a 4f 50 43 0a 00 00
PNG;*OPC...
[364472.205019] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2
sema=15
[364472.205062] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total
size: 44
[364472.205086] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=44,
retval=0, urbstat=0
[364472.205105] usbtmc 3-2.1.4:1.0: usbtmc_read(count:2)
[364472.613237] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(14)
[364472.613254] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(2),
bTransAttr(0)
[364472.613269] usbtmc 02 07 f8 00 02 00 00 00 00 00 00 00 23 39
............#9
[364472.613289] usbtmc 3-2.1.4:1.0: usbtmc_read(count:9)
[364472.613541] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(22)
[364472.613556] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(9),
bTransAttr(0)
[364472.613570] usbtmc 02 08 f7 00 09 00 00 00 00 00 00 00 30 30 30 30
............0000
[364472.613572] usbtmc 33 30 34 35 38 48
30458H
[364472.613600] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
Waiting for OPC
[364472.700310] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364472.700411] usbtmc 3-2.1.4:1.0: stb:0x00 received 4978
[364473.701054] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364473.724307] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364473.724422] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364474.724607] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364474.748305] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364474.748412] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364475.748598] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364475.772287] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364475.772384] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364476.772568] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364476.796291] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364476.796406] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364477.796592] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364477.820278] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364477.820383] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364478.820564] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364478.844275] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364478.844371] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364479.844554] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364479.868270] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364479.868370] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364480.868553] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[364480.892266] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364480.892364] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
[364481.892787] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
Timed out
[364481.916233] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[364481.916331] usbtmc 3-2.1.4:1.0: stb:0x00 received 4994
So for some reason status register read seams to not work. Commented this out and just waited for a second I then got the following:
$ ./rigol
sscope: *CLS
sscope: *ESE 1
sscope: :DISP:DATA? ON, OFF, PNG;*OPC
[365058.122268] usbtmc 3-2.1.4:1.0: Sending INITIATE_CLEAR request
[365058.122516] usbtmc 3-2.1.4:1.0: INITIATE_CLEAR returned 1
[365058.122525] usbtmc 3-2.1.4:1.0: Sending CHECK_CLEAR_STATUS request
[365058.122662] usbtmc 3-2.1.4:1.0: CHECK_CLEAR_STATUS returned 1
[365058.122996] usbtmc 3-2.1.4:1.0: usbtmc_write(size:5 align:20)
[365058.123005] usbtmc 01 13 ec 00 05 00 00 00 01 00 00 00 2a 43 4c 53
............*CLS
[365058.123009] usbtmc 0a 00 00 00 ....
[365058.123018] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2
sema=15
[365058.123078] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total
size: 20
[365058.123165] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=20,
retval=0, urbstat=0
[365058.123257] usbtmc 3-2.1.4:1.0: usbtmc_write(size:7 align:20)
[365058.123262] usbtmc 01 14 eb 00 07 00 00 00 01 00 00 00 2a 45 53 45
............*ESE
[365058.123266] usbtmc 20 31 0a 00 1..
[365058.123273] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2
sema=15
[365058.123286] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total
size: 20
[365058.123398] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=20,
retval=0, urbstat=0
[365058.123420] usbtmc 3-2.1.4:1.0: usbtmc_write(size:30 align:44)
[365058.123425] usbtmc 01 15 ea 00 1e 00 00 00 01 00 00 00 3a 44 49 53
............:DIS
[365058.123428] usbtmc 50 3a 44 41 54 41 3f 20 4f 4e 2c 20 4f 46 46 2c
P:DATA? ON, OFF,
[365058.123430] usbtmc 20 50 4e 47 3b 2a 4f 50 43 0a 00 00
PNG;*OPC...
[365058.123438] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: size=0 flags=0x2
sema=15
[365058.123471] usbtmc 3-2.1.4:1.0: usbtmc_write_bulk_cb - write bulk total
size: 44
[365058.123502] usbtmc 3-2.1.4:1.0: usbtmc_generic_write: done=44,
retval=0, urbstat=0
[365058.123520] usbtmc 3-2.1.4:1.0: usbtmc_read(count:2)
[365058.538851] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(14)
[365058.538879] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(2),
bTransAttr(0)
[365058.538882] usbtmc 02 16 e9 00 02 00 00 00 00 00 00 00 23 39
............#9
[365058.538903] usbtmc 3-2.1.4:1.0: usbtmc_read(count:9)
[365058.539167] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(22)
[365058.539183] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(9),
bTransAttr(0)
[365058.539197] usbtmc 02 17 e8 00 09 00 00 00 00 00 00 00 30 30 30 30
............0000
[365058.539199] usbtmc 33 30 37 34 37 48
30747H
[365058.539228] usbtmc 3-2.1.4:1.0: Enter ioctl_read_stb iin_ep_present: 1
[365058.552219] usbtmc 3-2.1.4:1.0: int status: 0 len 2
[365058.552334] usbtmc 3-2.1.4:1.0: stb:0x00 received 4997
Reading 30747 bytes of display data
52 bytes read
Short read
[365059.552497] usbtmc 3-2.1.4:1.0: usbtmc_read(count:30747)
[365059.552706] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(64)
[365059.552715] usbtmc 3-2.1.4:1.0: Bulk-IN header: N_characters(30747),
bTransAttr(0)
[365059.552718] usbtmc 02 18 e7 00 1b 78 00 00 00 00 00 00 89 50 4e 47
.....x.......PNG
[365059.552720] usbtmc 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 03 20
........IHDR...
[365059.552722] usbtmc 00 00 01 e0 08 02 00 00 00 d2 65 9e a2 00 00 00
..........e.....
[365059.552723] usbtmc 0c 74 45 58 74 41 75 74 68 6f 72 00 52 49 47 4f
.tEXtAuthor.RIGO
Exactly what I have seen before. Some first chunk of data is received, but most is missing. When executing a hexdump after the above I always get the following:
$ hexdump -C /dev/usbtmc0
[365184.992510] usbtmc 3-2.1.4:1.0: usbtmc_read(count:4096)
[365184.992643] usbtmc 3-2.1.4:1.0: usbtmc_read: bulk_msg retval(0),
actual(64)
[365184.992651] usbtmc 3-2.1.4:1.0: Device sent reply with wrong MsgID: 76
!= 2
Which is as described in the inital issue description due to the fakt that chunked data is not expected to contain a header again but just payload.
OK - this is a "new" quirk. As I mentioned we had something like this before but we changed the driver to handle it by default, Please send the output of lsusb -v -d 1ab1: Thanks.
The lsusb output is attached. Clearly this device reports it's MaxPacketSize. I patched the driver and got it working with this device. Please see my fork.
I would open a PR for this if you share my opinion that this is the root-cause
Bus 003 Device 016: ID 1ab1:04ce Rigol Technologies DS1xx4Z/MSO1xxZ series
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1ab1 Rigol Technologies
idProduct 0x04ce DS1xx4Z/MSO1xxZ series
bcdDevice 0.02
iManufacturer 1 Rigol Technologies.
iProduct 2 DS1000Z Series
iSerial 3 DS1Z**********
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0027
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 3 Test and Measurement
bInterfaceProtocol 1 TMC
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Hi Tobias, Yes, that is where I was going too. In the unlikely case that bMaxPacketSize is different for bulk ep_in and ep_out we should use two separate fields (as you indicated). Happy to take a PR. cheers, -Dave
``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