Program that can log/control many multimeters and other devices.

[KungFuJosh]

I generally leave my meters set a certain way, and I don't want those settings changed.....

A good definition should take into account all kinds of users, and offer optimum support for all use cases. Not please the specific preferences of a single user.

I completely agree with you; but which one of us is the single user being pleased?

The point of posting this as a discussion is to see where others stand. Your workaround might be good, but might be unnecessary for anybody else. I don't know a single person that wants to lose their customizations or calibration.

For me, I won't update the definition file from future versions released with TC. If something of value is added, I'll merge it.

This is one of the many areas where I prefer my Keithley DAQ. The autoexec script that runs at startup sets everything the way I want it, so nothing TC does during testing matters. The SDM doesn't have that, and it remembers the last state, no matter how it's set.

Thanks,
Josh

[KungFuJosh]

ETA: 2 other things that annoy me that *RST changes: 1. it disables the screen save, and 2. it disables statistics. I don't want those changed either.

You know it is very easy to generate a configuration script in TC, at least if the settings is in the setup menus.

Two steps:
1) Use menu to configure the meter
2) Right click in log window and select "Generate script, Mode and setup", the script can be saved as a menu item and will perform the commands you just did.

I do know, but simply removing *RST from the definition file solves all problems for me. It would take significantly more effort to set everything as I want instead.

Speaking of the script generation, there seems to be an issue. I had all meters set to SI7, but when I call the script, that's lost and it looks like the attached screenshot instead. Then I need to manually set each meter to SI7 again in the Current Values tab. It appears the generated script doesn't store Format info at all. Is there a way to fix that?

The 16-Hour test screenshot is how TC was setup before generating the script.

Thanks,
Josh

[HKJ]

Speaking of the script generation, there seems to be an issue. I had all meters set to SI7, but when I call the script, that's lost and it looks like the attached screenshot instead. Then I need to manually set each meter to SI7 again in the Current Values tab. It appears the generated script doesn't store Format info at all. Is there a way to fix that?

Try using the menu option: "Value formats"
It will generate a lit of the current formats and that can be included in the script (You have to do a bit of editing yourself to combine them).

[KungFuJosh]

Speaking of the script generation, there seems to be an issue. I had all meters set to SI7, but when I call the script, that's lost and it looks like the attached screenshot instead. Then I need to manually set each meter to SI7 again in the Current Values tab. It appears the generated script doesn't store Format info at all. Is there a way to fix that?

Try using the menu option: "Value formats"
It will generate a lit of the current formats and that can be included in the script (You have to do a bit of editing yourself to combine them).

Thanks, I added this after the scale section:
#ValueFormat AG34410A.VoltageDC SI7
#ValueFormat DAQ6510.VoltageDC SI7
#ValueFormat K34465.VoltageDC SI7
#ValueFormat SDM3065X.VoltageDC SI7

I assume that's good enough? I'll test it out after the next long test is done.

ETA: That worked, thanks.

Thanks,
Josh

[HKJ]

Thanks, I added this after the scale section:
#ValueFormat AG34410A.VoltageDC SI7
#ValueFormat DAQ6510.VoltageDC SI7
#ValueFormat K34465.VoltageDC SI7
#ValueFormat SDM3065X.VoltageDC SI7

I assume that's good enough? I'll test it out after the next long test is done.

ETA: That worked, thanks.

Generate layout only saves layout, not settings, but there are commands to set just about anything in TC and most of it can be generated from the script menu.
For people that like to read documentation there is a list of all script commands here: https://lygte-info.dk/project/TestControllerScriptCommands%20UK.html, they will also be shown in the help window and the text there is similar to the webpage.

[KungFuJosh]

Here's an updated definition for the 34410A/11A meters (a few minor edits).

I've also attached my version of the SDM3000X definition. If you review the notes, you can see Scott attempted to remove *rst from the file a year ago. I don't know who put it back in? Anyway, I think it's clear I'm not the only one who dislikes *rst being included. I made a couple other modifications, noted in the file.

Thanks,
Josh

ETA: Outdated 3441XA driver removed.

[HKJ]

Here's an updated definition for the 34410A/11A meters (a few minor edits).

I've also attached my version of the SDM3000X definition. If you review the notes, you can see Scott attempted to remove *rst from the file a year ago. I don't know who put it back in? Anyway, I think it's clear I'm not the only one who dislikes *rst being included. I made a couple other modifications, noted in the file.

