AB6674 CompactCOM EtherNet/IP Assemby Remap Write Area Returns Incorrect Size

First of all, I apologize for this lengthy post but I wanted to include as many details as possible to give a better picture of the issue I am running into. I am using files from the generic project provided by Anybus. I am using the configurations for ADI as shown in the attached code snippet.

Class: Assembly (0x04)
Service: 0x0E - Get Attribute Single
Instance: Producing (0x64)
Attribute: Data (3)

Class: Assembly (0x04)
Service: 0x0E - Get Attribute Single
Instance: Consuming (0x096)
Attribute: Data (3)

const AD_AdiEntryType APPL_asAdiEntryList[] =
{
    {513, "SetpointCurr", ABP_FLOAT, 1, APPL_READ_MAP_WRITE_ACCESS_DESC, {{NULL, NULL}}, NULL, SetAdiValueCbf}, // register 0x3010
    {514, "SetpointCurrQ", ABP_FLOAT, 1, APPL_WRITE_MAP_READ_ACCESS_DESC, {{NULL, NULL}}, GetAdiValueCbf, NULL}, // register 0x3020
    {515, "SetpointVolt", ABP_FLOAT, 1, APPL_READ_MAP_WRITE_ACCESS_DESC, {{NULL, NULL}}, NULL, SetAdiValueCbf}, // register 0x3030
}
const AD_MapType APPL_asAsmObjWriteMap1[] =
{
    {514, PD_WRITE, AD_MAP_ALL_ELEM , 0 },
    { AD_MAP_END_ENTRY } 
};
const AD_MapType APPL_asAsmObjReadMap1[] =
{
    {513, PD_READ, AD_MAP_ALL_ELEM , 0 }, 
    {515, PD_READ, AD_MAP_ALL_ELEM , 0 }, 
    { AD_MAP_END_ENTRY } 
};
const AD_MapType APPL_asAdObjDefaultMap[] =
{
    {513, PD_READ, AD_MAP_ALL_ELEM , 0 },
    {515, PD_READ, AD_MAP_ALL_ELEM , 0 },
    {514, PD_WRITE, AD_MAP_ALL_ELEM , 0 },
    { AD_MAP_END_ENTRY }
};
const ASM_InstanceType APPL_sAsmWriteMapInst1 =
{
    ABP_ASM_IA_DESC_WRITE | ABP_ASM_IA_DESC_STATIC | ABP_ASM_IA_DESC_PD_MAPPABLE,
    APPL_asAsmObjWriteMap1
};

const ASM_InstanceType APPL_sAsmReadMapInst1 =
{
    ABP_ASM_IA_DESC_READ | ABP_ASM_IA_DESC_STATIC | ABP_ASM_IA_DESC_PD_MAPPABLE,
    APPL_asAsmObjReadMap1
};

const ASM_InstanceType* APPL_aasAsmInstances[] =
{
    &APPL_sAsmWriteMapInst1,    /* Instance 1 */
    &APPL_sAsmReadMapInst1,     /* Instance 2 */
};

/* following macros are also enabled in their respective header files */

    #define ASM_OBJ_ENABLE                          TRUE
    #define EIP_IA_PROD_INSTANCE_ENABLE             TRUE
    #define EIP_IA_CONS_INSTANCE_ENABLE             TRUE
    #define ABCC_CFG_REMAP_SUPPORT_ENABLED          TRUE 
    #define ASM_IA_NAME_ENABLE                      TRUE
    #define EIP_IA_ENABLE_PARAM_OBJECT_ENABLE       TRUE

Adding the ADI instance to the default AD Object Map brings up the correct ad_WriteMapInfo and ad_ReadMapInfo structs with correct iPDSize (process data size) and bNumElements.

While adding the ADI Instances to Write/Read Maps and inturn to assembly mapping instances triggers a RemapProcessDataCommand() from the ABCC_CbfReceiveMsg() sent by Anybus device. This remap command overwrites the iPDSize and bNumElements to zero, thereby causing the Write Assembly command(Get Attribute Single, Class: Assembly(0x04), Instance(0x64), Attribute(3)) to corrupt. I get garbage results after each query. Read Assembly commands work all good.

Based on the datasheet, when I put a breakpoint on the Remap Process Data command I get the data as shown in the following screenshot

