Program that can log from many multimeters.

[ali_asadzadeh]

Thanks HKJ for the feedback,

Add a
#eol \r\n
to the definition

I'm new to your software, where should I add this, would you explain more?

[nicocorradini]

Hi! Can anybody help me? I'm trying to connect a ProsKit MT-1820 to TestController under macOS (Ventura). System Information shows it as "CP2102 USB to UART Bridge Controller", and when I type ls -al /dev in Terminal, it shows as "cu.usbserial-0001".

Got no idea what to do! 

EDIT: Finally figured out how to make it work, and now is fully functional! For those in the same situation:

1) Install CP201 drivers for Mac: https://www.silabs.com/documents/public/software/Mac_OSX_VCP_Driver.zip
2) Restart your Mac, connect your MT-1820 and press the "RS232" button until display shows it
3) Open TestController
4) Go to Load Devices, select ProsKit MT-1820 in the bottom, click Add, and in Address write tty.SLAB_USBtoUART
5) Click Reconnect and voila!

[HKJ]

Thanks HKJ for the feedback,

Add a
#eol \r\n
to the definition

I'm new to your software, where should I add this, would you explain more?

Somewhere in the definition file.

[ali_asadzadeh]

Somewhere in the definition file.

Would you please tell me exactly where in GPP4323 Definition file? thanks

[Hexley]

Somewhere in the definition file.

Would you please tell me exactly where in GPP4323 Definition file? thanks

Some results from the bench on how I established a serial connection to the GPP-4323 just now:

First, configure the GPP-4323 for the desired serial parameters, using pp 99-100 of the manual for reference:

• System->F1->F1->Fn. This selects the serial interface and brings you to the baud rate choice.
• I used 9600 baud, which was "F1" for the "Fn" shown above.
• F6-->F6->F6 to return to the home screen..

Then perform the following steps:

• Connect an RS-232-to-USB adapter to the PC.
• Connect a null modem between the two male 9-pin connectors.
• Start TestController with the Scan Serial Ports box checked. (Put COM3 in the list of ports to skip, as this is an internal management interface of the PC itself.)
• TC should discover the GPP-4323 and display something like this:

Code: [Select]

;; jSerialComm version: 2.9.1
;; Start thread for: COM6 - GWInstek GPP-4323
;; COM6: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; COM6: Rx: <GW Instek,GPP-4323,SN:GET852000,V1.19> 47 57 20 49 6E 73 74 65 6B 2C 47 50 50 2D 34 33 32 33 2C 53 4E 3A 47 45 54 38 35 32 30 30 30 2C 56 31 2E 31 39
;; Found GWInstek GPP-4323 on USB-Serial Controller D (COM6) sn: SN:GET852000


• You may need to change the baud rate of the GPP-4323 to match the serial port, or vice versa.

No need to add anything about #eol to the Device file; it works fine as is, as can be seen in the code listing above.

I hope this helps.

[mawyatt]

Somewhere in the definition file.

Would you please tell me exactly where in GPP4323 Definition file? thanks

Some results from the bench on how I established a serial connection to the GPP-4323 just now:

First, configure the GPP-4323 for the desired serial parameters, using pp 99-100 of the manual for reference:

• System->F1->F1->Fn. This selects the serial interface and brings you to the baud rate choice.
• I used 9600 baud, which was "F1" for the "Fn" shown above.
• F6-->F6->F6 to return to the home screen..

Then perform the following steps:

• Connect an RS-232-to-USB adapter to the PC.
• Connect a null modem between the two male 9-pin connectors.
• Start TestController with the Scan Serial Ports box checked. (Put COM3 in the list of ports to skip, as this is an internal management interface of the PC itself.)
• TC should discover the GPP-4323 and display something like this:

Code: [Select]

;; jSerialComm version: 2.9.1
;; Start thread for: COM6 - GWInstek GPP-4323
;; COM6: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; COM6: Rx: <GW Instek,GPP-4323,SN:GET852000,V1.19> 47 57 20 49 6E 73 74 65 6B 2C 47 50 50 2D 34 33 32 33 2C 53 4E 3A 47 45 54 38 35 32 30 30 30 2C 56 31 2E 31 39
;; Found GWInstek GPP-4323 on USB-Serial Controller D (COM6) sn: SN:GET852000


• You may need to change the baud rate of the GPP-4323 to match the serial port, or vice versa.

No need to add anything about #eol to the Device file; it works fine as is, as can be seen in the code listing above.

