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

[HKJ]

Instead of type a command port, press F2 to enter edit mode in the address field, the right click to see what comport are defined.

Nothing happens, when I right click while editing the address field. The Electronic Load Test Software by Atorch also doesn't see the DL24. Do I need a driver for the DL24? Under which entry is the DL24 usually listed in Device Manager?

Edit: A post by @1RandomUser led me to the BW150 software from Atorch  (http://en.atorch.cn/NewsDetail.aspx?ID=84). It runs smoothly on the BW150 even without a firmware update. Is this because the BW150 – and presumably the newer DL24 as well – cannot be accessed via a UART interface? Can the BW150 be supported by TC?

It sound like there is no com port to use, that makes it impossible for TC to connect to the load.

Try only changing the #name string, not the #idString and see if that makes it work.

Unfortunately, nothing has changed.

If it worked before you changed name, it will also work after you change the #name string, or you did damage the file.

[HKJ]

I reuploaded it, and it's actually attached now. The board is weird with attachments sometimes. 

It doesn't have anything new yet; I only made it work and removed unneeded stuff. Let me know what features you need, and I'll see if I can implement them.

Josh I still have not gotten to your file yet.  I had to test two batteries for a project and did not realize that it would take 16 hours to test each battery.

BTW when a battery load test is performed is the graphing and data capture supposed to start when I turn on Load and end when the load voltage gets to cutoff?
I have to be doing it manually.

There are a couple of different battery test options in TC, some of them do control the chart.

[Dread]

There are a couple of different battery test options in TC, some of them do control the chart.

Now that i got those two batteries out of the way I am going to start testing the other methods.
Thanks

[Silent Runner]

Nothing happens, when I right click while editing the address field. The Electronic Load Test Software by Atorch also doesn't see the DL24. Do I need a driver for the DL24? Under which entry is the DL24 usually listed in Device Manager?

Edit: A post by @1RandomUser led me to the BW150 software from Atorch  (http://en.atorch.cn/NewsDetail.aspx?ID=84). It runs smoothly on the BW150 even without a firmware update. Is this because the BW150 – and presumably the newer DL24 as well – cannot be accessed via a UART interface? Can the BW150 be supported by TC?

It sound like there is no com port to use, that makes it impossible for TC to connect to the load.

That’s what I was afraid of. Bad news for anyone planning to buy a DL24, as they’ll likely end up with the newer model too. However, the DL24 does have a Bluetooth module. Is it possible to connect to the device via Bluetooth? If I’ve understood correctly, @1RandomUser managed to upgrade the DL24 to a DW150 with a WiFi module. Would a connection to TC be possible via that? But the DW150 firmware would need to be flashed for that, and then it would no longer be a DL24.

Unfortunately, nothing has changed.

If it worked before you changed name, it will also work after you change the #name string, or you did damage the file.

Sorry, I was wrong. I didn't read the full message. With the original KeysightDMMs.txt-File the message in the Commands-Tab says:
;; USB-Serial Controller (COM9) Did not find any match for: Agilent Technologies,U1253A,MY511xxxxx,V1.20

After changing only the #name string the following message is shown in the Commands-Tab:
;; USB-Serial Controller (COM9) Device "Keysight Technologies,U1253A," do not match answer: "Agilent Technologies,U1253A,MY511xxxxx,V1.20"

When exchanging Keysight with Agilent in both #name and #idString there was no message at all in the Commands-Tab.

But: I’ve also changed the #idString to Agilent again, and now it reports

‘;; Found Agilent U1253A on USB-Serial Controller (COM9) sn: MY511xxxxx’

 I’ve no idea what I did wrong the first time. But in the Current values tab, I can only see data in resistance, diode and capacity modes.

I tried creating a new file using ‘Create new SCPI device definition’ and that actually worked straight away. However, I couldn’t find the file named ‘Agilent U1253.txt’ by TC in the Device folder. Reason: TC had saved the file in the newly created folder ‘Users\xx\Documents\TestController\Devices’. But I now had two entries with this name in the device list. As I couldn’t tell which was the new entry, I deleted both devices from the list and restarted TC. The device list was empty, but I still received the message: ‘;; Found Agilent U1253A on USB-Serial Controller (COM9) sn: MY511xxxxx’. I moved the newly created file ‘Agilent U1253.txt’ to a different directory, but still received the message. Renaming the edited ‘KeysightDMMs.txt’ file didn’t change anything either. It was only when I moved this file to a different folder that the message disappeared. Nevertheless, the other Agilent and Keysight devices were still in the selection list. This was because I had merely renamed the unedited ‘KeysightDMMs.txt’ file. Is the content of all files in the Devices folder loaded into TC regardless of their names?

That might also have been the reason why I couldn’t successfully create a new SCPI device definition a second time. Once the files were gone, it worked. A bit confusing.

Data isn’t displayed at all with the newly created file. Configuration is needed. I’ll have to work through your corresponding page for that.

[HKJ]

Now that i got those two batteries out of the way I am going to start testing the other methods.
Thanks

I will recommend that you try out the new battery test popup.

[HKJ]

@1RandomUser managed to upgrade the DL24 to a DW150 with a WiFi module. Would a connection to TC be possible via that? But the DW150 firmware would need to be flashed for that, and then it would no longer be a DL24.

TC works fine with socket and some other network connections.

Sorry, I was wrong. I didn't read the full message. With the original KeysightDMMs.txt-File the message in the Commands-Tab says:
;; USB-Serial Controller (COM9) Did not find any match for: Agilent Technologies,U1253A,MY511xxxxx,V1.20

After changing only the #name string the following message is shown in the Commands-Tab:
;; USB-Serial Controller (COM9) Device "Keysight Technologies,U1253A," do not match answer: "Agilent Technologies,U1253A,MY511xxxxx,V1.20"

When exchanging Keysight with Agilent in both #name and #idString there was no message at all in the Commands-Tab.

But: I’ve also changed the #idString to Agilent again, and now it reports

‘;; Found Agilent U1253A on USB-Serial Controller (COM9) sn: MY511xxxxx’

 I’ve no idea what I did wrong the first time. But in the Current values tab, I can only see data in resistance, diode and capacity modes.

I tried creating a new file using ‘Create new SCPI device definition’ and that actually worked straight away. However, I couldn’t find the file named ‘Agilent U1253.txt’ by TC in the Device folder. Reason: TC had saved the file in the newly created folder ‘Users\xx\Documents\TestController\Devices’. But I now had two entries with this name in the device list. As I couldn’t tell which was the new entry, I deleted both devices from the list and restarted TC. The device list was empty, but I still received the message: ‘;; Found Agilent U1253A on USB-Serial Controller (COM9) sn: MY511xxxxx’. I moved the newly created file ‘Agilent U1253.txt’ to a different directory, but still received the message. Renaming the edited ‘KeysightDMMs.txt’ file didn’t change anything either. It was only when I moved this file to a different folder that the message disappeared. Nevertheless, the other Agilent and Keysight devices were still in the selection list. This was because I had merely renamed the unedited ‘KeysightDMMs.txt’ file. Is the content of all files in the Devices folder loaded into TC regardless of their names?

That might also have been the reason why I couldn’t successfully create a new SCPI device definition a second time. Once the files were gone, it worked. A bit confusing.

Data isn’t displayed at all with the newly created file. Configuration is needed. I’ll have to work through your corresponding page for that.

The second directory TC creates for definitions has priority over the first for regular definitions, but this priority system do not work for #metadef.
The easiest way to get around it is to use a slightly different name for the device.

[flash2b]

As I have told you, I working on (several) definitions for devices (several brands) that can output a character, string, number or float.

I propose to use the following #interface standard (based on: https://lygte-info.dk/project/TestControllerInterfaceDefinitions%20UK.html) for this

--
Display

A single channel display will be:
#interfaceType display
But most display interfaces are multichannel (Here a 6 channel):
#interfaceType display display:2 display:3 display:4 display:5 display:6

Primary display

   #interface setDisplayAscii, set a display to a ascii character code
   #interface getDisplayAscii, get the shown ascii character code of a single display
   #interface setDisplaysInteger, set all displays to show an integer value
   #interface getDisplaysInteger, get the shown integer value of the full display
   #interface setDisplaysFloat, set all displays to show a float value
   #interface getDisplaysFloat, get the shown float value of the full display
   #interface setDisplaysText, set all displays to show string value
   #interface getDisplaysText, get the shown string content of the full display
--

For this to work properly the content of getDisplayAscii and getDisplaysText must be allowed to a :string: currently I get NaN if there is a non number on the display.

Let me know your feedback.

PS.
Maybe #interface setDisplayChar and #interface getDisplayChar is already better. (instead of Ascii)

[HKJ]

As I have told you, I working on (several) definitions for devices (several brands) that can output a character, string, number or float.

I propose to use the following #interface standard (based on: https://lygte-info.dk/project/TestControllerInterfaceDefinitions%20UK.html) for this

--
Display

A single channel display will be:
#interfaceType display
But most display interfaces are multichannel (Here a 6 channel):
#interfaceType display display:2 display:3 display:4 display:5 display:6

Primary display

   #interface setDisplayAscii, set a display to a ascii character code
   #interface getDisplayAscii, get the shown ascii character code of a single display
   #interface setDisplaysInteger, set all displays to show an integer value
   #interface getDisplaysInteger, get the shown integer value of the full display
   #interface setDisplaysFloat, set all displays to show a float value
   #interface getDisplaysFloat, get the shown float value of the full display
   #interface setDisplaysText, set all displays to show string value
   #interface getDisplaysText, get the shown string content of the full display
--

For this to work properly the content of getDisplayAscii and getDisplaysText must be allowed to a :string: currently I get NaN if there is a non number on the display.

Let me know your feedback.

PS.
Maybe #interface setDisplayChar and #interface getDisplayChar is already better. (instead of Ascii)

Not a bad idea, but I see a few issues.
Display is a very generic term, it can cover many sizes, I have the impression this is displays that only shows a few characters at a time, and a name that sort of indicates that might be better.
If ascii/char is for displaying a single character, where on the display is it shown and can it be used together with other functions? It can often be useful to combine a letter and a number on the display.
I like using the name Text, but the datatype is String and it might be a better name for that function.

For a idea on how a display library work see: https://lygte-info.dk/project/DisplayDriver%20UK.html#All_functions the library is designed to be used on a microcontroller to handle a attached 7-seg display. Do not try to do anything like that, it is way to complicated for this task, but you might be able to get some ideas from it.

[flash2b]

Thank you for your feedback.

I have seen the content of the #DisplayDriver. I myself also want to build a 8 digit version with help of a MAX7219 + Arduino, once I have more time to strengthen my Arduino skills.

I agree that "Display" is a generic term, and to focus it more and make it more specific, I would opt for "Readout" also seen these term used commercially. I liked the analogy with Relay and Relays so that is why I came pup with Display Displays.

The devices I use at the moment are commercially available, so no DIY required. These include 1, 2, 3, 4 and 6 digit readouts. My definitions work great already on the 4 data type I listed. They offer similar features like the one on your #DisplayDriver page including blinking of digits and brightness control for the full display (or readout). I added blinking to the #interface below. I am running it at the background to show alternating values with #runscript.

Char is numbered left to right, Text (or String) is also left to right, Integer is right to left (no leading zero) with support of sign and Float is utilizing maximum digits (with rounding) with support of sign.

It also supports setting a Integer or Float first and then adding a Char (better term than letter since there are only 26 letters and more chars). This requires 2 writes to the #interface.


To summarize

--
Readout

A single channel readout will be:
#interfaceType readout
But most readout interfaces are multichannel (Here is a 6 channel):
#interfaceType readout readout:2 readout:3 readout:4 readout:5 readout:6


   #interface setReadoutChar, set a character on a position of the readout
   #interface getReadoutChar, get the shown character on a position of the readout
   #interface setReadoutInteger, set readout to show an integer value
   #interface getReadoutInteger, get the shown integer value of the readout
   #interface setReadoutFloat, set readout to show a float value
   #interface getReadoutFloat, get the shown float value of the readout
   #interface setReadoutString, set readout to show string value
   #interface getReadoutString, get the shown string content of the full readout
   #interface setReadoutBlink, set a character on a position of the readout to blink
   #interface getReadoutBlink, get the blink status of a character position
--

For this to work properly the content of getReadoutChar and getReadoutString must be allowed to a :string: currently I get NaN if there is a non number on the readout (display).

Let me know your feedback of my updated proposed new #interfaceType.

PS:
#interface setReadoutBlink, set a character on a position of the readout to blink
#interface getReadoutBlink, get the blink status of a character position

Could also be done alternatively setReadoutBlinkOn and setReadoutBlinkOff (like #interfaceType relay)

#interface setReadoutBlinkOn, set a character on a position of the readout to blink
#interface setReadoutBlinkOff, set a character on a position of the readout NOT to blink

[HKJ]

The devices I use at the moment are commercially available, so no DIY required. These include 1, 2, 3, 4 and 6 digit readouts. My definitions work great already on the 4 data type I listed. They offer similar features like the one on your #DisplayDriver page including blinking of digits and brightness control for the full display (or readout). I added blinking to the #interface below. I am running it at the background to show alternating values with #runscript.


Let me know your feedback of my updated proposed new #interfaceType.

I will adapt your definitions.
I have added the two functions to the list of string functions, this will work from next version (beta or release).
I do not define get/set when defining string functions, TC will assume both are strings.

PS:
#interface setReadoutBlink, set a character on a position of the readout to blink
#interface getReadoutBlink, get the blink status of a character position

Could also be done alternatively setReadoutBlinkOn and setReadoutBlinkOff (like #interfaceType relay)

#interface setReadoutBlinkOn, set a character on a position of the readout to blink
#interface setReadoutBlinkOff, set a character on a position of the readout NOT to blink

I assume each digits is handled as a device, this means I like setReadoutBlink best (No on/off in the name).

[flash2b]

I assume each digits is handled as a device, this means I like setReadoutBlink best (No on/off in the name).

Yes, it uses like :2 to select.

I am very happy with this 

You can also copy the content between the two "--"  to  https://lygte-info.dk/project/TestControllerInterfaceDefinitions%20UK.html

[HKJ]

You can also copy the content between the two "--"  to  https://lygte-info.dk/project/TestControllerInterfaceDefinitions%20UK.html

I have updated the document, please see if you agree.

[flash2b]

Forgot to refresh 

I agree.

When you were working on the display library for Arduino, did you ever wanted to create a SCPI (or Modbus  ) controlled Readout?

[HKJ]

When you were working on the display library for Arduino, did you ever wanted to create a SCPI (or Modbus  ) controlled Readout?

No, it was not something that was relevant at that time. This library is made before I made testController and the logging software I used at that time did not have a visual component. I did make a box with a few leds and a buzzer that it could control, but that was it. TestController was started as a upgrade to that software, but it is considerable more now.

[Dread]

Now that i got those two batteries out of the way I am going to start testing the other methods.
Thanks

I will recommend that you try out the new battery test popup.

That works a treat but I can't find a way to stop it from using a 1 second default logging interval.

[HKJ]

I will recommend that you try out the new battery test popup.

That works a treat but I can't find a way to stop it from using a 1 second default logging interval.

The 1 sec logging interval is hardcoded. The only issues with that is large files and TC has no issues with that. If you need smaller files for other applications, you can use the export function in TC to generate a smaller file.

[Dread]

The 1 sec logging interval is hardcoded. The only issues with that is large files and TC has no issues with that. If you need smaller files for other applications, you can use the export function in TC to generate a smaller file.

You might want to think about making it a variable in the future.
Lots of people with Solar Installs are reaching the 4-5 Year ownership point and battery capacity Testing is going to be a big thing.  It will take me about 16 Hours with this ET5410 to discharge each 100Ah / 5.4KWh battery and I have 8 packs.  That about 1.4 Million samples @1sec per battery.
It would be nice if there was a way to cut that down at least 10 fold.

[HKJ]

The 1 sec logging interval is hardcoded. The only issues with that is large files and TC has no issues with that. If you need smaller files for other applications, you can use the export function in TC to generate a smaller file.

You might want to think about making it a variable in the future.
Lots of people with Solar Installs are reaching the 4-5 Year ownership point and battery capacity Testing is going to be a big thing.  It will take me about 16 Hours with this ET5410 to discharge each 100Ah / 5.4KWh battery and I have 8 packs.  That about 1.4 Million samples @1sec per battery.
It would be nice if there was a way to cut that down at least 10 fold.

I have been doing battery test for a long time and usually I have test runs up to 30 hours with 1 sec interval, sometimes I also have considerable longer runs.
TC do not have a issue with a few million samples and you can easily reduce the file size by doing a export.

You can check my website to see my battery test, all of them are with 1 sec sample interval, even when I do stuff like this: https://lygte-info.dk/info/BatteriesLowCurrentDischarge2%20UK.html (There is a 3 week discharge in that lot).

[KungFuJosh]

I have been doing battery test for a long time and usually I have test runs up to 30 hours with 1 sec interval, sometimes I also have considerable longer runs.
TC do not have a issue with a few million samples and you can easily reduce the file size by doing a export.

You can check my website to see my battery test, all of them are with 1 sec sample interval, even when I do stuff like this: https://lygte-info.dk/info/BatteriesLowCurrentDischarge2%20UK.html (There is a 3 week discharge in that lot).

I agree, there's no technical reason TC can't handle the current setup. However, what's the benefit of such a short interval over 30 hours? Have you found weird glitchy behavior that needed a finer test resolution? Personally, I would prefer to control the interval.

[HKJ]

I agree, there's no technical reason TC can't handle the current setup. However, what's the benefit of such a short interval over 30 hours? Have you found weird glitchy behavior that needed a finer test resolution? Personally, I would prefer to control the interval.

Generally I prefer to have a stable logging rate, independent of the discharge current and at high current you want to turn off fairly fast when voltage drops below minimum.
If the battery has a BMS system that kicks in, you may need the 1 sec logging rate to get a good guess about what voltage it activate at.

[Dread]

Generally I prefer to have a stable logging rate, independent of the discharge current and at high current you want to turn off fairly fast when voltage drops below minimum.
If the battery has a BMS system that kicks in, you may need the 1 sec logging rate to get a good guess about what voltage it activate at.

I get that it might be great for AA or other small Batteries but the smallest packs in Solar Installs are 5KWh and they go up to 32KWh.   
I can tell you that nothing fast happens at even 5KWh.  Even the steep end of the curve take minutes to drop off, especially if your only drawing 300W from it  

[KungFuJosh]

Here are some updated definitions for the East Tester ET5410A+ and ET5420A+ DC Loads. Other brand variants can be added with metadefs; if anybody has a list I can add them in. Other single and dual channel models compatible with this protocol/firmware version/whatever could also potentially work.

These definitions have separated the mode functions from cmdSetup, and should function more inline with how TC is intended.

I separated the single/dual models because the metadef remove stuff was just too much to be worth it to keep them together.

I tested basic functions of both definitions briefly. Please let me know if anybody finds any issues. Note: these will not be compatible with older models.

Thanks,
Josh

[HKJ]

Here are some updated definitions for the East Tester ET5410A+ and ET5420A+ DC Loads. Other brand variants can be added with metadefs; if anybody has a list I can add them in. Other single and dual channel models compatible with this protocol/firmware version/whatever could also potentially work.

Updated, thanks.

[KungFuJosh]

Here are some updated definitions for the East Tester ET5410A+ and ET5420A+ DC Loads. Other brand variants can be added with metadefs; if anybody has a list I can add them in. Other single and dual channel models compatible with this protocol/firmware version/whatever could also potentially work.

Updated, thanks.

Is there any way to make Handles allow the + sign? I have it set as ET5420AP because ET5420A+ doesn't work.

Thanks,
Josh

[HKJ]

Is there any way to make Handles allow the + sign? I have it set as ET5420AP because ET5420A+ doesn't work.

Because values from devices can be used in expressions, any operator (and a lot of other stuff) is banned from handles. You might be able to get away with some of it, but that means variables using the handle as prefix will use a modified handle and that is not the best solution.
If you want to be sure you have a clean handle name, check that the variable is called the same as the handle.