During the initialization phase, in the NW_INIT state, all write assemblies (e.g. the instances of the assembly mapping object with type“write”) will be remapped to the write process data area. For this to happen, the device will issue the Remap_ADI_Write_Area command to the application data object in the host.

case ABP_APPD_REMAP_ADI_WRITE_AREA:
     RemapProcessDataCommand( psMsgBuffer, &ad_WriteMapInfo );
     break;


Decoding above data shows:

  • CmdExt[0…1] = 0, Start remap from mapping item 0
  • Data[0…1] = 1, Remove 1 mapping item
  • Data[2…3] = 1, Insert 1 mapping item
  • Data[4…5] = 514, New mapping item 1: Instance no. #514
  • Data[6] = 0, New mapping item 1: Map from element 0
  • Data[7] = 0, New mapping item 1: Map 0 elements ???

The command ends up corrupting the iPDSize for ad_WrtieMapInfo and thus giving me erroneous results when trying to access producing instances.

Accessing the individual ADI using the ADI Object works too without any errors:

Class: ADI Object (A2h)
Service: 0x0E - Get Attribute Single
Instance: 514
Attribute: Data (5)

Is there anything else that I am missing on my side that’s causing the above-mentioned issue? Also, no command is issued from the network when the iPDSIze/bNumElements of the Map is overwritten.

Minor copy-paste error in above post, I meant:

Class: Assembly (0x04)
Service: 0x10 - Set Attribute Single
Instance: Consuming (0x096)
Attribute: Data (3)

Hi @pdesai,

Could you send me the files that you modified from the generic Compact Com code so that I can try and debug this issue?

-Tim

Hi @Tim_hms,

I have attached a zip file containing the adaptation of Anybus generic project anybus_mpe_adaptation.zip (817.8 KB) . The following is a list of files that were modified as per our requirement:

  • anybus_mpe_adaptation/abcc_adapt/abcc_drv_cfg.h
  • anybus_mpe_adaptation/abcc_adapt/abcc_identification.h
  • anybus_mpe_adaptation/abcc_adapt/abcc_obj_cfg.h
  • anybus_mpe_adaptation/abcc_adapt/abcc_sys_adapt.c
  • anybus_mpe_adaptation/abcc_adapt/abcc_td.h

The example_app folder was replaced by mpe_app with minor modification to the following files:

  • anybus_mpe_adaptation/mpe_app/appl_abcc_handler.c
  • anybus_mpe_adaptation/mpe_app/appl_abcc_handler.h
  • anybus_mpe_adaptation/mpe_app/appl_adi_config.h
  • anybus_mpe_adaptation/mpe_app/appl_adimap_mpe_callback.c
  • anybus_mpe_adaptation/mpe_app/appl_obj_port.c

We have two more external Texas Instruments driver files for SPI Send/Recieve functions which are not included in the above folder due to proprietary information but not needed in this context.

I just wanted to re-iterate that above-mentioned problem happens even before communicating with anybus device over network when Remap_ADI_Write_Area command is issued by anybus to host during NW_INIT state.

Let me know if you need anything else @Tim_hms.

Hi @pdesai,

I was talking with one of my colleagues on this issue and he was wondering if you had a summary of what you’re trying to accomplish with this setup.

He was saying that he’s not sure if there’s something wrong with the way you have the ADI setup. While you have defined a few ASM instance lists they do not have enough of them to make a real difference (there is just one WR and one RD), and the list of CIP assembly object instances that you send to the ABCC (EIP_IA_xx_INSTANCE_VALUE) does presently not define any other instances than our default ones (100 + 150), so we’re a little puzzled about what kind of result they had in mind.

My colleague thinks that the confusion might be in your understanding of our ASY object, rather than the setup and values in your code, or the ABCCs behaviour.

While this may not be the reason for the issue, my colleague is recommending that you grab a copy of the latest example code from our website. It seems like you’re working with the 3.06, we released the 3.07 a while ago.

The 3.07 contains an updated version of the “appl_adimap_asm.c” that contains a list of example CIP assembly instance numbers and some of the mechanisms to relay those to the ABCC. They are presently written for DEV, but the EIP works in the same way in this regard, albeit via different instance attributes in the host EIP object. In case you want some ASY example to test that should work ‘out of the box’.

Hi @pdesai,

just wanted to check if you still were looking for help with this issue?

-Tim