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

[HKJ]

The future is now! 🤯

if somebody using a COM port wants to test these, that'd be great, thanks. 😉

No issues with this change using my 2010 on GPIB. I can't test on a 2700 anymore.

I have update, but I changed your if statements.
A single = is a assignment, not a comparison
And using !="GPIB" is a better way, because TC support 3 different comports, but only one GPIB port.

[KungFuJosh]

The future is now! 🤯

if somebody using a COM port wants to test these, that'd be great, thanks. 😉

No issues with this change using my 2010 on GPIB. I can't test on a 2700 anymore.

I have update, but I changed your if statements.
A single = is a assignment, not a comparison
And using !="GPIB" is a better way, because TC support 3 different comports, but only one GPIB port.

Like the attached then?

I didn't know the different comport types might be an issue.

Thanks,
Josh

[HKJ]

Like the attached then?

Exactly.

I didn't know the different comport types might be an issue.

Depends, using GPIB is the safe way.
The actual internal porttype names are: None, Serial, SerialFixedBaud, SerialNoBaud, SocketAuto, Socket, LXI, USBHID, GPIB, UDP, Modbus, Dummy

Upper/Lower case do also matter when using == to compare.

[KungFuJosh]

I want to add screendump to the Siglent SDM3000X meters. They support the command SCDP to do that via SCPI, but it doesn't work.
I tried this:
#ScreenDump std
SCDP

TC says "ScreenDump failed due to null" - log attached, but probably useless.

Thanks,
Josh

