Products > Test Equipment

Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)

<< < (28/74) > >>

Karel:

--- Quote from: frozenfrogz on May 15, 2017, 11:19:45 am ---Can someone please break down the :FUNCtion:WREPlay:FEND // :FUNCtion:WRECord:FEND issue for me? I have not used the remote commands and am not sure if I understand correctly what is going on.
To my understanding, setting the frame size should be two different variables for record and play, but both functions seem to be using the same variable. -> or something like that.. Sorry, I did not have the time to dig into what is going on yet.

--- End quote ---

I connected the scope via LAN and opened a telnet connection.

Then I enabled the record function:


--- Code: ---:FUNC:WREC:ENAB 1

:FUNC:WREC:FEND 20

:FUNC:WREC:OPER RUN

:FUNC:WREP:FST?
1

:FUNC:WREP:FEND?
20

:FUNC:WREP:FMAX?
20

:FUNC:WREP:FEND 10

:FUNC:WREP:FMAX?
10

:FUNC:WREP:FEND 20

:FUNC:WREP:FINT?
5.000000e-01

:FUNC:WREP:OPER PLAY   (plays 20 frames)

:FUNC:WREP:FEND 10

:FUNC:WREP:OPER PLAY (plays 10 frames)

:FUNC:WREP:FMAX?
10

:FUNC:WREP:FEND 20

:FUNC:WREP:FMAX?
20

:FUNC:WREP:OPER PLAY (plays 20 frames)

--- End code ---

The problem here is with the command :FUNC:WREP:FMAX?
It returns the value of :FUNC:WREP:FEND, not the number of frames recorded in memory (set with :FUNC:WREC:FEND).

I refer to the DS1000Z_Programming_Guide_EN_December_2015, page 91 (2-75):

Syntax
 :FUNCtion:WREPlay:FMAX?
Description
 Query the maximum number of frames can be played, namely the maximum number of
frames recorded.

BravoV:
@Frederik,

As an OP, I suggest you to report to moderator to clean up / delete posts from posters that don't own this scope, and clearly not even interested in this scope, but still keep doing pointless bashing here.

Its obvious this DS1000Z does and still create lots of troubles on competing brands.

HoracioDos:
Hello
I recently tried to connect DSRemote via USB (USBTMC) in linux and found this bug. It seems it's NOT a Linux bug. Can it be included in the list?
(Rigol Firmware Version 00.04.04.SP3)


--- Quote from: Karel on December 08, 2016, 06:12:08 pm ---Probably it's a bug in the firmware of the scope that triggers this error in combination with certain USB host controller chipsets.

The reason that this problem occurs on Linux is probably because the kernel developers are more strict with the USB standard.

To give you an example, connect your DS1000Z to a USB port and enter dmesg:


--- Code: ---[  569.775078] usb 1-2: new high-speed USB device number 4 using ehci-pci
[  569.911485] usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[  569.911499] usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
[  569.911976] usb 1-2: New USB device found, idVendor=1ab1, idProduct=04ce
[  569.911987] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  569.911991] usb 1-2: Product: DS1000Z Series
[  569.911994] usb 1-2: Manufacturer: Rigol Technologies.
[  569.911998] usb 1-2: SerialNumber: DS1ZA17040xxxx
[  569.934523] usbcore: registered new interface driver usbtmc

--- End code ---

The scope presents itself as a highspeed USB device but set the maxpacket value for the bulk endpoint to 64 bytes.

The USB standard says that a highspeed USB device MUST set that value to 512 bytes!

I reported this bug to Rigol but no answer so far.

My impression is that they don't care about Linux...

--- End quote ---

More details here:
https://github.com/Teuniz/DSRemote/issues/12#issuecomment-283940080

frozenfrogz:

--- Quote from: HoracioDos on May 15, 2017, 12:56:48 pm ---Hello
I recently tried to connect DSRemote via USB (USBTMC) in linux and found this bug. It seems it's NOT a Linux bug. Can it be included in the list?

--- End quote ---

Hello Horacio,

it is already listed as Bug #8, however I could add more information on this. The Problem of USB interface not being standards compatible (64 bytes instead of 512 bytes packet size) has been discussed.
I will add a more descriptive comment to that.

Regards,
Frederik

HoracioDos:

--- Quote from: frozenfrogz on May 15, 2017, 01:31:42 pm ---it is already listed as Bug #8, however I could add more information on this.

--- End quote ---
Hi frozenfrogz!
Ohh I'm sorry for the inconvenience. I checked the list before posting but obviously I've got it wrong. Thanks!!!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod