Here is a Device file for the HP 53131A Universal Counter. A few screen shots are attached.
Some notes:
- This was developed with TC version 2.34, using a Prologix GPIB-Ethernet adapter.
- While some 20 measurement modes are supported, not all have been thoroughly tested. So bugs no doubt remain to be found.
- Support for the 3rd channel is hard-coded. It should really be conditioned on the response to the *OPT? query, but that is not yet done.
I checked the code and you are correct, it is not possible.
The documentation only descibes local and global vars, but there is a third option: A script can be declared (in my code, not in scripting) as a child of another script and this means it will have access to the variables. The variable names is seached with local first, then parent scripts, then global and stops on first match. This is used in TC, but not everywhere.
To create a global variable it must be declared with globalvar, that works in the same way as var.
Generally globalvar is not supposed to be used in any device definition, because then only one instance of that device can be connected at a time.
I accepted defeat and resorted to using a selector with controls that are always enabled or always disabled. It's probably not as elegant but it solves the problem.
;----- OPERATION STATE CONTROLS (RUN/PAUSE/STOP)
#cmdSetup info Operation_State
:read: OPER:STAT?
#cmdSetup selector Operation_State
:read: OPER:STAT?
:string:
STOP Run_Allow. Pause_NAllow. Stop_NAllow.
RUN Run_NAllow. Pause_Allow. Stop_NAllow.
PAUSE Run_Allow. Pause_NAllow. Stop_Allow.
#cmdSetup button Run Run_Allow
:write: OPER:SET "011"
:update: Operation_State
:enable 1
#cmdSetup button Run Run_NAllow
:write: OPER:SET "011"
:update: Operation_State
:enable: 0
#cmdSetup button Pause Pause_Allow
:write: OPER:SET "051"
:update: Operation_State
:enable: 1
#cmdSetup button Pause Pause_NAllow
:write: OPER:SET "051"
:update: Operation_State
:enable: 0
#cmdSetup button Stop Stop_Allow
:write: OPER:SET "021"
:update: Operation_State
:enable: 1
#cmdSetup button Stop Stop_NAllow
:write: OPER:SET "021"
:update: Operation_State
:enable: 0
I'm having a separate issue with #cmdSetup combobox as well unfortunately.
I can see in the debug output that the defined combobox controls are outputting the correct values, and the correct values are being read by TC, but the combobox always displays the first option in the list after reading back, even if the value shows something else in the debug output.
Is this because I'm using them to set/read a numeric value?
If I replace the combobox with a #cmdSetup number control, that reads back correctly without issue.
I accepted defeat and resorted to using a selector with controls that are always enabled or always disabled. It's probably not as elegant but it solves the problem.
Not as elegant when you want the controls shown.
I am working on adding vars for the info control.
I'm having a separate issue with #cmdSetup combobox as well unfortunately.
I can see in the debug output that the defined combobox controls are outputting the correct values, and the correct values are being read by TC, but the combobox always displays the first option in the list after reading back, even if the value shows something else in the debug output.
Is this because I'm using them to set/read a numeric value?
If I replace the combobox with a #cmdSetup number control, that reads back correctly without issue.
A combobox will compare strings, i.e. 1 1. and 1.0 are 3 different values, a number control will see then as the same value.
Not as elegant when you want the controls shown.
I am working on adding vars for the info control.
The controls were defined so that they are always appear to be visible, but in fact the selector changes between pages, each page with its own version of the control that may be :enable: 0 or :enable: 1 as needed.
A combobox will compare strings, i.e. 1 1. and 1.0 are 3 different values, a number control will see then as the same value.
I suspected that was the case, but was led astray by the debug output.
The debug output was indicating they were being read in as single digit strings without a decimal. I've just swapped a :readformat: for a :readmath: that typecasts as int and that solves it. Thanks!
Just before you replied I had devised the formulas to convert from number to display as string, and then to take the displayed string and convert back to number, which was a challenging but nonetheless interesting exercise!
Just before you replied I had devised the formulas to convert from number to display as string, and then to take the displayed string and convert back to number, which was a challenging but nonetheless interesting exercise!
There are functions to do that, they give you many more possibilities that the automatic typecase.
Another query:
I've tried to use the #cmdSetup multi as part of a #cmdSetup set. Reading values in works fine with suitable :readmath: or :readformat: tags, but when I transmit the values with the #cmdSetup set, it always transmits the :write: parameter for the multi as a literal string - my :write: tags contain formulas to convert values into suitable data packets.
I've tried wrapping it with brackets, quotes, and combinations of, but it always transmits the :write: tag as a literal string. Can this be done or am I pushing the limits?
It's not vital that it works as a multi, but would just allow me a bit more flexibility in tidying up the layout of the Setup dialogue.
Sample below:
#scpiCmd SET:MODE? txrxn? 31 "@0122" / 5h2 7h1 8h2 10h2 12h2 14h2 16h1 17h2/10 19h2/10 21h2/10 23h2/10 25h1
#scpiCmd SET:MODE txrxn 12 "@0112" (value) / 5h2
#cmdSetup multi Start_Time Mode_Settings
:read: SET:MODE?
:readmath: getElement(value,2) + " " + getElement(value,3) + " " + getElement(value,4) + " " + getElement(value,5)
:write: ("(bytesAsHex(hex(round(#),2))) (bytesAsHex(hex(round(#),2))) (bytesAsHex(hex(round(#),2))) (bytesAsHex(hex(round(#),2)))")
number hrs _ 0 23
number mins _ 0 59
number Month _ 1 12
number Date _ 1 31
#cmdSetup set Update_Mode_Settings Mode_Settings
:write: SET:MODE
:update: Mode_Settings.Operation_Mode_Test
Mode_Settings.Link/Pattern_Number_Execution Mode_Settings.Operation_Mode Mode_Settings.Start_Time Mode_Settings.Power_Recovery_Mode Mode_Settings.Wait_Temperature_Neg Mode_Settings.Wait_Temperature_Pos Mode_Settings.Wait_Humidity_Neg Mode_Settings.Wait_Humidity_Pos Mode_Settings.Running_At_End
\x20
Tx <SET:MODE 0x30 0x39 0x30 ("(bytesAsHex(hex(round(9),2))) (bytesAsHex(hex(round(54),2))) (bytesAsHex(hex(round(12),2))) (bytesAsHex(hex(round(5),2)))") 0x30 0x30 0x41 0x30 0x41 0x31 0x39 0x31 0x39 0x30>
I've tried to use the #cmdSetup multi as part of a #cmdSetup set. Reading values in works fine with suitable :readmath: or :readformat: tags, but when I transmit the values with the #cmdSetup set, it always transmits the :write: parameter for the multi as a literal string - my :write: tags contain formulas to convert values into suitable data packets.
I've tried wrapping it with brackets, quotes, and combinations of, but it always transmits the :write: tag as a literal string. Can this be done or am I pushing the limits?
:write: ("(bytesAsHex(hex(round(#),2))) (bytesAsHex(hex(round(#),2))) (bytesAsHex(hex(round(#),2))) (bytesAsHex(hex(round(#),2)))")
I am not sure exactly what you are doing, but your write line do not make sense.
Something like this will probably work better:
:write: ((bytesAsHex(hex(round(#),2))) +bytesAsHex(hex(round(#),2))) +(bytesAsHex(hex(round(#),2))) +(bytesAsHex(hex(round(#),2))))
I have removed the quotes and made it into a real expression by adding + between the elements.
HJK,
Here are some instrument device driver file updates and some new instrument device driver files to include in the next TestController release.
Updated Driver Files: Keithley 2260B Power Supplies.txt
Tested equivalent GW Intek supply and fixed typos in GW Instek #idstrings
GW-Instek ASR-2000.txt
Updated file for faster logging and added interface commands
Ametek 600-1.4.txt
Minor updates and added interface commands
Owon ODP6033.txt
Minor update
Yokogawa Power Analyzer.txt
Yokogawa power analyzers can't be all put into one file. So, for this file changed the file name.
Please delete this file from from future releases. See New Driver Files section for replacement file.
New Driver Files: Yokogawa WT3000 Power Analyzer.txt
This is just a file name change on existing "Yokogawa Power Analyzer.txt" driver file.
Yokogawa WT5000 Power Analyzer.txt
Newer Yokogawa power analyzer. Uses different comm, commands than WT3000 hence a different file.
Vitrek PA900.txt
Power analyzer
Hioki PW6001.txt
Power Analyzer
Vitrek V7x.tx
Hipot safety tester family
Sorensen DCS DC Supply.txt
Power supply family
Owon TAO3104.txt
Tablet oscilloscope
HKJ,
I was able to test the Racal-Dana 1998-1999 definition fie I submitted
here, two pages back with an original Prologix GPIB-USB adapter.
I made some minor adjustments to the definition file, so could you please re-download it?
Of coarse the definition file also worked with the Prologix. But I was surprised to find that there were differences in speed, With the Prologix I could log a bit faster.
The most surprising thing was that when I registered the AR488 in TestController as a Prologix it also worked a bit faster. (But not as much as the original Prologix.)
Regards, Gertjan.
I was able to test the Racal-Dana 1998-1999 definition fie I submitted here, two pages back with an original Prologix GPIB-USB adapter.
I made some minor adjustments to the definition file, so could you please re-download it?
When you make a updated version it is easeast for me if you just post it in a new post.
Of coarse the definition file also worked with the Prologix. But I was surprised to find that there were differences in speed, With the Prologix I could log a bit faster.
The most surprising thing was that when I registered the AR488 in TestController as a Prologix it also worked a bit faster. (But not as much as the original Prologix.)
I probably use slightly different commands to control read/write.
Each GPIB driver can also switch GPIB parameters between devices, but due to a softwaren fault multiple devices on the same GPIB controller do not work yet.
I will add a thanks for all the new/updated drivers from all 3 people, I have added them to TC.
Except Vitrek V7x, it looks like it only have the connection and nothing else.
HJK,
You are correct that Vitrek Hipot tester is only communications. I am not sure it makes sense to log data from this device??? The intent is that it would be automated via a script which only requires communications working.
However, it should have a Setup popup. I will also re-think what data might be worth logging beyond Pass/Fail. I will re-submit once I have that complete.
You are correct that Vitrek Hipot tester is only communications. I am not sure it makes sense to log data from this device??? The intent is that it would be automated via a script which only requires communications working.
However, it should have a Setup popup. I will also re-think what data might be worth logging beyond Pass/Fail. I will re-submit once I have that complete.
I would like voltage and leak current logged.
A setup popup will allow you to control it from popups.
Hi HKJ,
Does the Modbus driver support streaming data, in the same manner as the Block and AsciiBlock drivers?
Does the Modbus driver support streaming data, in the same manner as the Block and AsciiBlock drivers?
No, the MODBUS protocol always works with a command and a answer.
Hi HKJ,
Please find attached a device definition file to suit B&K Precision 9115, 9116, and 9117 DC power supplies.
I have a handful of other, much more complicated definitions in the works but would like to make sure they are a bit more polished before submitting.
Hi HKJ,
Please find attached a device definition file to suit B&K Precision 9115, 9116, and 9117 DC power supplies.
I have a handful of other, much more complicated definitions in the works but would like to make sure they are a bit more polished before submitting.
Thanks, it will be included in the next release.
HKJ is there any detention for SDS2104X plus scope, There is SiglentSDSxxxxxx.txt file, it did not support the scope, So I have just added these lines to it
#metadef
#author MikeLud
#idString Siglent Technologies,SDS2104X Plus,
#name Siglent SDS2104X
#handle SDS2104X
#replaceText AV C1:PAVA? RMS;C2:PAVA? RMS;C3:PAVA? RMS;C4:PAVA? RMS;C1:PAVA? PKPK;C2:PAVA? PKPK;C3:PAVA? PKPK;C4:PAVA? PKPK
But it seems it makes the software very lagy and also some times it freezes the software.
HKJ is there any detention for SDS2104X plus scope, There is SiglentSDSxxxxxx.txt file, it did not support the scope, So I have just added these lines to it
#metadef
#author MikeLud
#idString Siglent Technologies,SDS2104X Plus,
#name Siglent SDS2104X
#handle SDS2104X
#replaceText AV C1:PAVA? RMS;C2:PAVA? RMS;C3:PAVA? RMS;C4:PAVA? RMS;C1:PAVA? PKPK;C2:PAVA? PKPK;C3:PAVA? PKPK;C4:PAVA? PKPK
But it seems it makes the software very lagy and also some times it freezes the software.
I have not checked it, but replacing AV with lots of AV will probabaly do a lot of damage to the generated file.
Thanks HKJ, Do you have a config file for SDS2104X plus scopes?
"Hello, I would also like to control the old DMM Advantest R6551. Does anyone happen to have a configuration file for it? If not, could someone at least recommend a suitable template from the existing ones? The device has only GPIB interface, and the link to its manual is provided here:
Ivo
The command structure of the HP3478A is roughly similar to that of the Advantest R6551, so you might find some general ideas in the Device File for the HP3478A, which uses the "ASCII" driver of TestController.
Thank you! I am planning to connect the Advantest with AR488 interface. Do you expect any troubles?
Thank you! I am planning to connect the Advantest with AR488 interface. Do you expect any troubles?
The "ASCII" driver mentioned above does not refer to the connection type, but rather to the command format used by the device in question. So you can have an "ASCII" device with a GPIB connection like the AR488 or Prologix and that works fine.
Good luck.