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

[HKJ]

I'm working on some tests, and I'm perplexed as to why TC doesn't seem consistent when loading devices on a Prologix Ethernet adapter over a TCP socket. I have 5 devices, and they act erratically when trying to connect to them.

This is a bug that has been in TC always. I tried fixing it for serial attached GPIB adapter when adding MODBUS, but I do not know if it worked.

Based on my tests, yes, it is still there for the Prologx GPIB Ethernet adapter

I remember the serial adapter working better, but that test was a while back.

The emulator software I posted earlier in the thread is based on the Prologox Ethernet adapter, so I can use your great software with USB VISA instruments.
I made that software able to accept multiple socket connections to use the workaround of making it look like each instrument is on its own Prologox Ethernet GPIB adapter.

Based on my testing, each A:2, A:4, A:5, etc starts a thread that tries to talk to the adapter, and it's a race. The results are erratic connectivity and access to the devices.

I never tired fixing the Ethernet GPIB adapter.

I will add links to your project in TC's documentation, it looks very useful.
Do different socket connections get separate thread in your software or is everything handled by one thread?
TC takes a performance hit when using shared adapters, because it can only have one message outstanding at a time on the shared adapter.

[NoDisintegrations]

Reading the output is not the solution, I had not realized that you could not read the set point.

There is a way around that, let the driver keep track of the set value and use that as answer. That will work with TC's verification.

In the set voltage #scpiCmd command add:
:setVar: setVoltage=inputValue;

Then declare a #scpiCmd to read the value:
#scpiCmd getSetVoltage none?
:readmath: setVoltage

You do the same for current.


This is a workaround with the purpose to make the power supply work with all popups and panels in TC
I do explain it for SCPIx, but it is the same for other protocols: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Protocol_is_nearly_SCPI,_but_there_is_a_few_issues_(SCPIx)

Thank you! It's good to know there's a possible workaround!

That said, I've given it a crack, but can't figure out where I'm going wrong.

Testing the changes via the PS Interface Popup yields NaN results with Rx timeouts.
Sending the commands directly via the main window shows a more descriptive "Variable not found setVoltage" UnknownException in the logs.

I've also tried changing the intermediate variables' names from setVoltage to setVoltageShadow, to differentiate them from the name setVoltage which is being used for the scpiCmd, but also to no avail.

The current commands:

Code: [Select]

#interface getVoltage getSetVoltage?
#interface getCurrent getSetVoltage?

#scpiCmd setVoltage tx 0x3C 0x30 0x31 0x30 (bytesAsHex(formatInt((value*1000),5,8))) 0x30 0x30 0x30 0x3E
:setVar: setVoltage=inputValue;

#scpiCmd setCurrent tx 0x3C 0x30 0x33 0x30 (bytesAsHex(formatInt((value*1000),5,8))) 0x30 0x30 0x30 0x3E
:setVar: setCurrent=inputValue;

#scpiCmd getSetVoltage none?
:readmath: setVoltage

#scpiCmd getSetCurrent none?
:readmath: setCurrent

[Cyclotron]

I'm working on some tests, and I'm perplexed as to why TC doesn't seem consistent when loading devices on a Prologix Ethernet adapter over a TCP socket. I have 5 devices, and they act erratically when trying to connect to them.

This is a bug that has been in TC always. I tried fixing it for serial attached GPIB adapter when adding MODBUS, but I do not know if it worked.

Based on my tests, yes, it is still there for the Prologx GPIB Ethernet adapter

I remember the serial adapter working better, but that test was a while back.

The emulator software I posted earlier in the thread is based on the Prologox Ethernet adapter, so I can use your great software with USB VISA instruments.
I made that software able to accept multiple socket connections to use the workaround of making it look like each instrument is on its own Prologox Ethernet GPIB adapter.

Based on my testing, each A:2, A:4, A:5, etc starts a thread that tries to talk to the adapter, and it's a race. The results are erratic connectivity and access to the devices.

I never tired fixing the Ethernet GPIB adapter.

I will add links to your project in TC's documentation, it looks very useful.
Do different socket connections get separate thread in your software or is everything handled by one thread?
TC takes a performance hit when using shared adapters, because it can only have one message outstanding at a time on the shared adapter.

