Oh no, I could finally read the telegram extension with the PLC. I do it the same way as the standard 352 Telegram, with DPRD_DAT, except for the energy (or any real double word) which I could only read with SinaPara, which is a bit messy and the program looks really ugly.

It took me a while to get this because in the G120X you configure only one extended telegram (the same way as a G120C but from the IOP panel) whereas from the plc side I have two telegrams, each with a different HW_ID: the Standard 352, and the extension PZD 2/4.

I don't know if you where asking me that

If you are using profinet communications with the G120X, you do not need to do the DP.._DAT calls to read/write data.

Also, if the extended telegram is at least 4 bytes long to contain the energy Real data, you can accept that into the PLC as "Real" starting at the address of the PZD receive (plc side).  It may need to be scaled compared to reading it via acyclic where you can read it is a Real directly.

Jorge KW

Oh no, I could finally read the telegram extension with the PLC. I do it the same way as the standard 352 Telegram, with DPRD_DAT, except for the energy (or any real double word) which I could only read with SinaPara, which is a bit messy and the program looks really ugly.

It took me a while to get this because in the G120X you configure only one extended telegram (the same way as a G120C but from the IOP panel) whereas from the plc side I have two telegrams, each with a different HW_ID: the Standard 352, and the extension PZD 2/4.

I don't know if you where asking me that

You mean using the process Image to map the drive values?

I don't like that because I have 20 drives and I prefer to use data encapsulation so that I can use the telegram as one data structure as input to my FB, instead of having FBs with 10 different inputs, which implies more work.

Let's say your Telegram process image Input starts at I300.0, is 8 words (16 bytes) long, and Output starts at Q300.0, is 6 words (12 bytes) long.

P#IX300.0 BYTE 16 is the input to your FB for inputs. P#QX300.0 BYTE 12 for outputs.

That's pretty encapsulated, but I get what you are saying.  The only thing is, your PLC is already providing the telegram data in a deterministic manner every PN update.  You are doing the work twice.

I have never wiresharked a session where the work was done twice like this, but suspect it adds traffic to the PN network.

If you are using PB, ignore everything I've said.

Jorge KW

You mean using the process Image to map the drive values?

I don't like that because I have 20 drives and I prefer to use data encapsulation so that I can use the telegram as one data structure as input to my FB, instead of having FBs with 10 different inputs, which implies more work.

New question published by guimbastos is split to a separate thread with the subject G150C not able to access these parameters.

Best regards
Jen_Moderator