ETA: I dunno why the B was missing in that log, but more often it starts with this:
BM6ú6(à


ú       

[rallyhard]

When launching an automatic battery test from a script, I can't get setting chargeEndCurrent (EOC) to work. Is there something special about that field?

[HKJ]

I want to add screendump to the Siglent SDM3000X meters. They support the command SCDP to do that via SCPI, but it doesn't work.
I tried this:
#ScreenDump std
SCDP

TC says "ScreenDump failed due to null" - log attached, but probably useless.

The log may be more useful if you give the command on the command line.
TC expect standard image format (Usually png or bmp).
If a image is transferred another way I can must add code to handle it.

[HKJ]

When launching an automatic battery test from a script, I can't get setting chargeEndCurrent (EOC) to work. Is there something special about that field?

I just tried this:

#ShowPopupSystem BatteryTest 132 14 500 330
#BatteryTest V 4.3 1000m 60m 3.2 5m
#BatteryTest C 501m 1.1 2.1 5.1
#BatteryTest M 255 0 4 70 1 Test

And parameters went in exactly as specified.

But I do have a limit on the maximum value, what current are you trying to set?

[KungFuJosh]

I want to add screendump to the Siglent SDM3000X meters. They support the command SCDP to do that via SCPI, but it doesn't work.
I tried this:
#ScreenDump std
SCDP

TC says "ScreenDump failed due to null" - log attached, but probably useless.

The log may be more useful if you give the command on the command line.
TC expect standard image format (Usually png or bmp).
If a image is transferred another way I can must add code to handle it.

Attached from the command window and debug log. It's supposed to be a BMP.

Thanks,
Josh

[HKJ]

Attached from the command window and debug log. It's supposed to be a BMP.

Nothing looks like a binary SCPI command, i.e. it mat be a proprietary format.
The first character is supposed to be #, followed by a numeric digit, that specify how many digits to read for the length, i.e. usually it will be something like:
#49876.........................
for a actual data length of 9876 bytes.

To handle other format I need some format specifications.

[flash2b]

Format:
https://gist.github.com/thatisuday/95923af1ab25d3e634518da3322ecae5
https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapfileheader

[KungFuJosh]

Attached from the command window and debug log. It's supposed to be a BMP.

Nothing looks like a binary SCPI command, i.e. it mat be a proprietary format.
The first character is supposed to be #, followed by a numeric digit, that specify how many digits to read for the length, i.e. usually it will be something like:
#49876.........................
for a actual data length of 9876 bytes.

To handle other format I need some format specifications.

I think the SCDP command might be a little weird. There's discussion on this site for different Siglent devices with SCDP command. This is probably relevant: https://www.eevblog.com/forum/testgear/siglent-sdg6000-series-awg_s/msg5857495/#msg5857495

Thanks,
Josh

[KungFuJosh]

I ran into a sorta weird thing.

On the Scales for chart tab:
I usually switch to Center/Span for the range. I made a mistake and put 500uu. The second u made both columns switch to ?s. Editing either one wouldn't work. I had to switch to Min/Max and manually enter values there, then switch back to edit Center/Span.

Is it possible you can limit the input to a single unit letter to avoid this? Or something to prevent that like ignoring doubles or rejecting invalid input (but revert to last acceptable value).

Thanks,
Josh

[HKJ]

Attached from the command window and debug log. It's supposed to be a BMP.

I have made a new test version, it support a bmp type in addition to std type screendump.
The code is completely untested, please test and report back.

http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[HKJ]

When launching an automatic battery test from a script, I can't get setting chargeEndCurrent (EOC) to work. Is there something special about that field?

In the new beta version I have increased the charge the limit on charge termination current to 5A, hope that fixes your problems.

[HKJ]

I ran into a sorta weird thing.

On the Scales for chart tab:
I usually switch to Center/Span for the range. I made a mistake and put 500uu. The second u made both columns switch to ?s. Editing either one wouldn't work. I had to switch to Min/Max and manually enter values there, then switch back to edit Center/Span.

Is it possible you can limit the input to a single unit letter to avoid this? Or something to prevent that like ignoring doubles or rejecting invalid input (but revert to last acceptable value).

It looks like it enters NaN (Not a number) value when you do that and that prevents calculating the center/span values.
I have not decided if I want to change this behavior, it is easy enough to get back from.

[rallyhard]

Got it all working now 

Thanks for bumping that up

[KungFuJosh]

I have not decided if I want to change this behavior, it is easy enough to get back from.

Something should be done about what happens after that. If Center/Span is in use, you can't recover without switching to Min/Max.

Maybe add an if statement that if changing from NaN to a valid number resets the other to a default value. Or simply if the result is NaN set it to a default instead automatically.

[KungFuJosh]

I have made a new test version, it support a bmp type in addition to std type screendump.
The code is completely untested, please test and report back.

I added a delay to the command which removed the failure due to null for both std and bmp. However, it doesn't turn into an image in either case:
#ScreenDump std
SCDP;[1000]

#ScreenDump bmp
SCDP;[1000]

I've attached the result the above produces as fail.bmp.txt (copied from the command window) and a zip containing a working bmp for comparison saved directly on the device.

Thanks,
Josh

[HKJ]

I added a delay to the command which removed the failure due to null for both std and bmp. However, it doesn't turn into an image in either case:
#ScreenDump std
SCDP;[1000]

#ScreenDump bmp
SCDP;[1000]

I've attached the result the above produces as fail.bmp.txt (copied from the command window) and a zip containing a working bmp for comparison saved directly on the device.

I converted the read code to read a file and tried again, I found a bug and fixed it.
Please try again.
You have to use #ScreenDump bmp to use this code. Std is for a SCPI command. I could have made that automatic, but if other formats shows up, it is better to request that it is defined in the definition.

PS: I added a check for NaN on the center/span input and is now ignoring that type of input.

[KungFuJosh]

I converted the read code to read a file and tried again, I found a bug and fixed it.
Please try again.
You have to use #ScreenDump bmp to use this code. Std is for a SCPI command. I could have made that automatic, but if other formats shows up, it is better to request that it is defined in the definition.

The end result is attached. I tried with and without the delay, and shared both (delay appears to be required for now).

Is it possible for TC to read the response in raw hex or something like that? TC seems to be doing something to convert the response (or at least it's converted in the command window). If you view the response in hex vs. reading the BMP file I shared above in hex, they are different.

PS: I added a check for NaN on the center/span input and is now ignoring that type of input.

Thank you!

Thanks,
Josh

[HKJ]

The end result is attached. I tried with and without the delay, and shared both (delay appears to be required for now).

Is it possible for TC to read the response in raw hex or something like that? TC seems to be doing something to convert the response (or at least it's converted in the command window). If you view the response in hex vs. reading the BMP file I shared above in hex, they are different.

TC uses the same read routines as the std format, it is a binary read.
I have added code to list how many bytes is read and a hex dump of the first 512 bytes

I.e. it is supposed to write the line:
Read 391734 bytes
And 32 lines with hex data to the console.

The above code ignores the debug setting and will always dump these lines.
Note: The reading has a hardcoded 5 second timeout, I would not expect any issues with that on a network.

[KungFuJosh]

It's just a guess, but I think the reading conversion might be the issue. I dunno. I will also try with a different meter.

[HKJ]

It's just a guess, but I think the reading conversion might be the issue. I dunno. I will also try with a different meter.

You are not supposed to get any output when doing a screendump, it is supposed to read all bytes.
I wonder if the device uses too much time to prepare the screendump and the first read timeout* (It uses the standard timeout).
Try increase the timeout.

The routine uses a initial read to get the data length (it read 6 bytes) and the another read to read the remaining data. The second read has a 5 second timeout.

[KungFuJosh]

I tried:
#ScreenDump bmp
SCDP;[9999]

No change in the results.

Thanks,
Josh

[HKJ]

I tried:
#ScreenDump bmp
SCDP;[9999]

No change in the results.

That was not the value I was talking about, it do not affect the read in any way.
It is the #readingDelay setting, try increase it to 5 seconds.