I hope this helps.

As you've nicely detailed, we've also been able to connect to the GPP4323 thru the serial port using a cheap USB to RS232 cable/adapter with a NULL MODEM adapter, be sure to set the Baud rate, we just use the common 9600 since we aren't passing lots of data.

This was not thru this software tho, we are using our own Python routines as shown here:

https://www.eevblog.com/forum/testgear/lcr-meter-plot-software/

Best,

[ali_asadzadeh]

Hexley and mawyatt thanks for the feedback, If you check a few pages back,I told that I have used the USB connection of my GPP-4323 and I do not have or want to use a separate USB to RS232, also in there I was able to connect to it with a normal terminal program, the TC program just do not send \r\n for the USB connection and that's the reason it can not find it there.The TC program just needs a simple update I guess.

[Hexley]

No need to add anything about #eol to the Device file; it works fine as is, as can be seen in the code listing above.
I hope this helps.

Let me try to help one more time.

To connect the GPP-4323 to TestController via USB:
First, download and install the GW Instek USB driver for the GPP-4323. This is mentioned in page 100 of the manual, and may be found in the Downloads section of the GPP-4323 product page on the Instek web site. This link may work, though registration may be required: https://www.gwinstek.com/en-GB/products/downloadSeriesDownNew/14679/1742.

Second, configure the GPP-4323 for USB control. See pages 100-101 of the manual. In summary, it is System->F1->F2->Fn to select the USB interface, where Fn selects the baud rate. As before, I used "F1" for "Fn" in order to choose 9600 baud. When done, press F6 three times to return to the main menu.

Third, power down the GPP-4323, connect the GPP-4323 to the PC with a USB cable, then power up again.

Fourth, Start TestController with the Scan Serial Ports box checked.   (Put COM3 in the list of ports to skip, as this is an internal management interface of the PC itself.)

Now TC should discover the GPP-4323 and display something like this:

Code: [Select]

;; jSerialComm version: 2.9.1
;; Start thread for: COM7
;; COM7: Set params: 9600
;; COM7: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; COM7: Rx: <GW Instek,GPP-4323,SN:GET852000,V1.19> 47 57 20 49 6E 73 74 65 6B 2C 47 50 50 2D 34 33 32 33 2C 53 4E 3A 47 45 54 38 35 32 30 30 30 2C 56 31 2E 31 39
;; Found GWInstek GPP-4323 on USB2.0-Serial (COM7) sn: SN:GET852000

NOTES AND COMMENTS

• It appears that Instek uses a USB serial interface that is not automatically supported by some PCs (yours and mine, at least). Hence they have to supply a driver.
• However, the terminal emulator that you used for testing must have a suitable driver built in. Interesting.
• The command terminator for the GPP-4323 is <new line>. To quote the manual, "A command can also be terminated using a carriage return + <new line> character." See page 112, Command Terminators. So there is no need for TC to send anything different that what it is sending, as can be seen in the code above and in the example provided previously. An extra carriage return won't hurt, but it is not required.

The steps shown above are what I did just now to connect my GPP-4323 to TestController via USB. If you have already done them and are still having errors, perhaps it would be good to uninstall as much as possible and start over with a fresh installation.

I hope this helps.
Good luck.

[mawyatt]

That special driver works for the GPP-4323 under direct USB control!!

Interestingly, that's the only special USB driver we've needed, all our other TE and USB-RS232 cable/adapters work with Windows 10, without any additional driver(s).

Thanks,

Best,

[ali_asadzadeh]

Thanks Hexley for the update, I have changed the USB baud rate to 9600 and it works, every other baud rate it does not work, But I can still use a separate terminal program to control it with higher baud rates by inputting SCPI commands by hand, also I have to modify the GWInstek GPP-4323.txt to be able to connect to TC program

I have changed #idString GW INSTEK,GPP-4323, to  #idString GW Instek,GPP-4323,SN:GEW895373,V1.19

Can you test your USB connection with other baud rates?

[HKJ]

Thanks Hexley for the update, I have changed the USB baud rate to 9600 and it works, every other baud rate it does not work, But I can still use a separate terminal program to control it with higher baud rates by inputting SCPI commands by hand, also I have to modify the GWInstek GPP-4323.txt to be able to connect to TC program

I have changed #idString GW INSTEK,GPP-4323, to  #idString GW Instek,GPP-4323,SN:GEW895373,V1.19

Can you test your USB connection with other baud rates?

