Add new VISA resource names options and Startup delay

[aleruggeri87]

Hi Kai,

I made a few modifications to the source code and updated the README file accordingly.

Specifically:

• Both the initial available option for VISA resource naming, produced with some instruments very long names. The MATLAB visa command seems to handle only names shorter than approx. 50 characters. For this reason, I added two new modes that produce short names.
• I encountered issues when leaving the UsbGpib connected to a powered-off instrument. When powered on, the UsbGpib immediately tried to search for the instrument address. This might have triggered some instrument bootloader, corrupting the it firmware. To avoid this, I implemented a simple programmable startup delay, which delays any UsbGpib operation for a specified amount of time after the instrument has been turned on.

Thank you for your excellent work. Overall, it works and integrates very well, better than many commercial solutions.
I hope my modifications are appreciated.

Best,
Alessandro.

[xyphro]

Hi Alesandro,

Thanks a lot for your contribution. I am busy right now speeding up transfers and will merge and test your pull request afterwards.
Btw: Writes will be in future 7 times faster and reads more than 4 times (including usb latencies)!

[xyphro]

And i value starup delays a lot btw! Auto id feature might get better with it

[xyphro]

From a quick browse over the code it looks good and well integrated using the pulse indicator triggered sidechannel. Thanks for fixing also the typos in the readme. Some I had seen myself but was not motivated yet to fix them :-)

Let me test this next week, also with my latest local changes, then I will merge it.

[aleruggeri87]

Hi, no problem, take your time, and merge when it better suits you.

It's been a while since I wanted to submit my changes. Recently, I noticed your numerous updates, and I was concerned about potential conflicts. However, with your current master, as you can see, the merge is straightforward.
I've tested the merged version during last week, and everything seems to be working fine.
At your disposal for further clarifications and looking forward for the improved high-speed version 😋

Cheers,
Alessandro.

[xyphro]

Hi Alessandro,

sorry - short update: I merged it locally already and tested it successfully. Thanks a lot!
Still I don't push it yet as I am busy trying to pass fully a 488.2 compliance test.

Best regards,

Kai

[xyphro]

Hi Allesandro,

I did a lot of changes of the configuration interface and it now supports textual commands.

I implemented your items like this:

!string short => limits ressource string = serial number length to 28 characters. Independent on if autoid is used or not. Allthough I use matlab often, I don't have it by hand right now to determine the exact maximum length, but 28 should be OK.
!string normal => Does not limit the string length (default behavior)

!autoid off -> no autoid sensing using *IDN? or ID?
!autoid on -> "0s" delay (default)
!autoid slow -> 10s delay
!autoid slower -> 30s delay
!autoid slowest -> 60s delay

Not as nice as your approach which is adjustable in 0.5s steps, but I wanted to keep the text parser simple and this maybe does at the end the same. It might be hard to determine the exact amount of required delay time anyway.

Hope you are fine with this! I did not push the sourcecode/ binary for this yet as I also want to take your grammar corrections into the latest readme.md and in general want to improve the readme.mds.

BTW: I have also one instrument that has a debug GPIB port enabled during powerup - CMU200. It does not distort the instrument operation, but comes up with another *IDN? response during startup when the delay time is short.

[aleruggeri87]

Hi Kai,

thanks for keeping me updated on your development.

When I was trying to using the UsbGpib with MATLAB, I tried with some instruments that were enumerated (with the default settings) as:

USB0::0x03EB::0x2065::TEKTRONIX_AFG3102_C011696_SCPI_99.0_FV_1.1.3::INSTR
USB0::0x03EB::0x2065::HEWLETT-PACKARD_8131A_0_1.5::INSTR
USB0::0x03EB::0x2065::KEITHLEY_INSTRUMENTS_INC._MODEL_2400_1204575_C30::INSTR
USB0::0x03EB::0x2065::NSDCI+0.0000E-09_B0000::INSTR

The last device is a KE236 SMU that doesn't recognize the *IDN command. However, the replay string was short enough (overall lenght: 51 chars) to be recognized by MATLAB, so I understood the issue. The HP8131A string is 56 chars and doesn't work. So, the limitation seems to be somewhere in between. If you are counting only the characters in the "central" part of the string, the one available on the microcontroller, I would suggest to limit it to 20-22 chars.
Please note that I used the visa object instead of the visadev one, which was introduced in the latest releases. In the official documentation, this limitation is not mentioned; maybe is only related to the old object or is a bug in my release (R2017b). Unfortunately, I don't have a newer/another release to perform further tests.

Currently, I am using my format 03, i.e. something like this: USB0::0x03EB::0x2065::GPIB_NN::INSTR. I'm used to associate an unique GPIB number to each instrument and placing a sticker on them to properly identify them. I am not sure you have retained this format among the available options. Maybe you need a !string gpibonly or something similar. It would be very appreciated from "legacy" people like me 😉.

Regarding the *IDN request delay, I think your discretization is totally fine.
I am currently using a 5 seconds delay, and I find a good compromise between safety and reaction time (useful when you have to frequently restart the instrument after offending commands 😉).
I would suggest you to modify the values to something like 0, 5, 10 and 30. If the instrument requires more time to boot... I think there are other issues 😆. Actually, there is a case where the boot can be very long: Windows-based instruments; but I am not sure how the GPIB and *IDN command parsing is managed there.

I wish you a great start to the New Year,
Alessandro.

[xyphro]

Hi Alesandro,

Thanks for additional input. Will change the times and shorteb the strings further.

I need to think about your gpib_NN proposal. This makes sense, but can create issues when you have 2 times the same gpib address. Maybe I make the gpibonly proposal - let me think.

Best regards,

Kai