I launched gurux.dlms.python/Gurux.DLMS.Client.Example.python
I have an Itron Actaris SL7000 meter connected via RS485 via an RS485-Net converter.
I connected, I read the registers, but the reading takes place from 8-12 attempts:
python3 main.py -r ln -c 1 -s 17 -l 1 -h xx.xx.xx.xx -p xxxx -a Low -P ABCDEFGH -g "1.1.91.7.0.255:1; 1.1.91.7.0.255:2; 1.1.91.7.0.255:3; 0.0.40.0.0.255:1; 0.0.40.0.0.255:4; 1.1.92.7.0.255:1; 1.1.92.7.0.255:2; 1.1.92.7.0.255:3" -d DLMS -t Info -C None
gurux_dlms version: 1.0.105
gurux_net version: 1.0.17
gurux_serial version: 1.0.15
Authentication: Authentication.LOW
ClientAddress: 0x1
ServerAddress: 0x91
Standard: Standard.DLMS
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Data send failed. Try to resend 1/3
Unknown object : 46 0.0.25.5.0.255
Index: 1 Value: 1.1.91.7.0.255
Index: 2 Value: 405
Index: 3 Value: 0.001, Unit.CURRENT
Index: 1 Value: 0.0.40.0.0.255
Index: 4 Value: 2 16 756 5 8 1 1
Data send failed. Try to resend 1/3
Index: 1 Value: 1.1.92.7.0.255
Index: 2 Value: 2267
Index: 3 Value: 0.1, Unit.VOLTAGE
DisconnectRequest
Ended. Press any key to continue.
What am I doing wrong that many times there is a connection attempt:
Data send failed. Try to resend 1/3
And second question:
If I not write "-l 1" - does not connection, and "ServerAddress: 0x11".
If I write "-l 1" - there is a connection, and "ServerAddress: 0x91"!!!
Why?
gurux_dlms version: 1.0.105
gurux_net version: 1.0.17
gurux_serial version: 1.0.15
Authentication: Authentication.LOW
ClientAddress: 0x1
ServerAddress: 0x11
Standard: Standard.DLMS
Data send failed. Try to resend 1/3
Data send failed. Try to resend 2/3
RX: 10:28:32
Traceback (most recent call last):
File "main.py", line 88, in main
reader.initializeConnection()
File "/root/gurux.dlms.python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 307, in initializeConnection
self.readDLMSPacket(data, reply)
File "/root/gurux.dlms.python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 119, in readDLMSPacket
self.readDLMSPacket2(data, reply)
File "/root/gurux.dlms.python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 169, in readDLMSPacket2
raise e
File "/root/gurux.dlms.python/Gurux.DLMS.Client.Example.python/GXDLMSReader.py", line 162, in readDLMSPacket2
raise TimeoutException("Failed to receive reply from the device in given time.")
gurux_common.TimeoutException.TimeoutException: Failed to receive reply from the device in given time.
Ended. Press any key to continue.
You are not doing anything wrong. Data send failed. Try to resend 1/3 is coming because your PC is so fast and the meter can't handle all incoming requests. You can use -o output.xml to save association view to the XML file. It makes reading faster.
Your meter is using also the Logical device address and if you don't give it with -l parameter, the meter doesn't reply, because the server address is wrong.
Meters are using different server addresses and you can even change it. Problem here is that the meter doesn't answer anything if the meter address is wrong.
So the script sends a request several times until the counter responds. And he answers, the data is received. But in DLMS.Director, the connection is formed instantly and reading is also instantaneous and without errors. In DLMS.Director everything is much faster!
There might be re-sending in GXDLMSDirector. You can check them from the log file. It's common that meters don't reply to all requests. It depends on the communication channel and if the communication channel is bad, this is happening quite often.
I started Client.Example in C ++ and saw that it uses the method GetAssociationView and it reads the association view of all objects even I read one/two of them! I guess that this is the register read latency. While the counter transfers all objects, the client cannot read the register value. Therefore, this error and delay exists.
Hi,
Hi,
You are not doing anything wrong. Data send failed. Try to resend 1/3 is coming because your PC is so fast and the meter can't handle all incoming requests. You can use -o output.xml to save association view to the XML file. It makes reading faster.
Your meter is using also the Logical device address and if you don't give it with -l parameter, the meter doesn't reply, because the server address is wrong.
Meters are using different server addresses and you can even change it. Problem here is that the meter doesn't answer anything if the meter address is wrong.
BR,
Mikko
So the script sends a request
Thanks for the answer.
So the script sends a request several times until the counter responds. And he answers, the data is received. But in DLMS.Director, the connection is formed instantly and reading is also instantaneous and without errors. In DLMS.Director everything is much faster!
With counter addressing, I got it!
Hi,
Hi,
There might be re-sending in GXDLMSDirector. You can check them from the log file. It's common that meters don't reply to all requests. It depends on the communication channel and if the communication channel is bad, this is happening quite often.
BR,
Mikko
I started Client.Example in C
I started Client.Example in C ++ and saw that it uses the method GetAssociationView and it reads the association view of all objects even I read one/two of them! I guess that this is the register read latency. While the counter transfers all objects, the client cannot read the register value. Therefore, this error and delay exists.
And your advice with the -o
And your advice with the -o output.xml parameter helped a lot. Now the counter responds immediately and there is no delay.
Thank you, Mr Kurumi.
Hi,
Hi,
I'm glad that the saving association view helped.
BR,
Mikko