That explains why my prior tests with my Ethernet GPIB adapter were similarly problematic. I recall switching to the Serial adapter and it being better but again, this is my memory. I can test again given some time. Is there anything you could use to help in your lab?  I don't know if you have access to all the various adapters to run tests against. I'd be willing to donate what I can to support your wonderful tool development.  Speaking of which, do you have a means to do financial donations?

The utility I created supports using a single socket connection or multiple.  Each socket thread can access all instruments on the virtual GPIB patch panel.
When testing and researching, I believe I've confirmed that the Prologix Ethernet adapter will only allow one socket connection, so my workaround in TC will not help those using the real adapter.

I wanted to make sure that TC could have low-latency, non-blocking access to query all configured instruments. So, I've done some "performance" tests on my utility but not extreme ones. I need to write a test harness to validate that after any future builds, but for this release I just did the best I could by setting fast query rates on TC with 5 instruments configured.

[flash2b]

Reading the output is not the solution, I had not realized that you could not read the set point.

There is a way around that, let the driver keep track of the set value and use that as answer. That will work with TC's verification.

In the set voltage #scpiCmd command add:
:setVar: setVoltage=inputValue;

Then declare a #scpiCmd to read the value:
#scpiCmd getSetVoltage none?
:readmath: setVoltage

You do the same for current.


This is a workaround with the purpose to make the power supply work with all popups and panels in TC
I do explain it for SCPIx, but it is the same for other protocols: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Protocol_is_nearly_SCPI,_but_there_is_a_few_issues_(SCPIx)

Thank you! It's good to know there's a possible workaround!

That said, I've given it a crack, but can't figure out where I'm going wrong.

Testing the changes via the PS Interface Popup yields NaN results with Rx timeouts.
Sending the commands directly via the main window shows a more descriptive "Variable not found setVoltage" UnknownException in the logs.

I've also tried changing the intermediate variables' names from setVoltage to setVoltageShadow, to differentiate them from the name setVoltage which is being used for the scpiCmd, but also to no avail.

The current commands:

Code: [Select]

#interface getVoltage getSetVoltage?
#interface getCurrent getSetVoltage?

#scpiCmd setVoltage tx 0x3C 0x30 0x31 0x30 (bytesAsHex(formatInt((value*1000),5,8))) 0x30 0x30 0x30 0x3E
:setVar: setVoltage=inputValue;

#scpiCmd setCurrent tx 0x3C 0x30 0x33 0x30 (bytesAsHex(formatInt((value*1000),5,8))) 0x30 0x30 0x30 0x3E
:setVar: setCurrent=inputValue;

#scpiCmd getSetVoltage none?
:readmath: setVoltage

#scpiCmd getSetCurrent none?
:readmath: setCurrent

You must make initialization first:

Code: [Select]

#scpiCmd setVars none
:setvar: setVoltage=0
:setvar: setCurrent=0

#initCmd setVars
You can put setVars; in front of your existing #initCmd.

It is strange to tx the hex values again, since pcConStart is already defined as scpiCmd (calling it will already send the hex codes). So you can delete the trailing tx + all hex values.

Same for the #finalCmd with pcConStop. Better also is to add a ;[500] at the end of the line to make sure the bytes are processed before breaking the connection.

Also it is :setvar: not :setVar:

Furtermore it is:  #scpiCmd getSetVoltage? none? and #scpiCmd getSetCurrent? none? ....... both missing ? in your code. --> that is the main cause for the timeout and NaN

[NoDisintegrations]

You must make initialization first:

Code: [Select]

#scpiCmd setVars none
:setvar: setVoltage=0
:setvar: setCurrent=0

#initCmd setVars
You can put setVars; in front of your existing #initCmd.

It is strange to tx the hex values again, since pcConStart is already defined as scpiCmd (calling it will already send the hex codes). So you can delete the trailing tx + all hex values.

Same for the #finalCmd with pcConStop. Better also is to add a ;[500] at the end of the line to make sure the bytes are processed before breaking the connection.

Also it is :setvar: not :setVar:

Furtermore it is:  #scpiCmd getSetVoltage? none? and #scpiCmd getSetCurrent? none? ....... both missing ? in your code. --> that is the main cause for the timeout and NaN

