VISA doesn't talk to USB Tektronix oscilloscope on RH4 WS Linux although works well on Windows XP

[DVV]

Thank you for your efforts to reproduce the problem.

Although your thoughts on that  are resonable, I think, they don't explain all  facts:
1) why everything works on Windows XP with the same hardware, and especially
2) why it my C example described in the message 12 works well on RH Linux when it runs for the first time after the device is plugged in.
BTW, I use a different model of the scope, TDS2024B, it's resonably new, bought at 2007.

I did an exercise making the C-program to call write/read pair for 2000 times and it worked fine (only for the first time, of course).

Now I switched to RHEL 5 since it has builtin kernel usb monitoring feature (usbmon). Will send you usb traffic logs soon.

Regards,
DVV.

[DVV]

Hi,

I mentioned previously that I switched to RHEL5 (kernel 2.6.18-53.1.4) to use the debuging feature of the newer kernel to monitor an usb traffic.
This feature is activated by mounting a special file system:
# mount -f debugfs none_debugs /sys/kernel/debug  and then dumping the output from a device
# cat /sys/kernel/debug/usbmon/Xt > usbmon_dump.txt 

The problem is still there.
Since NIvisaic never works this time I used my simple C-program I mentioned earlier. This time it made only 3 write/read sequencies (n = 3), not 2000.
The dump file corresponds to the following sequence of events:
1) unplugging the scope at non-working state (no communication is possible)
2) plugging it again
3) running the C-program which runs successfully at this point showing
j=0 Data read: TEKTRONIX, TDS 2024B,C031476,CF;91.1CT FV:v22.01
j=1 Data read: TEKTRONIX, TDS 2024B,C031476,CF;91.1CT FV:v22.01
j=2 Data read: TEKTRONIX, TDS 2024B,C031476,CF;91.1CT FV:v22.01
4) running the C-program for the second time (now it fails)

for your convinience I put my comments in the file starting with "-----------" separating the parts (1)-(4).
The format of the dump is described in /usr/src/linux/Documentation/usb/usbmon.txt or /usr/share/doc/kernel-doc-2.6.*/Documentation/usb/usbmon.txt
or you can look at it here (see "Raw text data format" section).

[Sarah_R]

Hey DVV,

Thank you for that information.

The situation that you are currently seeing could be related to the very first write after a reboot does some on-demand initialization of stuff in the kernel which slows things down.  After the first write, stuff is fully initialized and so subsequent writes are faster.

The problem with many USB products is that they are tested only on Windows and so on other platforms which may do a slightly different order of bus activity, or use a slightly different (but valid) variant of the standardized USB calls, or have a different timing (many are faster like Linux) may not work on these devices.

Please feel free to submit a product suggestion if you would like at: http://www.ni.com/contact.

Thanks and hope you have a great day.

Message Edited by Sarah_S on 01-15-2008 07:42 AM

[DVV]

Sorry, I can not quite get your arguments about slowing things down at the first write because it's the first one after reboot and kernel needs to do some additional initialization.

I must be not clear enough - I don't do a reboot - I just unplug and plug the scope and it works (for one time). Does the kernel needs additional initializations in this case?

Then my program doesn't do one write it does 2000 writes and reads and all are success when it runs for the first time after unpluging/pluging. It takes 2-3minutes to complete these transactions - enough time everything settles down in the kernel.

To me it rather looks like calls to visa put either the scope or a linux usb stack to some unproper state at closing time (at the first time the program runs) so after that a communication is not possible.

The device by itself CAN work with the linux usb stack which is proven by 2min long/2000 transaction successful communication cycle.

Regards,
DVV.

[Sarah_R]

I will be sure to pass all of this information onto R&D, and we will continue doing research into this issue. I will let you know any current information as soon as I have it.

Thank you for your patience and sorry for your frustrations.

[hamid.ohadi]

Hi,

I have this problem too. Exactly this problem with the same scope model. Works in Windows and seen by Linux but writing fails. Any advice?

[Promme]

Yep the same problem with a complete new TDS 2024, NI-VISA 4.4 open-SUSE 10.1 (2.6.16.54-0.2.5-smp
) 32 bit 2 years old DELL Optiplex GX620. First plug/communication is working, then timeout errors. I'm very sad about this, since programming and gnu usage is much easier under linux than under Windows.... Did anybody try with older devices/kernels? For example running with USB 1.0?

Message Edited by Promme on 08-28-2008 09:29 AM

[Promme]

I even found 4 other topics here in the board related to this problem. Everyone dealing this this problem on linux. I just discovered that I even don't have to plug and unplug the scope, but it is enogth to change the virtual GPIB Address or the USB interface type (in Auto detect or Computer) to have the same effect like plugging and uplugging the device! This means one communication session is possible with reading and writing from/to the scope as often and as long as I want (even receiving thousands of waveforms). All other once are not working anymore and I have to change again for example the GPIB adress on the scope. What is Tektronix / kernel or the NI-VISA doing wrongly?

[hamid.ohadi]

interesting! how would you change the virtual GPIB address?

[Promme]

I change the virtual GPIB adress on my scope:

press "Utility" -> Options -> GPIB Setup -> Address