Program that can log from many multimeters.

[HKJ]

It is only necessary to test with Kunkinx, what is needed now is to get data back from the KP184 and I am a bit low on ideas.

Data from KP184 does not come back. It would be more correct to say KP184 sends data (I see it in the com-port monitor), but TC does not understand this data.

I believe I found the issue, try this version (V1.64) (It may be up to an hour before you can download the correct version):
http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[PaWill68]

There are no external changes. Data is still not being received by TC. (((

9600N81DR - does it mean RTS on, DTR on, Data bits = 8, Stop bits = 1? What is "N"?

Can the connection parameter be affected:

Code: [Select]

Handflow: ControlHandShake=(DTR_CONTROL), FlowReplace=(TRANSMIT_TOGGLE, RTS_CONTROL, XOFF_CONTINUE), XonLimit=2048, XoffLimit=512
Set timeouts: ReadInterval=-1, ReadTotalTimeoutMultiplier=-1, ReadTotalTimeoutConstant=1000, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=0Kunkin software has this parameter:

Code: [Select]

Handflow: ControlHandShake=(DTR_CONTROL), FlowReplace=(TRANSMIT_TOGGLE, RTS_CONTROL), XonLimit=64, XoffLimit=64
Set timeouts: ReadInterval=-1, ReadTotalTimeoutMultiplier=0, ReadTotalTimeoutConstant=0, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=500

[djadeski]

I have been following this and with the jar file just made available I am receiving data to TC at 115,200 using this setting 115200N81rd - have not tested other settings but current values tab is updating. I do not have a sniffer so cannot speak to what is actually happening but the setup pop up is working as well.

[PaWill68]

djadeski, It still does not receive data (((
rd - RTS off, DTR off. In kunkin software RTS on, DTR on.

What's the serial number?
my 2021022700080

[djadeski]

Very weird -  min is 2020101019440, so older than yours.  Perhaps another change?
                               

[PaWill68]

djadeski, Will the new Kunkin software work for you?
https://disk.yandex.ru/d/5MizUcHimwxMIw

[djadeski]

I had downloaded that when i was mentioned in the other thread and this is the first time it worked with this unit - see screenshots attached.

[HKJ]

There are no external changes. Data is still not being received by TC. (((

Have you checked you got the correct version of TC?

[PaWill68]

Sure. And tried different bitrains and flags.

[PaWill68]

HKJ, i will ask you about these parameters again. They change several times during the boot process. First they coincide with kunkinsw, then they become different. Maybe they are the problem?
ReadTotalTimeoutMultiplier=-1
ReadTotalTimeoutConstant=1000

[HKJ]

HKJ, i will ask you about these parameters again. They change several times during the boot process. First they coincide with kunkinsw, then they become different. Maybe they are the problem?
ReadTotalTimeoutMultiplier=-1
ReadTotalTimeoutConstant=1000

TC control the serial parameters but receive timeout is in software, because it uses a event handle to capture the data from the serial port and there is no timeout associated with that.
For modbus the event handle will collect one packet at a time and kick it down to the receive routine that may show the debug output.

[PaWill68]

I have no more ideas. But I can see the difference in the parameters in the working connection of kunkinsw and TC 

[HKJ]

I have no more ideas. But I can see the difference in the parameters in the working connection of kunkinsw and TC 

I wonder, TC must be V1.64 and you have verified on the About page you are using that version?
My webserver has a cache, i.e. files do not get updated at the same time I upload them, there can be up to one hour delay.

[PaWill68]

The old version (1.62) is downloaded from the official address. I installed from here https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg3566608/#msg3566608

[HKJ]

The old version (1.62) is downloaded from the official address. I installed from here https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg3566608/#msg3566608

That is an intermediate version, downloaded before the webserver cache had update.
The test version with a fixed fault is here: http://lygte-info.dk/pic/Projects/TestController/TestController.jar
It is only a .jar file and must be used to replace the .jar file from a regular release.

If you or djadeski test it I would like the answer to: model?
typed on the command line.

[PaWill68]

Works!!!!
model?
;; COM11: Flush:
;; COM11: Tx: 01 03 00 01 00 04 15 C9
;; COM11: Rx: 01 03 04 00 00 07 30 F8 17
;; 1840

[djadeski]

Working here as well - looks very good.

thank you!

[HKJ]

Works!!!!
model?
;; COM11: Flush:
;; COM11: Tx: 01 03 00 01 00 04 15 C9
;; COM11: Rx: 01 03 04 00 00 07 30 F8 17
;; 1840

Good, I will add a Kunkin KP184 V4 (or is it V3) to the next release of TestController.
Add the identifier is the same, i.e. the #verifyDevice do not need to be commented out. This means it will only connect if there is a load connected to the specified serial port and there is communication.

Thanks for your patience while working on fixing this.

[PaWill68]

HKJ, this is version V4 202007 (there is still V4 20191111)
Huge gratitude for the work and patience !!! Sorry if I was so annoying.

[PaWill68]

HKJ, today I'm doing my first full battery test. I notice a difference in the voltage and capacitance readings on the device and in the TC. This is apparently due to the difference in requests.
It is better to receive all data in one request, and not in separate ones (0x0122, 0x0126). Is it possible to implement this?

[HKJ]

HKJ, today I'm doing my first full battery test. I notice a difference in the voltage and capacitance readings on the device and in the TC. This is apparently due to the difference in requests.
It is better to receive all data in one request, and not in separate ones (0x0122, 0x0126). Is it possible to implement this?

It is probably not possible to receive all data in one request, but TC will get the data as fast as the device support (When not in debug mode).
Another reason for small differences can be number of digits, the device may use more digits internally that can be read from the interface or the other way around (It depends on the device).
For capacity and energy readings there may also be difference in clock speed, TC is based on the Windows clock, the device has it own clock that may not be as precise.

[PaWill68]

This is an excerpt from the user manual. Just take into account the change in CRC. Perhaps it would be more correct.

5.Read actual voltage and current:
Send instruction: 01 03 03 00 00 00 8E 45
It is a special instruction, which facilitates reading the common data register bank at one time.
01: equipment address.
03: read the instruction number of register.
03 00 : read the special defined address of the common register bank.
00 00 : it can be any value, because it is senseless in this special instruction.
8E 45: check code. The high order is before the low order.
Load return data: 01 03 30 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17 D18 CRCH CRCL
Hereinto, D1 to D18 are valid data.
D1.0 is ON/OFF bit, D1.1-D1.2 is mode bit
D3-D5 is the actual voltage value (unit mV), which is three bytes 24 bit data with the high order is before the low order.
D6-D8 is the actual current value, which is three bytes 24 bit data with the high order is before the low order..

[HKJ]

This is an excerpt from the user manual. Just take into account the change in CRC. Perhaps it would be more correct.

Ok, they have implement a special instruction to read everything.
It is not really needed, at 115200 baud it takes about 0.01 second to read the two registers and at 9600 it takes about 0.1 second, assuming the load is fairly fast to answer. Even a very fast battery discharge, say 15 minutes is about 1000 second, a 0.1 second difference in reading values is completely insignificant, other errors will be way larger.

Looking on the some documentation I have found for the Kunkin, it looks like it is possible to read it power, you can try with the command:
holdingL? 0x0122 /1000

If this correctly gives the power reading I can fairly easy add it to the definition. It will not help with capacity summations, that only uses current and time.

[PaWill68]

Another reason for small differences can be number of digits, the device may use more digits internally that can be read from the interface or the other way around (It depends on the device).

The difference in the data is likely due to ripple and mismatched sampling times.
https://www.eevblog.com/forum/testgear/an-investigation-about-ripple-current-of-kunkin-kp184/

Looking on the some documentation I have found for the Kunkin, it looks like it is possible to read it power, you can try with the command:
holdingL? 0x0122 /1000

Yes, I can do it a little later.

[HKJ]

The difference in the data is likely due to ripple and mismatched sampling times.

Voltage is not used during capacity calculations, i.e. mismatch between voltage and current cannot affect it. You can control how fast TestController samples from the load, it can run 100 samples/sec (0.01s), but the load can probably not run that fast (TC will automatic reduce sample rate to highest sustainable rate). Generally you do not have to worry much about the number of samples, TC can handle millions if you have enough memory.
TC uses double precision internally for all calculations, this is about 18 digits of precision and usually avoids any problems with rounding errors.