I have put your two files in.
Generally I like device to be reset to power on state, but it sounds like the *rst has some undesirable effects.

[KungFuJosh]

I'm working on the definition for my DAQ6510. I don't like what *RST does there either, but there's a much better option:
#finalCmd *CLS;SCR:RUN "autoexec";:TRIG:CONT REST

That executes the autoexec script, and then resets the trigger to continuous. That's exactly how the meter starts up, without anything destructive happening.

Thanks,
Josh

[Gertjan]

Hi HKJ,

Here is an updated version of the HP / Agilent 3458A definition.


IMG_4616__Agilent_3458A_10VDC-2000pix.jpg

Most relevant improvements:
- Much shorter connect time when starting TC / Reconnecting devices.
- Improved / more ergonomic mode Menu.
- Improved "Delay" settings in Setup Menu (now also "return to automatic (default) value".)
- Added "Delay" function to DCV setup menu.

The long connect time is interesting, because it highlighted a possible shortcoming in the way TC is initially connecting to devices.

I found that the long connect time was due to time outs after the initial ID request.
When trying to connect, TC is sending just the ID request string to the meter, and only afterwards, when fully connecting to the meter, it sends the init string(s)
Probably fine with most SCPI meters to get a *idn? answer. But for GPIB there are initial settings like EOI handling etc. This meter also needs "Suspend readings" and "Enable input buffer" to get quick and reliable answers.

For now I solved it by adding the necessary init commands to the ID? string.
But would it not be better to send the #initCmd string to the device before asking it's ID by default?

Please find the updated definition file here: AgilentHP3458A.zip

regards, Gertjan.

[KungFuJosh]

Here's an updated version of the 34410A / 34411A definition. Lots of updates and correction of manual ranges. Hopefully, this is the final version for now.

Thanks,
Josh

[KungFuJosh]

Does SCPIx not work with LXI/VXI?

I have the DAQ6510 driver mostly done (and it will cover DMM6500 and DMM7510 also with better control/features).

To enable the Digitize VorI options, I added a #pgm# with conditional logic to set the askmode/askvalues stuff. It all works fine, but all the regular commands get a null response with VXI or LXI mode active, so I removed that and limited it to socket.

Thanks,
Josh

[KungFuJosh]

I don't know if this is the final version or not, but if anybody wants to try it, it should work with the DAQ6510, DMM6500, and DMM7510.

The only change I made for the DMM7510 was to increase the value digits from SI7 to SI8. If there's something else that should be adjusted, let me know.

Please let me know if you find any issues.

Thanks,
Josh

ETA: Replaced file with new version 1.3.

ETA2: Outdated file removed.

[HKJ]

I'm working on the definition for my DAQ6510. I don't like what *RST does there either, but there's a much better option:
#finalCmd *CLS;SCR:RUN "autoexec";:TRIG:CONT REST

That executes the autoexec script, and then resets the trigger to continuous. That's exactly how the meter starts up, without anything destructive happening.

That gets an error on my DMM6500, I do not have a autoexec file, maybe it is because my firmware is some years old.

[HKJ]

Here is an updated version of the HP / Agilent 3458A definition

Thanks, I have updated the definition.

But would it not be better to send the #initCmd string to the device before asking it's ID by default?

Definitely not, the *idn? is used to identify a unknown device (sometimes) and I do not what to send strange commands to a device.

[HKJ]

Here's an updated version of the 34410A / 34411A definition. Lots of updates and correction of manual ranges. Hopefully, this is the final version for now.

Thanks, it is updated.

[HKJ]

Does SCPIx not work with LXI/VXI?

I have the DAQ6510 driver mostly done (and it will cover DMM6500 and DMM7510 also with better control/features).

To enable the Digitize VorI options, I added a #pgm# with conditional logic to set the askmode/askvalues stuff. It all works fine, but all the regular commands get a null response with VXI or LXI mode active, so I removed that and limited it to socket.

Strange, I will have to investigate that.
The comm driver has nothing to do with the device driver, except a limited interface where they communicate with each other.

[HKJ]

I don't know if this is the final version or not, but if anybody wants to try it, it should work with the DAQ6510, DMM6500, and DMM7510.

The only change I made for the DMM7510 was to increase the value digits from SI7 to SI8. If there's something else that should be adjusted, let me know.

Please let me know if you find any issues.

ETA: Replaced file with new version 1.3.

I have added it and removed the old drivers, thanks.