Do not include sn and firmware in the idstring, thatwould lock the definition to that specific meter.

[ali_asadzadeh]

Thanks HJK, Why it does not work with other baud rates? (maybe because it does not send \r\n) Also I have connected my Signal gen SDG2042X, But TC software only would allow to use one of the products? Is there a way to use my  GPP4323 power supply  and SDG2042X function gen both at the same time with TC software? if the answer is yes how?

[HKJ]

Thanks HJK, Why it does not work with other baud rates? (maybe because it does not send \r\n) Also I have connected my Signal gen SDG2042X, But TC software only would allow to use one of the products? Is there a way to use my  GPP4323 power supply  and SDG2042X function gen both at the same time with TC software? if the answer is yes how?

Usually there is no problems running multiple devices from TC, it is designed to do that.

[Hexley]

A revised device file for the GW Instek GPP-4323 is available.
This is compatible with the response to "*idn?", which changed in the latest firmware for the GPP-4323 (1.19).

HKJ - It appears that the modified Device File for the GPP-4323 that was submitted back in February was accidentally not included in the current release of TestController. The updated file supported the change to the ID string of the GPP-4323 that Instek made with their latest firmware release.

A fresh copy of that file is attached for your convenience. Please include it in the next release of TC, thanks.

Hexley

[HKJ]

A revised device file for the GW Instek GPP-4323 is available.
This is compatible with the response to "*idn?", which changed in the latest firmware for the GPP-4323 (1.19).

HKJ - It appears that the modified Device File for the GPP-4323 that was submitted back in February was accidentally not included in the current release of TestController. The updated file supported the change to the ID string of the GPP-4323 that Instek made with their latest firmware release.

Probably because there has not been any new releases of TC since. 

[ali_asadzadeh]

Usually there is no problems running multiple devices from TC, it is designed to do that.

How can I do that? Because the when TC connects to more than one equipment the setup button only shows on instrument controls. also the chart and histogram panels are always disabled, Can they be used with a power supply and Function gen too?

[HKJ]

Usually there is no problems running multiple devices from TC, it is designed to do that.

How can I do that? Because the when TC connects to more than one equipment the setup button only shows on instrument controls. also the chart and histogram panels are always disabled, Can they be used with a power supply and Function gen too?

The setup button is only for the selected device, use the button on the left to select another device.
You need to start logging for all panels to be enabled.

You can use any combination of devices you want and if you want to be advanced you can make customized control panels (GridPanel) and save them.

[ali_asadzadeh]

The setup button is only for the selected device, use the button on the left to select another device.

There is no button on the left? which one do you mean?

[Hexley]

A revised device file for the GW Instek GPP-4323 is available.
This is compatible with the response to "*idn?", which changed in the latest firmware for the GPP-4323 (1.19).

HKJ - It appears that the modified Device File for the GPP-4323 that was submitted back in February was accidentally not included in the current release of TestController. The updated file supported the change to the ID string of the GPP-4323 that Instek made with their latest firmware release.

Probably because there has not been any new releases of TC since. 

That would explain it. 

I imagine there must be a few other new or updated device files in the queue as well, since there has been no release of TC for a while. It looks like it would be helpful to allow updating the Device File collection independently of new releases of TC itself.

No doubt you are the best judge of this, but here are a few suggestions to consider:

• Add a link in the TestController downloads area that delivers just the latest Device File collection.
• Have the run time engine phone home to check for new releases of the Device File collection, and provide a user notification if one is ready. Like it does for the engine itself.
• Or add a button to the "Help" section of the TC runtime that reloads the latest collection of Device Files when the user clicks it.
• Finally, consider creating a parallel repository just for crowd-sourced device files. If this could be accessed by some of the methods above, it would effectively remove the burden of maintaining all those files from you. Just a thought.

Thanks for all the hard work you put into TC. It is really appreciated.

[HKJ]

The setup button is only for the selected device, use the button on the left to select another device.

There is no button on the left? which one do you mean?

Ok, it is not really a buttun: Right click on the short device name to the left of the command line.
You can also type the short device name followed by a colon on the command line and press enter.
In the popups there is a shortcut to open all setup menus.

Pressing the F1 key will show some help to most pages/popups in TC. It is using a browser and opening the documentation on my webserver for that page/popup.

[HKJ]

I imagine there must be a few other new or updated device files in the queue as well, since there has been no release of TC for a while. It looks like it would be helpful to allow updating the Device File collection independently of new releases of TC itself.

