Hello all,
I am trying to connect GDS ports for receiving CAN messages from a component available as a function block (AXL_CAN_COMM_4 block) to a C++ component. The message structure defined in C++ is:
struct CAN_UDT_MESSAGE {
Arp::boolean xUsed = false;
Arp::int32 dilD = 0;
Arp::int16 iDLC = 0;
Arp::uint32 udiSequence = 0;
Arp::boolean xFrameFormat = false;
Arp::boolean xFrameType = false;
Arp::uint8 arrData[8] = {0x00};
};
The Struct generated from this code is:
TYPE
CAN_UDT_MESSAGE : STRUCT
xUsed : BOOL;
dilD : DINT;
iDLC : INT;
udiSequence : UDINT;
xFrameFormat : BOOL;
xFrameType : BOOL;
arrData : arrDataArray;
END_STRUCT
arrDataArray : ARRAY [0..7] OF USINT;
END_TYPE
My first question is here. The uint8 can be interpreted using several types: e.g., BYTE, USINT, Unsigned8, … . How is the choice made and can the user control this transformation?
Now, the in-port I am trying to match with, has this type:
TYPE
CAN_ARR_B_1_8 : ARRAY[1..8] OF BYTE;
CAN_UDT_MESSAGE : STRUCT
xUsed : BOOL;
diID : DINT;
iDLC : INT;
udiSequence : UDINT;
xFrameFormat : BOOL;
xFrameType : BOOL;
arrData : CAN_ARR_B_1_8;
END_STRUCT
END_TYPE
However it is impossible to assign this in-port to the C++ component in the PLCnext Engineer. Do you guys know what I am doing wrong? I appreciate your help!
There are a few parts to this question:
1. The STRUCT data type that is generated by the C++ code generator is included in the PLCnext Engineer library, so rather than defining your own STRUCT data type in PLCnext Engineer, you could just use the data type that is included with the library. This „guarantees“ that the STRUCT data types will match between the port on the C++ program and the port on the IEC program.
2. I think the mapping of C++ data types to IEC 61131 data types is hard-coded into the PLCnext CLI, but I will check. There is probably a manual work-around (involving the editing of the .dt file generated by the PLCnext CLI), but even if that worked it would not be very convenient if you’re using Visual Studio or Eclipse to build the project.
3. The custom STRUCT definition you showed above should match to to the C++ struct. This can be tested by manually editing the file PCWE.gds.config on the PLC (in the directory /opt/plcnext/projects/PCWE/Plc/Gds). I tried this, and the PLCnext Runtime does accept the connection of those port types. The problem in this case is the GDS Port List window in PLCnext Engineer, which does not allow you to connect these port types in that window. I will report this as a bug in PLCnext Engineer.
Correction to my answer above:
3. The structs need to have the same field names and compatible data types. The STRUCT generated from the C++ code has the following field:
dilD : DINT;
... and this will not match with the field in your struct:
diID : DINT;
… because the field names are different. If this is fixed, you should be able to match the structs in PLCnext Engineer. I was wrong to attribute this to a bug in PLCnext Engineer.
Correction to my answer above:</p>3. The structs need to have the same field names and compatible data types. The STRUCT generated from the C++ code has the following field:</p>
dilD : DINT;\n<\/pre>... and this will not match with the field in your struct:<\/p>
diID : DINT;\n<\/pre>... because the field names are different. If this is fixed, you should be able to match the structs in PLCnext Engineer.<\/p>I was wrong to attribute this to a bug in PLCnext Engineer.<\/p>
Well spotted !
Sorry that I misled you at first. But everything seems to work perfectly now, so thanks a lot!
There are a few parts to this question:<\/p>1. The STRUCT data type that is generated by the C++ code generator is included in the PLCnext Engineer library, so rather than defining your own STRUCT data type in PLCnext Engineer, you could just use the data type that is included with the library. This "guarantees" that the STRUCT data types will match between the port on the C++ program and the port on the IEC program.<\/p>2. I think the mapping of C++ data types to IEC 61131 data types is hard-coded into the PLCnext CLI, but I will check. There is probably a manual work-around (involving the editing of the .dt file generated by the PLCnext CLI), but even if that worked it would not be very convenient if you're using Visual Studio or Eclipse to build the project.<\/p>3. The custom STRUCT definition you showed above should match to to the C++ struct. This can be tested by manually editing the file PCWE.gds.config<\/code> on the PLC (in the directory \/opt\/plcnext\/projects\/PCWE\/Plc\/Gds<\/code>). I tried this, and the PLCnext Runtime does accept the connection of those port types. The problem in this case is the GDS Port List window in PLCnext Engineer, which does not allow you to connect these port types in that window. I will report this as a bug in PLCnext Engineer.<\/p>
Just a bit of clarification on points (1) and (2),
Regarding point (1), we are using the structure that is provided by the CAN function block, so we are not rewriting it. What we are trying to do is to match this structure by writing a corresponding C++ code so that they can work together.
Regarding point (2), once things start working together I see that this is not something I need anymore, since all the types I mentioned (BYTE, USINT, Unsigned8, ...) seem to be compatible (i.e., they have the same representation and interpretation of values in my platform).