Program that can log from many multimeters.

[PaWill68]

I understand.
The display shows 000.40

holdingL? 0x0122 /1000
;; COM11: Flush:
;; COM11: Tx: 01 03 01 22 00 04 E5 FF
;; COM11: Rx: 01 03 04 00 00 0F A4 FE 78
;; 4.0040000000000004

[HKJ]

I understand.
The display shows 000.40

holdingL? 0x0122 /1000
;; COM11: Flush:
;; COM11: Tx: 01 03 01 22 00 04 E5 FF
;; COM11: Rx: 01 03 04 00 00 0F A4 FE 78
;; 4.0040000000000004

Do not look like power, the documentation listed it as either VA or voltage measurement from 40V range, I believe the 40V range is the correct answer, even though it is meaningless to show it when there is another field from the 150V range with the same resolution.

[PaWill68]

Sorry, I was wrong. This is the display capacity.
The display shows 03.985

holdingL? 0x0122 /1000
;; COM11: Flush:
;; COM11: Tx: 01 03 01 22 00 04 E5 FF
;; COM11: Rx: 01 03 04 00 00 0F 91 3E 6F
;; 3.985

[HKJ]

Sorry, I was wrong. This is the display capacity.
The display shows 03.985

holdingL? 0x0122 /1000
;; COM11: Flush:
;; COM11: Tx: 01 03 01 22 00 04 E5 FF
;; COM11: Rx: 01 03 04 00 00 0F 91 3E 6F
;; 3.985

Now I am a bit confused, you say the command shows capacity?

[PaWill68]

For power data, another command. Perhaps there is no command for the data power.

U MEASURE   0x0122   4   R   0-150000   电压测量值，单位mV，量程150V
VA MEASURE   0x0124   4   R   0-40000   电压测量值，单位mV，量程40V
I MEASURE   0x0126   4   R   0-30000   电流测量值，单位mA，

BATT_CAPACITY   0x0148   4   R      电池放电容量测试结果，单位为AH或WH


holdingL? 0x0148
;; COM11: Flush:
;; COM11: Tx: 01 03 01 48 00 04 C5 E3
;; COM11: Rx: 01 03 04 00 21 D7 48 F5 FF
;; 2217800

[HKJ]

For power data, another command.

Code: [Select]

VA MEASURE	0x0124	4	R	0-40000	电压测量值，单位mV，量程40V

It was that address I meant, the 122 was a typo.

For 148 my documentation says: Battery discharge capacity test result, the unit is AH or WH   
And it is probably only valid when load is configured to do battery discharge

It is easy to add a command to read any register, but for logging I only want register that always contains relevant data.

A command definition looks like this:

#scpiCmd VoltageM? holdingL? 0x0122 /1000

The M means measured value, the question mark must be present because it returns a value, the 122 is the register number and the /1000 is the adjustment to SI unit.
If you have some suggestions for more command, please test them carefully and then post them here. Defining commands removes the need to remember register number and command names are listed in the help array, making it easy to find it.

[HKJ]

I anybody want my list of registers I can put it on my server (Temporary). I found it somewhere on the internet, but I do not remember the link.

It has lines like this (From row 2 to 47) and is in .xls format:
Fail_Alarm   0x018A   1   R/W   0,1,2   比较结果为FAIL时输出的信号   Signal output when the comparison result is FAIL   

[PaWill68]

I'm a little confused. What command should I execute?

[HKJ]

I'm a little confused. What command should I execute?

None, but if you want more command/registes supported, you can define them, test them and then list them for inclusion in the next release.

[PaWill68]

Sorry, I do not speak English and did not understand you well. I will reverse engineer when I have free time.
Another question. Can TC be done with other languages?

[HKJ]

Another question. Can TC be done with other languages?

No, I did not design it with a language table or with extra space for words in other languages.
Anyway most test equipment use english, i.e. you must understand some english words to use the test equipment.

[PaWill68]

In general, I figured out how what works. Basic commands for reading all parameters:
holding? 0x0300
holding? 0x0301
The point is that TC does not form them very correctly. Should accordingly be:
holding? 0x0300 >>> 01 03 03 00 00 20 44 56
holding? 0x0301 >>> 01 03 03 01 00 0C 14 4B
Because of this, everything has slowed down so far. Is there a way to fix it?

[HKJ]

In general, I figured out how what works. Basic commands for reading all parameters:
holding? 0x0300
holding? 0x0301
The point is that TC does not form them very correctly. Should accordingly be:
holding? 0x0300 >>> 01 03 03 00 00 20 44 56
holding? 0x0301 >>> 01 03 03 01 00 0C 14 4B
Because of this, everything has slowed down so far. Is there a way to fix it?

TC strips the protocol layer and only returns the actual value, simple scaling can be done in the same command, but you can also do some more advance processing on the value (Using :readmath:, see my documentation), but that gets fairly complicated quickly.