Highly appreciated!

I managed to catch the setvar case issue and the missing question marks shortly after reading your unedited post, and adding the variable initialisation.
I wasn't able to find variable initialisation in the documentation pages, so assumed it must have been done automatically when assigning a value to a variable for the first time.

#finalCmd delay has been added and redundant hex transmissions removed.

Everything seems to be working now. That said, I'm happy to make the changes if there's anything else that needs sorting out.

Very awesome of yourself and HKJ for taking the time to help with creating this thing. Thank you both!

(Updated V1.22 definition file attached.)

[flash2b]

You can also add to the #initCmd setVoltage 12;setCurrent 3 to make sure the vars have the same value as the actual PSU. Now the vars are out of sync until you change V or A.

I just choose 12 and 3 but you should choose any other pair as the values you like to have as default as after startup.

[KungFuJosh]

I haven't read much of your conversation, but I would add a script to the initCmd instead of setting the values arbitrarily.

Make a script command to read the state of the PSU and set the variables to match from the start.

[flash2b]

Well readback the setValues is not supported by this device. That was the whole reason of using variables.

See below:

Reading the output is not the solution, I had not realized that you could not read the set point.

There is a way around that, let the driver keep track of the set value and use that as answer. That will work with TC's verification.

In the set voltage #scpiCmd command add:
:setVar: setVoltage=inputValue;

Then declare a #scpiCmd to read the value:
#scpiCmd getSetVoltage none?
:readmath: setVoltage

You do the same for current.

My standard: #scpiCmd setVars;readVars , but in this case not supported.

[KungFuJosh]

Oh, that's annoying. Then you have to be careful about the voltage you set in the variables/initCmd. Maybe start with a default of 0 or close to 0 to avoid potentially frying something by mistake on startup.

[flash2b]

Good option is that the PSU has output On and Off so, yes I would start with Off. 

This line on Nice Power/Kuaiqu is manufactured by Kuaiqu Electronic / Bolton Bailey Electronics in Shenzhen and a fierce competitor of eTommens manufactured by Dongguan TongMen (eTOMMENS) Electronic Technology Co., Ltd. in Dongguan. While the first sell mainly under their own brand names the latter is more an OEM for others. I was very interested to see how the protocol of these two lines of PSUs would compare.

So Nice Power/Kuaiqu uses fixed ascii strings and do not support all features of PSUs we expect to find, compared to the other using Modbus and all supported including protection features.

From a technical PSU side they are both pretty good, and glad that a definition now is also available for TestController after great work of NoDisintegrations.

[HKJ]

I believe NoDisintegration has made a very good definition.
I wonder if there are multiple models where the only difference is voltage/current?
If that is the case it only requires a little work to support all models.

To do that:
Replace all references to voltage/current with names, like MaxVoltage/MaxCurrent, it is very important that these name do not appear elsewhere in the definition.

Declare the definition #meta, i.e. place #meta on the line before the actual definition.

Now you can add each model with:

#metadef
#idString KUAIQU,SPPS3010D,
#name KUAIQU SPPS3010D
#handle SPPS3010D
#replaceText MaxVoltage 32
#replaceText MaxCurrent 10

One #metadef for each model.
Note: You can do a lot of other stuff, like removing lines you do not want (The extra selections for radio control)
Documentation is herehttps://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Creating_multiple_devices_from_one_configuration_file
You can also check definitions of other devices, it is used for nearly all devices that comes in series with slightly different specifications.

[flash2b]

There are 4 models in this series

 SPPS305D 30V 5A
 SPPS3010D 30V 10A
 SPPS605D 60V 5A
 SPPS1203D 120V 3A

Connectivity is optional not standard. but these 4 could be added for sure.

Be also carefull of preset values for Voltage / Current and use e.g. #removeLine 60V 60.0 to remove that option for a PSU that not support it. (see eTommens eTM-MP.txt for some ideas)

[NoDisintegrations]

You can also add to the #initCmd setVoltage 12;setCurrent 3 to make sure the vars have the same value as the actual PSU. Now the vars are out of sync until you change V or A.

I just choose 12 and 3 but you should choose any other pair as the values you like to have as default as after startup.

That's a fine idea. Implemented.

A delay was necessary between the commands.

