Feature Request : Read Termination / AutoID Settings

[dazz100]

The README file describes how to set the termination and autoID type/values.

I am thinking the adapters should be transparent and instrument agnostic. The GPIB controlling software should always write/select the correct terminator/AutoID setting at start-up. This will ensure that no matter which equipment the adapter is plugged into, it will be correctly configured by the controller for the instrument being controlled. nvRAM has limited write cycles so what is needed is a method of reading the settings, and only writing if they need changing. This will significantly extend the life of the adapter.

The feature request is to add a method to the adapter firmware that allows the GPIB controller to read the selected options.

It would be desirable, not essential, for the method to be human readable just to make it easier to read the code.

Edit: In the general case, the existing write function shouldn't write to nvRAM if the data matches what is there.
It would still be useful to read the specific settings.

[xyphro]

Hi dazz100,

Fully agree. Why? I had that same thought too :-D Just joking...

It is easier to make the ternination setting simply part of your instrument specific script rather than "bake" it into the nvmem and run into issues when you plug it ibto the next instrument.

Concerning limited write cycles: if I am not wrong I only do write when a value changed. At least.... normally I would do it like that. Will check.

I don't like my sidechannel creation mechanism that much anymore (pulse indicator request) to change those settings... but I also don't want to introduce "special gpib sequences" which can create unpredictable issues so for now I stick to it unless there are better suggestions. Vebdor specific transfers are not realized everywhere...

So: will pick your suggestions up! Also readback...

[xyphro]

I checked: yes, I only write to eeprom when a value really changed. This means with its 100000 write cycles lifetime and maybe 10 years of lifetime expectation and 365 days of usage per year you can change it 27 times per day to different values :-)

So don't see any concern there. But from usability perspective I would like to add read option and an option to change it during runtime without storing in nvmem.

[dazz100]

Hi dazz100,

Fully agree. Why? I had that same thought too :-D Just joking...

It is easier to make the ternination setting simply part of your instrument specific script rather than "bake" it into the nvmem and run into issues when you plug it ibto the next instrument.

I agree. My plan is to do exactly that. I want to be able to plug any adapter into any instrument at any time. That would require the controller software to check/configure the adapter.

Concerning limited write cycles: if I am not wrong I only do write when a value changed. At least.... normally I would do it like that. Will check.

I don't like my sidechannel creation mechanism that much anymore (pulse indicator request) to change those settings... but I also don't want to introduce "special gpib sequences" which can create unpredictable issues so for now I stick to it unless there are better suggestions. Vebdor specific transfers are not realized everywhere...

So: will pick your suggestions up! Also readback...

I have not studied your side channel solution. It seems to me that there are two common solutions to this type of problem.

• Multi-plexing, which may be the side channel solution.
• Packet data, something like simplified Ethernet over USB.
• Something else

I don't know enough about gpib to offer any opinion on what would be the best solution, or alternative. Being able to read back adapter settings would help with troubleshooting.

[xyphro]

Let me do the following: Implement a mini parser for adapter specific commands.

The requirement is that the pulse indicator request is sent upfront (vendor transfer command as it is right now).

Only after that vendor commands starting with exlamation mark can be executed to configure certain things.

Commands: !? A query which returns a help text explaining available adapter commands. Similar to below text.

!autoid 0 !autoid 1 turns on/off autoid feature and stores this in nvmem. It makes no sense to have a volatile version of this.

!autoid? Returns autoid state (0 or 1)

!term cr !term lf !term eoi Sets the termination for reads

!term? Returns the current cr lf or eoi to indicate read ternination method.

!term store Stores termination setting in nvmem=eeprom

The old syntax !0001 and so on will still be supported and have the same behavior for backwards compatibility.

Any command not starting with exclamation mark will be forwarded as normal instrument command and leave the instrument settings mode which was started with the pulse indicator request.

After that a command starting with exclamation mark would not be ibterpreted as internal command anymore but get transfered to the instrument.

I think that would suit the need and be extendable, right? I will also to extend this command set with some settings coming from a pull request (autoid delay, shorten ressource string option).

Best regards,

Kai

[dazz100]

That looks good to me. The only thing I would suggest is to make the prefix a double character. Maybe !z The reason being that a double char prefix of two low use characters will reduce the probability of being mistaken for some other message. Desirable, not essential.

[xyphro]

The method to prevent a normal gpib command mistaken for a adapter specific command and vice versa is the sending of the pulse indicator request. This should be very safe as normally nobody uses pulse indicator requests.

This means you are still able to send !term? or similar to your actual instrument if you don't send the pulse indicator request beforehand.

[xyphro]

Interim update: Nearly finished the implementation of the mini parser which was required to realize this functionality. Also added a command to read the firmware version (!ver?). Working towards a release still this year. Hope I will manage :-)