There is very few updates or new device files and not much change to the TC software either, that is the reason for the long delay in updates.

[jmurray]

Hi HKJ,

I am working on a device definition at present and have observed some curious behaviour.

I have created a setup dialogue box - all the parameters are part of a "#cmdSetup set" control, so updated all at once. This works fine.
Because all the parameters are read from the same defined #scpiCmd, it only issues the defined :read: command once and caches the results. This is great because it's not unnecessarily sending the same command over serial each time.

I have added Run/Pause/Stop buttons to the bottom, and they work fine as well.
I added :enable: tags to the buttons because Pause should only be available when running, Stop only available during Pause, etc.
I am also using a "#cmdSetup info" to display the current "Run/Pause/Stop/etc" state.

Because a "#cmdSetup info" control does not create a variable with its name, I have made its defined #scpiCmd save the result to a variable.
My :enable: tags for the buttons read like this:

Code: [Select]

:enable: inList(deviceRead(handle,"readOperationState?"), "STOP PAUSE")
This works, however for some reason the use of the deviceRead function in the :enable: tag means that when I update the parameters in the "#cmdSetup set", it issues the defined :read: #scpiCmd for each parameter, resulting in the same command/response occuring 11 times over serial, instead of once and caching the response. This appears to visibly slow down the debug output as the last few command/response instances occur.
It still works, but it just seems a bit clunky and would prefer to keep it fast and clean so I can share the finished definition and minimise the chances of any timing issues between instruments.

Is this an oddity in the way the deviceRead function works, or am I missing something?
It seems as though an easier solution would be if the "#cmdSetup info" controls created a variable with their name, but I presume there was a reason for them not to.

Thanks again for all the work you've put into this software. While I am still learning as I go and struggle with the syntax at times, I am definitely finding my way and am very grateful for it!

Relevant lines from the definition are below:

Code: [Select]

#scpiCmd OPER:SET txrxn 13 "@0153" (value)

#scpiCmd OPER:STAT? txrxn? 22 "@0151" / 7h2
:readmath: matchBitsList(value,"00000000","STOP","00000001","RUN","00000011","READY","00000101","WAIT","00010001","HOLD","00100000","END","10000000","PAUSE")
:setvar: Operation_State=value

#scpiCmd readOperationState? none?
:readmath: getVar("Operation_State")

#scpiCmd READ:FIX? txrxn? 37 "@0125" / 5h4 9h4 13h4 17h4 21h4 25h2 27h1 28h1 29h1 30h1 31h1
:readmath: binConv(int(getElement(value,0)),0,2,1)/10.0+" "+binConv(int(getElement(value,1)),0,2,1)/10.0+" "+binConv(int(getElement(value,2)),0,2,1)/10.0+" "+binConv(int(getElement(value,3)),0,2,1)/10.0+" "+getElement(value,4)+" "+getElement(value,5)+" "+getElement(value,6)+" "+getElement(value,7)+" "+getElement(value,8)+" "+getElement(value,9)+" "+getElement(value,10)

#scpiCmd SET:FIX? txrxn? 12 "@0115" (value) / 5h2
:setvar: response=value


#cmdSetup number Temperature
:read: READ:FIX?
:readformat: fxxxxxxxxxx
:write: (bytesAsHex(hex(value*10)))
°C -20 110

#cmdSetup number Humidity
:read: READ:FIX?
:readformat: xfxxxxxxxxx
:write: (bytesAsHex(hex(value*10)))
%RH 0 99.9

#cmdSetup number Temperature_Slope
:read: READ:FIX?
:readformat: xxfxxxxxxxx
:write: (bytesAsHex(hex(value*10)))
°C/min 0 99.9

#cmdSetup number Humidity_Slope
:read: READ:FIX?
:readformat: xxxfxxxxxxx
:write: (bytesAsHex(hex(value*10)))
%RH/min 0 99.9

#cmdSetup number Run_Hours
:read: READ:FIX?
:readformat: xxxxfxxxxxx
:write: (bytesAsHex(hex(round(value),4)))
hrs 0 9999

#cmdSetup number Run_Minutes
:read: READ:FIX?
:readformat: xxxxxfxxxxx
:write: (bytesAsHex(hex(round(value),2)))
mins 0 59

#cmdSetup combobox Time_Mode
:read: READ:FIX?
:readformat: xxxxxxfxxxx
:write: (bytesAsHex(hex(round(value),1)))
Continuous 0
Timer 1