Code: [Select]

#initCmd setVars;pcConStart;[100];outputOff;[100];setVoltage 5;[100];setCurrent 1;

Oh, that's annoying. Then you have to be careful about the voltage you set in the variables/initCmd. Maybe start with a default of 0 or close to 0 to avoid potentially frying something by mistake on startup.

I've gone with 3.3V 1A for now. The PSU always starts up with it's output off, but I've just added the outputOff command to the #initCmd for safety, in case a connection to TestController is made while it's on and connected to something.
I've tested it and can confirm that if you connect with TC while the output's on, it shuts right off and the chosen set values are displayed on it's screen, along with the word "OFF".

I believe NoDisintegration has made a very good definition.
I wonder if there are multiple models where the only difference is voltage/current?
If that is the case it only requires a little work to support all models.

To do that:
Replace all references to voltage/current with names, like MaxVoltage/MaxCurrent, it is very important that these name do not appear elsewhere in the definition.

Declare the definition #meta, i.e. place #meta on the line before the actual definition.

Now you can add each model with:

#metadef
#idString KUAIQU,SPPS3010D,
#name KUAIQU SPPS3010D
#handle SPPS3010D
#replaceText MaxVoltage 32
#replaceText MaxCurrent 10

One #metadef for each model.
Note: You can do a lot of other stuff, like removing lines you do not want (The extra selections for radio control)
Documentation is herehttps://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Creating_multiple_devices_from_one_configuration_file
You can also check definitions of other devices, it is used for nearly all devices that comes in series with slightly different specifications.

That seems likely. There is documentation of only that same single protocol in the zip file for their atrocious software, which is presumably used for a range of their PSUs. The same protocol is found yet again in their "Remote Contect Step.pdf".
I also had a look at their software. It looks like the only differences for the PSUs are the limits and presets that the software loads for each model, when you manually select one from a dropdown menu. However, I haven't wiresharked the usb to absolutely confirm
that there isn't another undocumented command sent to query a model number. I may look into that at some point, but expect that there won't be. Or at least that if there is, it's probably not used. The lack of a "scan" button in their software is probably a giveaway.

With their software I could only get it to turn the PSU On/Off (which worked for every model I selected), setting the voltage or current just turned them to zeroes on the PSU's screen and their program didn't seem to receive anything.

Back to the TC definition file itself:

I've changed the format to #metadef and added the definitions for SPPS305D, SPPS605D, SPPS1203D. They work within the range of the SPPS3010D, but I've left them commented out with warning until someone with the relevant PSUs tests them and reports back with good news.
I've also adjusted the radio button values to some that are probably more universally applicable to each PSUs range.

(Updated V1.23 definition file attached.) with sample log and screenshots of the Setup popups from each of the #metadefs.

[flash2b]

Once again great work.

Generally uncomment the untested #metadef is fine. That way they will be shown in the Device List of TestController.

You can add a #notes to explain it to the user.

[HKJ]

I've changed the format to #metadef and added the definitions for SPPS305D, SPPS605D, SPPS1203D. They work within the range of the SPPS3010D, but I've left them commented out with warning until someone with the relevant PSUs tests them and reports back with good news.
I've also adjusted the radio button values to some that are probably more universally applicable to each PSUs range.

Please enable the other definitions, or some people will miss them.

Looking in the definition I found:
:update: setVoltage?
That do not do anything, use:
:read: getSetVoltage?
That will make the control show the selected value. Use it only all voltage/current controls!


I do not really like the slider control, sliders are for display brightness and buzzer volume, not for adjusting a important setting. If you want to use a slider, use the "Param adjuster" popup, it is much more controlled. There is also a "analog" control in grid panel, it is in "General device adjustment" as Adjust or Dual adjust. They respond to mouse wheel or mouse dragging.

[NoDisintegrations]

Once again great work.

Generally uncomment the untested #metadef is fine. That way they will be shown in the Device List of TestController.

You can add a #notes to explain it to the user.

I've changed the format to #metadef and added the definitions for SPPS305D, SPPS605D, SPPS1203D. They work within the range of the SPPS3010D, but I've left them commented out with warning until someone with the relevant PSUs tests them and reports back with good news.
I've also adjusted the radio button values to some that are probably more universally applicable to each PSUs range.