[PaWill68]

Ok. Besides the answer to the holding team? 0x0301 should return 37 bytes and now returns 36 bytes. This is how I see it in TC.

[PaWill68]

Code: [Select]

Read actual voltage and current (0x0300):
Send instruction: 
01 03 03 00 00 20 44 56

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

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..
D9-D11 Dynamic A load current value, unit mA
D12-D13 Dynamic A load maintenance time, unit mS
D14-D16 Dynamic B load current value, unit mA
D17-D18 Dynamic B load maintenance time, unit mS


--------------------------
Read actual parameters when testing the battery (0x0301):
Send instruction:
01 03 03 01 00 0C 14 4B

Load return data:
(01 03 1F D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17 D18) D19 D20 D21 D22 D23 D24 D25 D26 D27 D28 D29 D30 D31 D32 CRCH CRCL
|-- -- --|--|--|voltage |current |-- --  -- |--  -- |--  --  -- |--  --  |-- |-- |-- |voltage end|--     Ah   -- |--    Wh    -- |--  |--  |

D19 When the discharge reaches the termination voltage, whether the current drops to half to continue discharging, 0 is no, 1 is yes
D20 The discharge capacity calculation unit is 0 for AH and 1 for WH
D21 Discharge end output signal: 0 beeps once, 1 always beeps, 2 output level
D22-D24 Battery discharge end voltage, unit mV
D25-D28 Battery discharge capacity test result, the unit is AH
D29-D32 Battery discharge capacity test result, the unit is WH

It remains to figure out how to translate capacity and power into normal decimal digits. Simple translation HEX> DEC doesn't work.

[HKJ]

Ok. Besides the answer to the holding team? 0x0301 should return 37 bytes and now returns 36 bytes. This is how I see it in TC.

TC do not support that message, it uses another format compared to the regular messages and not only for the data, but also for the frame around the data.
I could fix that, but next problem would be the command, it works on in 4 byte steps (holdingL? version) and the answer do not conform to that. Using the "holding?" could work (if the frame worked) and would return 9 answering values.

[PaWill68]

TC do not support that message

In general, this is not a disaster. Only the end of the CRC is truncated, the data seems to arrive intact

I get the following data from KunkinSW
01 03 1F 03 05 00 0D C1 00 07 D0 00 07 D0 00 FA 00 FA 00 07 D0 00 00 00 00 0A F0 00 09 C4 00 00 22 A3 C8 A6 1B
Where
00 09 C4 00 = ~ 0.178Ah
00 22 A3 C8 = ~ 0.63Wh
How are these values obtained? Normal HEX> DEC doesn't work. (I tried in windows calculator)

[HKJ]

I get the following data from KunkinSW
01 03 1F 03 05 00 0D C1 00 07 D0 00 07 D0 00 FA 00 FA 00 07 D0 00 00 00 00 0A F0 00 09 C4 00 00 22 A3 C8 A6 1B
Where
00 09 C4 00 = ~ 0.178Ah
00 22 A3 C8 = ~ 0.63Wh
How are these values obtained? Normal HEX> DEC doesn't work. (I tried in windows calculator)

All the other messages uses long integers in a scaled format, this means I would expect something like 178mAh or 1780*0.1mAh or 17800*0.01mAh
But it do not match the message.
You can fairly easy check for this by opening the calculator popup, select hex format and then type in the number, it will show the expected hex string:

[PaWill68]

Now I remember. I was making a config file for East Tester ET5410.txt. Unfortunately this device is now damaged and it will probably be repaired. I haven't done all the functions, but the basic settings are fine. You can edit who wants.

[HKJ]

Now I remember. I was making a config file for East Tester ET5410.txt. Unfortunately this device is now damaged and it will probably be repaired. I haven't done all the functions, but the basic settings are fine. You can edit who wants.

Do you mean that everything in the file works or only some of the stuff in the file works?

[PaWill68]

Do you mean that everything in the file works or only some of the stuff in the file works?

The file is working. The "LIST" mode is not implemented

[HKJ]

I could see I already have ET5410 with a simple definition, I have replaced it with the one you posted here.

[PaWill68]

I did not find examples of how to split the resulting string of 36 bytes and take the desired values and convert to dec. Can you write an example?

[HKJ]

I did not find examples of how to split the resulting string of 36 bytes and take the desired values and convert to dec. Can you write an example?

You will not get a 36 bytes answer, but a list of integers, you can see that when using it from the command line.

I am working on adding a "bytes" type that can be used for that type of answer, but I would also need a special holdingxxx? command to return it as a answer. This also include functions to extract any number of bytes and you can easily typecast them to integers.
But all that is for the next release.

[PaWill68]

Okay. In outgoing packets from the com-port, I see packets bytes, that's why I named it that way.