This means the most likely reason is the handshake settings that I asked you to try before.
I tried both #subDriver Kunkinx and #subDriver RTU. Also ;#verifyDevice 1840 model? commented out. Without this, the connection is not established. I didn't notice the difference. No data is received from KP184. Did another data acquisition from KP184:
If you capture the message with #subDriver Kunkin and Kunkinx you will see the two crc bytes has swapped location.
Can't you see on the load if it accept the current setting?
Pressing the "Setup" button
;; Start thread for: COM11 - Kunkin KP184
;; COM11: Set params: 115200
;; COM11: Tx <mode?>
;; COM11: Tx <holdingL? 0x0110>
;; COM11: Tx: 01 03 01 10 00 04 30 44
;; COM11: Rx Timeout
;; Found Kunkin KP184 on USB2.0-Ser! (COM11)
;; KP184: Tx <on?>
;; KP184: Tx <holdingL? 0x010E>
;; COM11: Tx: 01 03 01 0E 00 04 36 24
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <mode?>
;; KP184: Tx <holdingL? 0x0110>
;; COM11: Tx: 01 03 01 10 00 04 30 44
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <current?>
;; KP184: Tx <holdingL? 0x0116 /1000>
;; COM11: Tx: 01 03 01 16 00 04 31 A4
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <current?>
;; KP184: Tx <holdingL? 0x0116 /1000>
;; COM11: Tx: 01 03 01 16 00 04 31 A4
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <voltage?>
;; KP184: Tx <holdingL? 0x0112 /1000>
;; COM11: Tx: 01 03 01 12 00 04 F0 E5
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <resistance?>
;; KP184: Tx <holdingL? 0x011A>
;; COM11: Tx: 01 03 01 1A 00 04 32 64
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <power?>
;; KP184: Tx <holdingL? 0x011E /10>
;; COM11: Tx: 01 03 01 1E 00 04 F3 25
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <remote?>
;; KP184: Tx <holdingL? 0x10a>
;; COM11: Tx: 01 03 01 0A 00 04 F7 65
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
Pressing the "Setup" button
;; Start thread for: COM11 - Kunkin KP184
;; COM11: Set params: 115200
;; COM11: Tx <mode?>
;; COM11: Tx <holdingL? 0x0110>
;; COM11: Tx: 01 03 01 10 00 04 30 44
That is not data from "Kunkin" or "Kunkinx" #subDriver[/code]
If you set #subDriver Kunkinx, then the current value is recorded.
Write 2A:
;; Start thread for: COM11 - Kunkin KP184
;; COM11: Set params: 115200
;; COM11: Tx <mode?>
;; COM11: Tx <holdingL? 0x0110>
;; COM11: Tx: 01 03 01 10 00 04 44 30
;; COM11: Rx Timeout
;; Found Kunkin KP184 on USB2.0-Ser! (COM11)
;; KP184: Tx <on?>
;; KP184: Tx <holdingL? 0x010E>
;; COM11: Tx: 01 03 01 0E 00 04 24 36
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <mode?>
;; KP184: Tx <holdingL? 0x0110>
;; COM11: Tx: 01 03 01 10 00 04 44 30
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <current?>
;; KP184: Tx <holdingL? 0x0116 /1000>
;; COM11: Tx: 01 03 01 16 00 04 A4 31
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <current?>
;; KP184: Tx <holdingL? 0x0116 /1000>
;; COM11: Tx: 01 03 01 16 00 04 A4 31
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <voltage?>
;; KP184: Tx <holdingL? 0x0112 /1000>
;; COM11: Tx: 01 03 01 12 00 04 E5 F0
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <resistance?>
;; KP184: Tx <holdingL? 0x011A>
;; COM11: Tx: 01 03 01 1A 00 04 64 32
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <power?>
;; KP184: Tx <holdingL? 0x011E /10>
;; COM11: Tx: 01 03 01 1E 00 04 25 F3
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <remote?>
;; KP184: Tx <holdingL? 0x10a>
;; COM11: Tx: 01 03 01 0A 00 04 65 F7
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <current 2.0>
;; KP184: Tx <holdingL 0x0116 2.0 *1000>
;; COM11: Tx: 01 06 01 16 00 01 04 00 00 07 D0 9D 0C
;; KP184: Tx <current?>
;; KP184: Tx <holdingL? 0x0116 /1000>
;; COM11: Tx: 01 03 01 16 00 04 A4 31
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <current?>
;; KP184: Tx <holdingL? 0x0116 /1000>
;; COM11: Tx: 01 03 01 16 00 04 A4 31
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
;; KP184: Tx <mode?>
;; KP184: Tx <holdingL? 0x0110>
;; COM11: Tx: 01 03 01 10 00 04 44 30
;; KP184: Rx Timeout
;; KP184: Rx as number <NaN>
If you set #subDriver Kunkinx, then the current value is recorded.
What do you mean by recorder? That the load see it?
If you set #subDriver Kunkinx, then the current value is recorded.
What do you mean by recorder? That the load see it?
KP184 accept the current value. Sorry, Google Translate
KP184 accept the current value. Sorry, Google Translate
That makes me suspect that you did not perform the handshake tests correctly:
9600N81dr
9600N81Dr
9600N81dR
9600N81DR
The letters D & R control the DTS and RTS lines, a lower case letter means signal low a upper case means signal high.
Where should I configure this?
Where should I configure this?
On the "Load devices" page in the baudrate field and remember to press Reconnect after doing any changes.
I tried all four options. I did not notice any changes. Data from KP184 does not come.
I tried all four options. I did not notice any changes. Data from KP184 does not come.
I do not really know what to do know. TC is obvious sending the correct messages and you have tested the different handshake possibilities.
One detail: Did you press ENTER after typing each baudrate, the value is not used before ENTER is pressed.
Yes, ENTER.
Can I make a full dump from the moment of connection and before pressing the "Setup" button?
Yes, ENTER.
Can I make a full dump from the moment of connection and before pressing the "Setup" button?
You get that in debug mode.
That's what the sniffer intercepts.
01030110000444300103040E000001391B0103010E000424360103040E000000F8DB01030110000444300103040E000001391B010301160004A431010304000007D0F99F010301160004A431010304000007D0F99F010301120004E5F001030400004E20CE4B0103011A0004643201030400000000FA330103011E000425F301030400000000FA330103010A000465F701030400000000FA33
I have checked all the #subDriver options. KP184 only responds if #subDriver Kunkinx is installed. If the driver is #subDriver Kunkin or #subDriver RTU, the KP184 does not respond to commands. Bitrate (9600N81dr,
9600N81Dr, 9600N81dR, 9600N81DR) has no effect. The same data is always sent and returned. I posted the dump in the previous post. TestConrtoller does not process the response from KP184.
I have checked all the #subDriver options. KP184 only responds if #subDriver Kunkinx is installed. If the driver is #subDriver Kunkin or #subDriver RTU, the KP184 does not respond to commands.
#subdriver Kunkin & Kunkinx uses a modified modbus protocol, originally Kunkin swapped the crc bytes, they fixed that in the new software and I changed it in Kunkinx
RTU is standard modbus protocol.
Bitrate (9600N81dr, 9600N81Dr, 9600N81dR, 9600N81DR) has no effect. The same data is always sent and returned. I posted the dump in the previous post. TestConrtoller does not process the response from KP184.
These setting do not affect the data, instead they change the handshake lines, some device wait for one of these signals before transmitting and some devices use these signals for power.
I do not verify checksum or anything on received data, i.e. any received data will be shown.
You probably don't understand me.
With the #subDriver Kunkinx protocol, the TC controls KP184 (switches modes, changes current and voltage) and KP184 sends a response. But the answer is not accepted by TC and is not displayed on the "Setup" panel and in the "Current values" section.
You probably don't understand me.
With the #subDriver Kunkinx protocol, the TC controls KP184 (switches modes, changes current and voltage) and KP184 sends a response. But the answer is not accepted by TC and is not displayed on the "Setup" panel and in the "Current values" section.
It do not make sense, I have not received any complains about modbus not working and all of the different #subdriver versions uses the same receive code (That is also shared with some other interfaces).
The serial library i use may fail on some os/hardware combinations, I do not keep track of exactly what it support (It do support many different combinations). But I doubt that is the problem here, because somebody else had problems with the Kunkinx driver (And it was the the right place to do a long test).
I can assume that the protocol for KP184 was changed again. I received the latest 2021 software from the vendor (1.0.13). Only this version is functional. There are 2019 (1.0.4) and 2020 (1.0.11) versions, but they don't work with KP184.
I remember something about KP184 and RS485 interface. I wonder if there is a directional control in the load controlled from the handshake lines.
Try:
9600N81DR
9600N81dr
And check if it is possible to send command to the load from TC with both settings.
Yesterday I ran tests with different values of 9600N81DR and 9600N81dr. Where can I see the changes from 9600N81DR and 9600N81dr?
The control for the electronic load is executed at any of their values. And also commands are sent on and off.
Today I ran comparison tests using a com port monitor for different programs (Kunkin, KP184 Modbus, TC). Can this data somehow help? For change mode CV>CC.
Question why can't TestController use one command to get all the data (for example: 0103030000204456) instead of 0x0122 and 0x0126.
Yesterday I ran tests with different values of 9600N81DR and 9600N81dr. Where can I see the changes from 9600N81DR and 9600N81dr?
The control for the electronic load is executed at any of their values. And also commands are sent on and off.
Today I ran comparison tests using a com port monitor for different programs (Kunkin, KP184 Modbus, TC). Can this data somehow help? For change mode CV>CC.
Question why can't TestController use one command to get all the data (for example: 0103030000204456) instead of 0x0122 and 0x0126.
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.
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.