[Gertjan]

But would it not be better to send the #initCmd string to the device before asking it's ID by default?

Definitely not, the *idn? is used to identify a unknown device (sometimes) and I do not what to send strange commands to a device.

Strange commands?

It is just sending the  #initCmd before the #verifyDevice. Both from the same definition file, specially written for the device.
Probably this is mostly applicable for devices with ASCII driver definition.

regards, Gertjan.

[Hydron]

HKJ, any estimate on when the next release will be? I've got a few half-done drivers (Advantest R6581T, Keithley 617) that I could try and finish in the next week or so.

R6581T driver is mostly based on the 34401A layout, but I need to figure out how the triggering works (Japanese manual makes things harder!), and I'll probably not implement the ACV/ACI/Freq functions as the T/D models don't have these (could be added by someone else as a meta def thing though). K617 is based off the K199 driver, but right now I've managed to break the "setup" dialogue layout and have to fix it before I can submit.

Also on my to-do list are drivers for the K236/7/8 SMUs (probably quite a bit more work as they are complicated and use stupid "R2D2" ASCII language instead of SCPI) and an dingcheng electronic load that will also be a bit annoying (due to the way it's mode selection state machine works) - wouldn't wait up for these though!

[HKJ]

Strange commands?

It is just sending the  #initCmd before the #verifyDevice. Both from the same definition file, specially written for the device.
Probably this is mostly applicable for devices with ASCII driver definition.

Yes, strange commands. Search socket and scan serial port uses *idn? to identify a unknown the device, i.e. it will be the first command.

[HKJ]

HKJ, any estimate on when the next release will be? I've got a few half-done drivers (Advantest R6581T, Keithley 617) that I could try and finish in the next week or so.

R6581T driver is mostly based on the 34401A layout, but I need to figure out how the triggering works (Japanese manual makes things harder!), and I'll probably not implement the ACV/ACI/Freq functions as the T/D models don't have these (could be added by someone else as a meta def thing though). K617 is based off the K199 driver, but right now I've managed to break the "setup" dialogue layout and have to fix it before I can submit.

Also on my to-do list are drivers for the K236/7/8 SMUs (probably quite a bit more work as they are complicated and use stupid "R2D2" ASCII language instead of SCPI) and an dingcheng electronic load that will also be a bit annoying (due to the way it's mode selection state machine works) - wouldn't wait up for these though!

I do not have any fixed schedule, but I am thinking of soon. I can wait a week.

[KungFuJosh]

I'm working on the definition for my DAQ6510. I don't like what *RST does there either, but there's a much better option:
#finalCmd *CLS;SCR:RUN "autoexec";:TRIG:CONT REST

That executes the autoexec script, and then resets the trigger to continuous. That's exactly how the meter starts up, without anything destructive happening.

That gets an error on my DMM6500, I do not have a autoexec file, maybe it is because my firmware is some years old.

Interesting. I think you would have to make an autoexec file manually anyway? I dunno if they have them by default or not. I will see if there's anything that can be added to check for the script or not. Otherwise, I'll add a note regarding that.

autoexec scripts are great. You can save all your preferred defaults (NPLC, counts, digits, etc.) and have the meter start that way each power up.

I like it better than my other meters that do stuff like remembering the last power off state. With the autoexec, I don't have to pay attention to anything, it will always start up correctly.

Thanks,
Josh

[KungFuJosh]

Here's probably the final (assuming no issues), version 1.5. I added a note about the final command, and some additional features that were requested.

Thanks,
Josh

[HKJ]

Here's probably the final (assuming no issues), version 1.5. I added a note about the final command, and some additional features that were requested.

I have added it.

[KungFuJosh]

Does SCPIx not work with LXI/VXI?

I have the DAQ6510 driver mostly done (and it will cover DMM6500 and DMM7510 also with better control/features).

To enable the Digitize VorI options, I added a #pgm# with conditional logic to set the askmode/askvalues stuff. It all works fine, but all the regular commands get a null response with VXI or LXI mode active, so I removed that and limited it to socket.

Strange, I will have to investigate that.
The comm driver has nothing to do with the device driver, except a limited interface where they communicate with each other.

Yeah, it was weird and unexpected. Originally the driver had LXI, which worked but slowly. Then I switched to VXI and it was much faster. Once I added the SCPIx driver, everything had null responses until I forced socket only. It works fine as socket, but the issue is odd.

Thanks,
Josh