In our project we did include a PLC SoC chip that integrates the prime protocol which contains ( IEC61334-4-32+MAC+physical medium CENELEC-A). The communication between this chip and our microcontroller are based on API functions; on other terms (primitives functions) stated in PRIME protocol. Using these primitives we can control the Mac registration, IEC432 registration (such as destination address, base address and device identifier...). The truth is that IEC61334-4-32 rapper exists on the PLC Soc modem chip and not where the gurux C server code is installed (on the MCU).
So to connect the missing dots the server example of gurux should send us raw DLMS data which should not encapsulate its packet to the IEC432 header, since the modem chip is adding the IEC432 layer to the packets.
1)Do we have the possibility to send from gurux client the DLMS/COSEM header without any LLC layer since we are adding this layer from our modem PLC Soc chip?!
2)How does the client discover new PLC connections is the packets sent from gurux client to the plc modem are API codes or DLMS+IEC432+MAC PDU header;
To summarize the last question what is the client and server stack for the last plc release?
1. If you change the Interface type to PDU plain PDU is sent. This feature is not implemented for ANSI C at the moment. I believe that padding is not expected. I'll add this to wok list. It's easy to add, but testing will take some time.
We are testing PLC for ANSI C and try to release it during this week.
We are also adding support for PLC PRIME, but tests will start for PRIME after two weeks.
2. When the modem sends received bytes to the client it will parse data and show available meters.
Hi!
Thank you very much for your fast reply. So by plain pdu you mean row DLMS data without any LLC layer am I correct ?
And regarding my second question the client will have the following stack (DLMS/COSEM + LLC layer(IEC61334-4-32 + MAC layer) and the physical layer will be the plc modem which should support the s-fsk modulation scheme right?
You only need to change the interface type to PDU. I just realize that it's not visible in GXDLMSDirector because it's not widely used. We'll add it and a new version is released next week.
You can try parser by yourself if you can get a trace from the PLC message.
Get send or received bytes as a hex string and then select "DLMS Translator" from "Tools" menu.
Paste hex string to textbox and press the "Translate" button. You should see data in hex format.
You can try with this DiscoverRequest data:
Hi Mikko,
Knowing that you are going to implement the support of the plain PDU (without any LLC like HDLC, wrapper or IEC4-32) on the client side, it will be great to also implement the support of the plain PDU on the server side especially on the server example 2 ANSI C.
Will it be possible to give us an estimation time for the above implementation.
We will be very happy to help testing this solution
Hi,
Hi,
1. If you change the Interface type to PDU plain PDU is sent. This feature is not implemented for ANSI C at the moment. I believe that padding is not expected. I'll add this to wok list. It's easy to add, but testing will take some time.
We are testing PLC for ANSI C and try to release it during this week.
We are also adding support for PLC PRIME, but tests will start for PRIME after two weeks.
2. When the modem sends received bytes to the client it will parse data and show available meters.
BR,
Mikko
Hi!
Hi!
Thank you very much for your fast reply. So by plain pdu you mean row DLMS data without any LLC layer am I correct ?
And regarding my second question the client will have the following stack (DLMS/COSEM + LLC layer(IEC61334-4-32 + MAC layer) and the physical layer will be the plc modem which should support the s-fsk modulation scheme right?
Regards!!
Hi,
Hi,
Yes, plain PDU is DLMS data without PLC framing.
And for the second question. Yes.
BR,
Mikko
Hello again!
Hello again!
Seems great, can you just tell us how to set the plain pdu.
You are doing great work many thanks!
Best regards
Hi,
Hi,
You only need to change the interface type to PDU. I just realize that it's not visible in GXDLMSDirector because it's not widely used. We'll add it and a new version is released next week.
You can try parser by yourself if you can get a trace from the PLC message.
Get send or received bytes as a hex string and then select "DLMS Translator" from "Tools" menu.
Paste hex string to textbox and press the "Translate" button. You should see data in hex format.
You can try with this DiscoverRequest data:
021150FCC00FFF119000011D64000A00000000000000000000000000000000000000CDD3
BR,
Mikko
If you have
Hi Mikko,
Hi Mikko,
Knowing that you are going to implement the support of the plain PDU (without any LLC like HDLC, wrapper or IEC4-32) on the client side, it will be great to also implement the support of the plain PDU on the server side especially on the server example 2 ANSI C.
Will it be possible to give us an estimation time for the above implementation.
We will be very happy to help testing this solution
Best Regards!