[xyphro]

So here we go... TestAndMeasurement_Dazz100_Extensions.zip

Much more as you wanted :-)

Can you give it a try?

Here all commands which are supported:

## General comments:
# Every "internal command" has to be started with this command:
#    dev.control_in(0xa1, 0x40, 0, 0, 1); 
# Without this command, the writes will be sent directly to the connected instrument.
# Also when executing multiple internal commands after each other, every new command
# has to be started again with above snippet.
#
# Additional comments:
# -> Commands cannot be concatenated
# -> follow strictly the syntax. Adding e.g. one space too much will not work
# -> The read part of queries is correctly handled, this means it is possible to 
#    read byte by byte, or in one big go all responses.
# -> The old formates like !0000 are also supported and identical in previous behavior,
#    but will not be further documented. The textual format is better, since it is
#    Human readable
#
# Below code is not really intended to be executed linearly... Use it as a 
# "copy and paste snippet database".

###### Read FW version
dev.control_in(0xa1, 0x40, 0, 0, 1); 
print(dev.query('!ver?'))

###### Set AutoID behavior (This setting is stored in eeprom=non volatile memory)
dev.control_in(0xa1, 0x40, 0, 0, 1); # no autoid, the device will just enumerate with GPIB address ID
dev.write('!autoid off')

dev.control_in(0xa1, 0x40, 0, 0, 1); # autoid feature is turned on, so will respond with instrument name
dev.write('!autoid on')

dev.control_in(0xa1, 0x40, 0, 0, 1); # same as on, but with 10s delay added -> will lead to slower appearance of device on PC
dev.write('!autoid slow')

dev.control_in(0xa1, 0x40, 0, 0, 1); # read autoid setting
print(dev.query('!autoid?'))

##### Read termination functions:
dev.control_in(0xa1, 0x40, 0, 0, 1); # set read termination to CR
dev.write('!term cr')

dev.control_in(0xa1, 0x40, 0, 0, 1); # set read termination to LF
dev.write('!term lf')

dev.control_in(0xa1, 0x40, 0, 0, 1); # set read termination to EOI only
dev.write('!term eoi')

dev.control_in(0xa1, 0x40, 0, 0, 1); # Save readtermination setting in eeprom (non volatile)
dev.write('!term store')

dev.control_in(0xa1, 0x40, 0, 0, 1); # Query termination setting from device
print(dev.query('!term?'))

##### Set length of ressource string (=USB device serial number). This is a non-volatile setting
dev.control_in(0xa1, 0x40, 0, 0, 1); # Set string length limit (28 characters)
dev.write('!string short')

dev.control_in(0xa1, 0x40, 0, 0, 1); # Disable string length limit
dev.write('!string normal')

dev.control_in(0xa1, 0x40, 0, 0, 1); # Query current setting
print(dev.query('!string?'))

##### Reset the adapter (similar in behavior to unplug and plug in again):
dev.control_in(0xa1, 0x40, 0, 0, 1); 
dev.write('!reset')

[dazz100]

OK Thanks for your work on this.

I will try these out, but it is likely to take me a while before I can provide meaningful feedback. At present I am trying to control a WaveTek 2520 RF Signal Generator https://www.eevblog.com/forum/repair/wavetek-2025a-0-2-2-200mghz-rf-sig-gen-repair/. It is old and has a hand-built feel about it. I am having problems with the GPIB interface. The Wavetek interface is proving to be quirky and unreliable. Code runs, and then it doesn't. There is no evidence of any issue with the usb-gpib adapter.

The problem is that I can test your TestAndMeasurement_Dazz100_Extensions.hex code, but I may not be able to identify if a bug is within the WaveTek or usb-gpib firmware. I have other gpib test equipment but I'd rather finish with the WaveTek before moving to the next instrument.

I noticed in the Git download there are two versions of TestAndMeasurementReleaseCandidate.bin and TestAndMeasurement.bin.
Which version should people use?

Also it would be desirable if you could include both .hex and .bin files. I prefer .hex files because they are almost human readable and the file format includes error detection.

So, I will try and test the firmware and I will try and provide meaningful feedback, but it will probably take more time than desirable. I suggest others also try the Dazz100 firmware to test it better than I can.

Please keep up the good work.

[xyphro]

Hi dazz100,

I will soon release a new firnware with the new changes and delete the old ones.

In general: TestAndMeasurementReleaseCandidate.bin

Is the one with speed up, so the latest official. The other one is simply the previous version.

Will check the eev thread. In case you want me to crosscheck something let me know.

Best regards,

Kai

[xyphro]

Hi Dazz100,

I tested this addition extensively and are confident that it is good. Will push it in a few minutes to the repo and close this.

Thanks for your good suggestion!

Best regards,

Kai