Good day!
In the GuruxDLMSClientExample example, the application is launched with the parameters - IP, port, as well as the parameter 'o' - OutputFile (as I understand the file with DLMS meters objects)
Is there an example of the application launch line and this file (any) for Windows? This would make learning code easier.
thanks
We made a test case like this and it worked without problems. Can you send a full trace where are all the messages so I can check what is happening? Are you using DLMS client example or have you modify the source code?
I tried it in the original version of the client - it didn't work (log in the last post). I don't understand how this version of the client can work - shouldn't the request ID change with each new request? This can only work if there was a loss of DEVICE REQUEST, but not a loss of DEVICE RESPONSE
Tried it differently (message with code from August 7). Now I tried to transfer this option to the client - it also does not work. Log and code on the link: https://drive.google.com/uc?export=download&id=1ajIV7EY0YbhmOY3854APppR…
I take the latest version of the client form GitHub.
Added code like this to poll time:
CGXDLMSClock* ClockObject = new CGXDLMSClock("0.0.1.0.0.255");
ret = comm.InitializeConnection();
for (;;)
{
std::string st;
comm.Read(ClockObject, 2, st);
}
I started it. Cut the connection - the poll got up completely. There weren't even any attempts. Log and code - at the same link. https://drive.google.com/uc?export=download&id=1ajIV7EY0YbhmOY3854APppR…
Connection to the meter fails. When you try to read clock value meter returns invalid data, but HDLC frame is complete.
Check why connection fails and try again.
Good.
I understand correctly, if was a break in communication (even a short-term one), then it is better to close the session, open it again and only then try to interrogate the parameter again?
You need to start the session again if there is a break on the communication channel.
If there is a break in the communication it might be that it's not possible to establish connection to the meter right away. If the next connection fails there is an inactivity timeout and you need to wait until that time is past before next connection success.
As I understand it, DLMS uses the start and end character of the packet - 7E. This symbol may be in the middle of a packet?
I am trying to read the archive using range reads, and I get the following response request:
Read OBIS 1.0.99.1.0.255. Record Start 2017.12.15 17:0:0 End 2017.12.15 19:0:0
Tx: [0081] 7E A0 4F 00 02 14 85 03 54 CE 8C E6 E6 00 C0 01 82 00 07 01 00 63 01 00 FF 02 01 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 E1 0C 0F B5 11 00 00 FF FF 10 80 09 0C 07 E1 0C 0F 05 13 00 00 FF FF 10 80 01 00 E7 EF 7E
Rx: [0142] 7E A8 8C 03 00 02 14 85 74 72 F0 E6 E7 00 C4 02 82 00 00 00 00 01 00 81 9F 01 03 02 19 09 0C 07 E1 0C 0F 05 11 00 00 00 80 00 00 06 00 00 00 00 06 00 02 19 7E 06 00 01 9E C5 06 00 00 45 5E 06 00 00 00 3A 06 00 00 00 00 06 00 00 00 00 06 00 00 00 1B 06 00 00 00 00 06 00 00 00 00 06 00 00 00 00 06 00 00 00 00 06 00 02 19 7E 06 00 00 00 00 06 00 00 00 00 06 00 00 00 00 06 00 01 9E C5 06 00 00 00 00 06 00 00 00 00 06 A4 E2 7E
In the middle of frame 7E. At the same time, there is no such thing in earlier packages.
Is this a device error?
P.S. I am using my own function of receiving and transmitting packets.
Hi,
Hi,
We made a test case like this and it worked without problems. Can you send a full trace where are all the messages so I can check what is happening? Are you using DLMS client example or have you modify the source code?
BR,
Mikko
I tried it in the original
I tried it in the original version of the client - it didn't work (log in the last post). I don't understand how this version of the client can work - shouldn't the request ID change with each new request? This can only work if there was a loss of DEVICE REQUEST, but not a loss of DEVICE RESPONSE
Tried it differently (message with code from August 7). Now I tried to transfer this option to the client - it also does not work. Log and code on the link:
https://drive.google.com/uc?export=download&id=1ajIV7EY0YbhmOY3854APppR…
Hi,
Hi,
You have modified the source code. This is not the original client example. When read failed you do something and HDLC frame address is wrong.
The current example can handle the loss of device requests and responses.
Check your changes.
BR,
Mikko
I take the latest version of
I take the latest version of the client form GitHub.
Added code like this to poll time:
CGXDLMSClock* ClockObject = new CGXDLMSClock("0.0.1.0.0.255");
ret = comm.InitializeConnection();
for (;;)
{
std::string st;
comm.Read(ClockObject, 2, st);
}
I started it. Cut the connection - the poll got up completely. There weren't even any attempts. Log and code - at the same link.
https://drive.google.com/uc?export=download&id=1ajIV7EY0YbhmOY3854APppR…
Hi,
Hi,
Connection to the meter fails. When you try to read clock value meter returns invalid data, but HDLC frame is complete.
Check why connection fails and try again.
BR,
Mikko
Good.
Good.
I understand correctly, if was a break in communication (even a short-term one), then it is better to close the session, open it again and only then try to interrogate the parameter again?
Hi,
Hi,
You need to start the session again if there is a break on the communication channel.
If there is a break in the communication it might be that it's not possible to establish connection to the meter right away. If the next connection fails there is an inactivity timeout and you need to wait until that time is past before next connection success.
BR,
Mikko
As I understand it, DLMS uses
As I understand it, DLMS uses the start and end character of the packet - 7E. This symbol may be in the middle of a packet?
I am trying to read the archive using range reads, and I get the following response request:
Read OBIS 1.0.99.1.0.255. Record Start 2017.12.15 17:0:0 End 2017.12.15 19:0:0
Tx: [0081] 7E A0 4F 00 02 14 85 03 54 CE 8C E6 E6 00 C0 01 82 00 07 01 00 63 01 00 FF 02 01 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 E1 0C 0F B5 11 00 00 FF FF 10 80 09 0C 07 E1 0C 0F 05 13 00 00 FF FF 10 80 01 00 E7 EF 7E
Rx: [0142] 7E A8 8C 03 00 02 14 85 74 72 F0 E6 E7 00 C4 02 82 00 00 00 00 01 00 81 9F 01 03 02 19 09 0C 07 E1 0C 0F 05 11 00 00 00 80 00 00 06 00 00 00 00 06 00 02 19 7E 06 00 01 9E C5 06 00 00 45 5E 06 00 00 00 3A 06 00 00 00 00 06 00 00 00 00 06 00 00 00 1B 06 00 00 00 00 06 00 00 00 00 06 00 00 00 00 06 00 00 00 00 06 00 02 19 7E 06 00 00 00 00 06 00 00 00 00 06 00 00 00 00 06 00 01 9E C5 06 00 00 00 00 06 00 00 00 00 06 A4 E2 7E
In the middle of frame 7E. At the same time, there is no such thing in earlier packages.
Is this a device error?
P.S. I am using my own function of receiving and transmitting packets.
Hi,
Hi,
0x7E is the end and start char of the packet. Data can also contain 0x7E and it's quite common and it's not a meter issue.
BR,
Mikko