We are interested to implement a communication profile based on the protocol Prime through PLC (check the scheme in the picture attached).
Like we know when using the serial communication or TCP-UDP we are choosing the interface HDLC in the gurux client as protocol of communication. The connection starts always by an SNRM request from the client followed by an UA frame from the server then the AARQ and AARE (application layer).
In case we want to implement the Prime PLC, do you have any idea and information about the interface we should use? what are the requested step to do before reaching the DLMS/COSEM application layer AARQ and AARE? Do you intend to implement any of this protocol?
We are appreciating all the work you are doing and we actually know the load of work that you are handling.
But, we really need to know about the pre-alpha version that is covering the PLC protocol :
- status of the task : working on it or not?
- time (approximation) : when you will be able to release it?
We are waiting for your kind answer the soonest due to deadlines.
In addition, we would be more than happy and ready to support and test this pre-alpha version.
We want to know if the first version will cover the both sides (server and client) ?
One more question, will this version cover LLC (logic link control) which may include one of the following protocols (IEC61334-4-32, IPV4, IPV6 ...) or none of them ?
The idea was to release last week, but we find an issue with it and tests are in progress. We'll release support for IEC 61334-4-32 and IEC 61334-5-1 in next week. First, it is coming to GXDLMSDirector and C#. After that for other programming languages.
Everything looks good. The test has passed and we are releasing a new version from GXDLMSDirector on Monday. We try to release this to other programming languages as soon as tests are over for them. Implementation is done for all the programming languages.
We read the documentation page and we will start the detailed testing on Monday, while waiting the release for the server example in C.
Meanwhile, we did notice a bug : when trying to add a normal device and choose the "HDLC" as interface, we try directly to re-open again the properties of the device to check and we realize that the interface changed automatically and alone to "HdlcWithModeE" as interface. We are not able to test the normal serial hdlc protocol due to this.
We tried the new release of the GXDLMSDirector, and the above bug is fixed but we have 2 new bugs:
1- When we choose the HDLC and try to connect with the server, we realize by looking to the logs that the client is sending "IEC Sending:/?!<CR><LF>" instead of sending the snrm request. The HDLC interface is acting like HdlcWithModeE interface.
2- When the client and server are connected and we want to disconnect them, we realized that the disconnected pdu is not sent anymore.
But we noticed that you released the old version of the GXDLMSDirector, is there any major problem?
1- We downloaded the new version and the hdlc communication worked like expected from connection to disconnection
2- We were able to connect using the HdlcWithModeE interface, but when we want to disconnect the pdu is not even sent. The disconnection is working in the hdlc but not in the HdlcWithModeE
We are very thankful and grateful for your hard work.
We downloaded the new version and tested. The communication through hldc and HdlcWithModeE are now working like expected from connection to disconnection.
However, there is a special scenario that we want to ask you about to see if it is normal or not.
In fact, when we connect a device for the first time with none authentication level, it will read all the list of objects. After that we can access all the objects with access level only read. After that, we disconnected and change the authentication to high then connect again. We expected to have the high authentication access level (to read, to write and to trigger the method), but instead of that we are stocked in the none authentication access level (only to read). Is it normal?
We noticed that if we want to have the high authentication access level, we should use the high authentication the first time we connect to the meter and read the object list. After that if we change to the none authentication it worked like expected so we can switch between the authentication level without any problem.
This is normal. You need to read the association view again if you change the authentication level.
Association view was automatically read from the meter when the authentication level was changed, but there are meters that support the authentication level only without authentication.
If the authentication level is something else than None, the meter can't give association view. It's sad that we need to fix meter issues on the client-side.
Sometimes there might be a different amount of objects when the authentication level is changed and usually access right change.
Refresh association view every time when you change the authentication level.
By refreshing the association view every time when we change the authentication level, do you mean to create again the device, connect and read the list of objects or is there another way?
We downloaded the latest version of GXDLMSDirector and we faced a very weird and dangerous issue.
After connecting, we tried to read, write and trigger some methods, everything looked fine. However, when we tried to set the current time through the clock object, the GXDLMSDirector is totally crashing like you can see in the attached picture. The connected device disappeared and the director wasn't responding anymore.
We tried to follow the writing process of the clock time on the server side, everything looked good. So we thought that the problem was from the client side.
The last PDU sent by the client before crashing was:
7E A0 27 03 25 58 E3 91 E6 E6 00 C1 01 C1 00 08 00 00 01 00 00 FF 02 00 09 0C 07 E4 0B 10 FF 10 30 14 FF FF 88 00 85 10 7E
Can you please check the possible reason behind this major issue?
Can we have access for an older GXDLMSDirector version so we can test if the problem is coming from the new release or not?
We found the problem creating this crashing. In fact, we are sending an event notification using the sendEventNotification function each time when we write the clock. So most probably the server is sending an event notification and the new release of the GXDLMSDirector is not supporting this so it is crashing.
Plus, we did notice that the window showing the message sent by the server as event notification has disappeared in the GXDLMSDirector.
Can you please add support of the event notification in the new release? Meanwhile can you share with us the older version of the GXDLMSDirector?
We are using the sendEventNotification to transmit the message through serial. We were able to narrow the problem. In fact, when we were transmitting the event notification message the same message was sent continuously like you can see in the picture. The unstoppable sending message is causing the crashing of the GXDLMSDirctor.
Can you check if this problem is due to the client?
Is the function sendEventNotification working fine on your side? If yes, we will conclude that the problem is coming from the server side.
If you are sending the same push message in a loop like in your pic it will cause problems for the client. You need to change this and send push message(s) only once or max a few times.
We think that you got us wrong. In fact, we are sending the above push message one time only. To be sure of that, we sent the push message on an another com port and watched through Docklight the transmission instead of sending it on the same port using to communicate with the client. The push message is send only once like expected. This assured that the problem is coming from the client side not the server side.
When we tried to send this same message once to the GXDLMSDirector, it was like it is blocking in a loop and the same message appeared repeatedly in the event notification dialog leading to the crashing of the GXDLMSDirector. It seemed like the server is sending the message multiple time but in reality (like described in the test above) we are sure that the push message is sent only one time from the server side.
If you need more information to solve this issue don't hesitate.
We will appreciate if you can share with us the older version of the GXDLMSDirector so we can test and see if the problem is due to the new release.
We are checking again if the problem is arising from our side. What do you mean by this question "Can you add raw bytes from the push message here? "? can you explain it because we did not understand?
There is a trace from the received bytes in the pic above. Because the pic is compressed, I can't read the bytes. Can you add one push message from the notification view to here so we can check it.
Hi,
Hi,
PLC is on the work-list. We can generate PLC messages and parse them, but this need to be tested.
BR,
Mikko
Hi,
Hi,
We are ready and very interested to help you in testing the PLC messages.
Best Regards,
Lara Wakim
Hi,
Hi,
We talk if it's possible to release the Pre-alpha version from this.
BR,
Mikko
Hi,
Hi,
Any update concerning the release of the pre-alpha version?
We will be more than happy to help you in the testing phase.
Best Regards,
Lara Wakim
Hi,
Hi,
I am sorry to bother you, but do you have any updates concerning this topic?
Best Regards,
Lara Wakim
Hi Mikko,
Hi Mikko,
We are appreciating all the work you are doing and we actually know the load of work that you are handling.
But, we really need to know about the pre-alpha version that is covering the PLC protocol :
- status of the task : working on it or not?
- time (approximation) : when you will be able to release it?
We are waiting for your kind answer the soonest due to deadlines.
In addition, we would be more than happy and ready to support and test this pre-alpha version.
Best Regards,
Lara Wakim
Hi Lara,
Hi Lara,
We are planning to release the first version from PLC in begin of October.
BR,
Mikko
Hello,
Hello,
We want to know if the first version will cover the both sides (server and client) ?
One more question, will this version cover LLC (logic link control) which may include one of the following protocols (IEC61334-4-32, IPV4, IPV6 ...) or none of them ?
Best Regards,
Lara Wakim
Hi,
Hi,
IPV6 and IPv4 are using IEC 62056-47. They are already implemented. Interface type is WRAPPER.
We are testing S-FSK PLC (IEC 61334-4-32) parser at the moment.
BR,
Mikko
Hi Mikko,
Hi Mikko,
We expected that the new release cover this feature "S-FSK PLC (IEC 61334-4-32)" but we realized that it wasn't included.
Are you still planning to release the first version from PLC in begin of October like you told us or there is any problem?
Best Regards,
Lara Wakim
Hi,
Hi,
The idea was to release last week, but we find an issue with it and tests are in progress. We'll release support for IEC 61334-4-32 and IEC 61334-5-1 in next week. First, it is coming to GXDLMSDirector and C#. After that for other programming languages.
BR,
Mikko
Hi,
Hi,
We are glad to hear that. We will surely be here to help you in the testing phase when released.
Best Regards,
Lara Wakim
Hi Mikko,
Hi Mikko,
Do you have any update concerning the release supporting the PLC IEC 61334-4-32?
Best Regards,
Lara Wakim
Hi,
Hi,
Everything looks good. The test has passed and we are releasing a new version from GXDLMSDirector on Monday. We try to release this to other programming languages as soon as tests are over for them. Implementation is done for all the programming languages.
BR,
Mikko
Hi,
Hi,
We are really happy to hear that. Thank you for your hard work.
We will surely be here to test and give you our feedbacks.
Best Regards,
Lara Wakim
Hi,
Hi,
There is an own page for PLC.
https://www.gurux.fi/PLC
We are starting to release PLC for other programming languages and C# in next week.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Thank you for your hard work.
We read the documentation page and we will start the detailed testing on Monday, while waiting the release for the server example in C.
Meanwhile, we did notice a bug : when trying to add a normal device and choose the "HDLC" as interface, we try directly to re-open again the properties of the device to check and we realize that the interface changed automatically and alone to "HdlcWithModeE" as interface. We are not able to test the normal serial hdlc protocol due to this.
Best Regards,
Lara Wakim
Hi,
Hi,
Tests have started for ANSI C++. We try to release both ANSI C++ and ANSI C in this week.
This bug is fixed and we are testing it at the moment. A new version is released today fro GXDLMSDirector.
BR,
Mikko
Hi,
Hi,
We tried the new release of the GXDLMSDirector, and the above bug is fixed but we have 2 new bugs:
1- When we choose the HDLC and try to connect with the server, we realize by looking to the logs that the client is sending "IEC Sending:/?!<CR><LF>" instead of sending the snrm request. The HDLC interface is acting like HdlcWithModeE interface.
2- When the client and server are connected and we want to disconnect them, we realized that the disconnected pdu is not sent anymore.
But we noticed that you released the old version of the GXDLMSDirector, is there any major problem?
Best Regards,
Lara Wakim
Hi,
Hi,
1. This is fixed. Restart GXDLMSDirector and it will install the new version.
2. Release should be sent. I'll check this and get back to you.
BR,
Mikko
Hi,
Hi,
1- We downloaded the new version and the hdlc communication worked like expected from connection to disconnection
2- We were able to connect using the HdlcWithModeE interface, but when we want to disconnect the pdu is not even sent. The disconnection is working in the hdlc but not in the HdlcWithModeE
Best Regards,
Lara Wakim
Hi,
Hi,
This is now solved. A new version is released tomorrow. I'm sorry about all the hassle.
BR,
Mikko
Hi Mikko,
Hi Mikko,
We are very thankful and grateful for your hard work.
We downloaded the new version and tested. The communication through hldc and HdlcWithModeE are now working like expected from connection to disconnection.
However, there is a special scenario that we want to ask you about to see if it is normal or not.
In fact, when we connect a device for the first time with none authentication level, it will read all the list of objects. After that we can access all the objects with access level only read. After that, we disconnected and change the authentication to high then connect again. We expected to have the high authentication access level (to read, to write and to trigger the method), but instead of that we are stocked in the none authentication access level (only to read). Is it normal?
We noticed that if we want to have the high authentication access level, we should use the high authentication the first time we connect to the meter and read the object list. After that if we change to the none authentication it worked like expected so we can switch between the authentication level without any problem.
Do you have any explanation to this scenario?
Best Regards,
Lara Wakim
Hi,
Hi,
This is normal. You need to read the association view again if you change the authentication level.
Association view was automatically read from the meter when the authentication level was changed, but there are meters that support the authentication level only without authentication.
If the authentication level is something else than None, the meter can't give association view. It's sad that we need to fix meter issues on the client-side.
Sometimes there might be a different amount of objects when the authentication level is changed and usually access right change.
Refresh association view every time when you change the authentication level.
BR,
Mikko
BR,
Mikko
Hi,
Hi,
By refreshing the association view every time when we change the authentication level, do you mean to create again the device, connect and read the list of objects or is there another way?
Best Regards,
Lara Wakim
Hi,
Hi,
Select "Refresh" from the "File" menu. It will read the association view again.
BR,
Mikko
Hi,
Hi,
We downloaded the latest version of GXDLMSDirector and we faced a very weird and dangerous issue.
After connecting, we tried to read, write and trigger some methods, everything looked fine. However, when we tried to set the current time through the clock object, the GXDLMSDirector is totally crashing like you can see in the attached picture. The connected device disappeared and the director wasn't responding anymore.
We tried to follow the writing process of the clock time on the server side, everything looked good. So we thought that the problem was from the client side.
The last PDU sent by the client before crashing was:
7E A0 27 03 25 58 E3 91 E6 E6 00 C1 01 C1 00 08 00 00 01 00 00 FF 02 00 09 0C 07 E4 0B 10 FF 10 30 14 FF FF 88 00 85 10 7E
Can you please check the possible reason behind this major issue?
Can we have access for an older GXDLMSDirector version so we can test if the problem is coming from the new release or not?
Best Regards,
Lara Wakim
Hello Mikko,
Hello Mikko,
We found the problem creating this crashing. In fact, we are sending an event notification using the sendEventNotification function each time when we write the clock. So most probably the server is sending an event notification and the new release of the GXDLMSDirector is not supporting this so it is crashing.
Plus, we did notice that the window showing the message sent by the server as event notification has disappeared in the GXDLMSDirector.
Can you please add support of the event notification in the new release? Meanwhile can you share with us the older version of the GXDLMSDirector?
Best Regards,
Lara Wakim
Hi,
Hi,
Thanks for this info. We were trying to repeat and it worked like expected.
Select "View" | "Notifications" and "Hex". Then you can see notifications.
Can you send a trace from the notification message so we can try to repeat this?
BR,
Mikko
Hi,
Hi,
We are using the sendEventNotification to transmit the message through serial. We were able to narrow the problem. In fact, when we were transmitting the event notification message the same message was sent continuously like you can see in the picture. The unstoppable sending message is causing the crashing of the GXDLMSDirctor.
Can you check if this problem is due to the client?
Is the function sendEventNotification working fine on your side? If yes, we will conclude that the problem is coming from the server side.
Best Regards,
Lara Wakim
Hi,
Hi,
If you are sending the same push message in a loop like in your pic it will cause problems for the client. You need to change this and send push message(s) only once or max a few times.
BR,
Mikko
Hello Mikko,
Hello Mikko,
We think that you got us wrong. In fact, we are sending the above push message one time only. To be sure of that, we sent the push message on an another com port and watched through Docklight the transmission instead of sending it on the same port using to communicate with the client. The push message is send only once like expected. This assured that the problem is coming from the client side not the server side.
When we tried to send this same message once to the GXDLMSDirector, it was like it is blocking in a loop and the same message appeared repeatedly in the event notification dialog leading to the crashing of the GXDLMSDirector. It seemed like the server is sending the message multiple time but in reality (like described in the test above) we are sure that the push message is sent only one time from the server side.
If you need more information to solve this issue don't hesitate.
We will appreciate if you can share with us the older version of the GXDLMSDirector so we can test and see if the problem is due to the new release.
Best Regards,
Lara Wakim
Hi Lara,
Hi Lara,
Can you add raw bytes from the push message here? We have tested this in several different ways and it works every time without problems.
BR,
Mikko
Hi,
Hi,
We are checking again if the problem is arising from our side. What do you mean by this question "Can you add raw bytes from the push message here? "? can you explain it because we did not understand?
Best Regards,
Lara Wakim
Hi,
Hi,
There is a trace from the received bytes in the pic above. Because the pic is compressed, I can't read the bytes. Can you add one push message from the notification view to here so we can check it.
BR,
Mikko
Hi,
Hi,
Yes sure, the push message of the pic above is:
7E A0 28 25 03 13 CC 7D E6 E7 00 C2 00 00 07 01 00 63 62 00 FF 02 01 02 19 07 E4 0B 12 03 0C 0B 25 00 00 00 00 11 80 C7 4A 7E
Another push message tested just right now:
7E A0 28 25 03 13 CC 7D E6 E7 00 C2 00 00 07 01 00 63 62 00 FF 02 01 02 19 07 E4 0B 18 02 0B 1A 02 00 00 00 00 11 80 D6 E6 7E
Best Regards,
Lara Wakim