#cmdSetup combobox Wait
:read: READ:FIX?
:readformat: xxxxxxxfxxx
:write: (bytesAsHex(hex(round(value),1)))
Off 0
On 1

#cmdSetup number Time_Signal_1
:read: READ:FIX?
:readformat: xxxxxxxxfxx
:write: (bytesAsHex(hex(round(value),1)))
_ 0 9

#cmdSetup number Time_Signal_2
:read: READ:FIX?
:readformat: xxxxxxxxxfx
:write: (bytesAsHex(hex(round(value),1)))
_ 0 9

#cmdSetup number Time_Signal_3
:read: READ:FIX?
:readformat: xxxxxxxxxxf
:write: (bytesAsHex(hex(round(value),1)))
_ 0 9

#cmdSetup set Fixed_Settings
:write: SET:FIX?
:update: Fix_Settings
Temperature Humidity Temperature_Slope Humidity_Slope Run_Hours Run_Minutes Time_Mode Wait Time_Signal_1 Time_Signal_2 Time_Signal_3
\x20


#cmdSetup info Operation_State
:read: OPER:STAT?

#cmdSetup button Run
:write: OPER:SET "011"
:update: Operation_State
:enable: inList(deviceRead(handle,"readOperationState?"), "STOP PAUSE")

#cmdSetup button Pause
:write: OPER:SET "051"
:update: Operation_State
:enable: deviceRead(handle,"readOperationState?")=="RUN"

#cmdSetup button Stop
:write: OPER:SET "021"
:update: Operation_State
:enable: inList(deviceRead(handle,"readOperationState?"), "PAUSE BREAK END")

[HKJ]

Because a "#cmdSetup info" control does not create a variable with its name, I have made its defined #scpiCmd save the result to a variable.
My :enable: tags for the buttons read like this:

Code: [Select]

:enable: inList(deviceRead(handle,"readOperationState?"), "STOP PAUSE")
This works, however for some reason the use of the deviceRead function in the :enable: tag means that when I update the parameters in the "#cmdSetup set", it issues the defined :read: #scpiCmd for each parameter, resulting in the same command/response occuring 11 times over serial, instead of once and caching the response. This appears to visibly slow down the debug output as the last few command/response instances occur.
It still works, but it just seems a bit clunky and would prefer to keep it fast and clean so I can share the finished definition and minimise the chances of any timing issues between instruments.

DeviceRead clears the cache, this is necessary or it could not be used to get a real time status from the device.
Have you tried if you can access the variable directly (I do not remember if that is possible)?

[jmurray]

DeviceRead clears the cache, this is necessary or it could not be used to get a real time status from the device.
Have you tried if you can access the variable directly (I do not remember if that is possible)?

Ah, that makes sense.

I don't believe it's possible, but there might be a way that I'm unware of.

I've tried setting the :enable: tag as:

Code: [Select]

:enable: inList(Operation_State, "STOP PAUSE")in order to read the variable that the #scpiCmd set, but it throws an exception pointing out that the variable (Operation_State) does not exist.

Presumably variables declared in the definition are a separate local scope to variables within #cmdSetup dialogue. I'm not aware if there is a way to define it as a global variable and read it, but I did see on your Calculator page that:

Local variable (i.e. var declared) have priority over globally declared variables. If the script is called from another script there may exist variables between global and local from the calling script.

I presume that is only relevant in the event that there is a local and global variable with the same name, the function will refer to the local one.

On a whim I tried to :setglobalvar: instead of :setvar:, but that didn't appear to make any difference.

[HKJ]

DeviceRead clears the cache, this is necessary or it could not be used to get a real time status from the device.
Have you tried if you can access the variable directly (I do not remember if that is possible)?

Ah, that makes sense.

I don't believe it's possible, but there might be a way that I'm unware of.

I've tried setting the :enable: tag as:

Code: [Select]

:enable: inList(Operation_State, "STOP PAUSE")in order to read the variable that the #scpiCmd set, but it throws an exception pointing out that the variable (Operation_State) does not exist.

Presumably variables declared in the definition are a separate local scope to variables within #cmdSetup dialogue. I'm not aware if there is a way to define it as a global variable and read it, but I did see on your Calculator page that:

Local variable (i.e. var declared) have priority over globally declared variables. If the script is called from another script there may exist variables between global and local from the calling script.

I presume that is only relevant in the event that there is a local and global variable with the same name, the function will refer to the local one.

On a whim I tried to :setglobalvar: instead of :setvar:, but that didn't appear to make any difference.

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.