Please enable the other definitions, or some people will miss them.

Looking in the definition I found:
:update: setVoltage?
That do not do anything, use:
:read: getSetVoltage?
That will make the control show the selected value. Use it only all voltage/current controls!


I do not really like the slider control, sliders are for display brightness and buzzer volume, not for adjusting a important setting. If you want to use a slider, use the "Param adjuster" popup, it is much more controlled. There is also a "analog" control in grid panel, it is in "General device adjustment" as Adjust or Dual adjust. They respond to mouse wheel or mouse dragging.

All of the above adjustments and corrections made. The sliders also couldn't deal with the decimal .3 in the 3.3V initialisation setting, so they've now gone to Belize.

The definition now supports all 8 models from the SPPS series (see linked .pdf reference):
SPPS305D, SPPS3010D, SPPS605D, SPPS1203D, SPPS3206D, SPPS2001D, SPPS3001D, SPPS4001D.

https://cdn.shopify.com/s/files/1/0705/8027/3329/files/SPPS305D_English_Manual.pdf?v=1748051830

I've also made a number of other changes including:

- Warning indicator for voltages set above 50V (for applicable models) on the Setup popup. (example screenshots attached for SPPS4001D)
- Radio Buttons no longer support setting above 60V for safety reasons.
- Definition filename changed to "KUAIQU SPPS Series.txt", as it is no longer model specific.

(Updated V1.30 definition file attached) with screenshots.

[HKJ]

All of the above adjustments and corrections made. The sliders also couldn't deal with the decimal .3 in the 3.3V initialisation setting, so they've now gone to Belize.

You did not add:
:read: getSetVoltage?
to the radio box item

Without the read they will not show the selected voltage/current.

[NoDisintegrations]

All of the above adjustments and corrections made. The sliders also couldn't deal with the decimal .3 in the 3.3V initialisation setting, so they've now gone to Belize.

You did not add:
:read: getSetVoltage?
to the radio box item

Without the read they will not show the selected voltage/current.

Corrected and tested!

(Updated V1.31 definition file attached)

[HKJ]

Corrected and tested!

(Updated V1.31 definition file attached)

Thanks, I have added it.

When reading you comments i the file I starting wondering? Do KUAIQU  also sell these supplies marked NICE-POWER?
If they do, you are allowed to double you metadefs and use that name also (But keep the filename).
Generally people must be able to find the device from its marking, and do not need to know the OEM.
I do not know how many brands for single definition is record in TC, but there are some with multiple brands.

[flash2b]

When I have a device that supports both Mobus RTU and TCP, do I need to make 2 #metadef one with #subDriver RTU and one #subDriver TCP ?

[HKJ]

When I have a device that supports both Mobus RTU and TCP, do I need to make 2 #metadef one with #subDriver RTU and one #subDriver TCP ?

That is up to you.

Modbus TCP is not very well tested, it is not the same protocol as RTU.
If it do RTU on both serial and TCB, you just list it under #port

[flash2b]

I think I cannot do

#driver Modbus
#subDriver RTU TCP
#port comfixedbaud modbus 502
#baudrate 9600


So probably make 2 #metadef one with subDriver RTU and #port comfixedbaud modbus while the other has #subDriver TCP and #port 502

[HKJ]

I think I cannot do

#driver Modbus
#subDriver RTU TCP
#port comfixedbaud modbus 502
#baudrate 9600


So probably make 2 #metadef one with subDriver RTU and #port comfixedbaud modbus while the other has #subDriver TCP and #port 502

If TCP uses RTU protocol you can do:
#port comfixedbaud modbus 502

If TCP uses MODBUS TCP, you need another subdriver, i.e. another definition.

[flash2b]

One more device then... we want to hit the 1000 devices support mark this year !

Well good to know that Mobus TCP is not very well tested, I assume I can report issues 

[HKJ]

One more device then... we want to hit the 1000 devices support mark this year !

I will probably happen.
Current it is at 970 with NoDisintegrations contribution, but I need to subtract a bit from that for my own private devices and virtual devices. I.e. about 60 devices more and I will officially say 1000 devices supported.

Well good to know that Mobus TCP is not very well tested, I assume I can report issues 

Of course.