• State TI Thinks Resolved
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 80 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: Ind-Comms-SDK: Profinet Alarm Data

Philip Kees
Prodigy 135 points

Part Number: AM6442

Hi,

I started with implementing the sending of profinet process alarms on our side and have a question regarding the expected structure of the alarm data parameter.

For example PN_API_IOD_sendProcessAlarm needs an uint8_t* pointer to some memory containing alarm data together with a length value. 
Is there some information on how the alarm data should be structured? I suspect that I need to provide the channelNumber, properties, reason, etc, but don't now what the layout is. Should it be the same as PRAL_alarmItem in the spec? 

Also, what is the user handle parameter used for?

Thank you and kind regards,
Philip Kees

  • 0
    TI__Intellectual 1990 points

    Hi Philip,

    The data parameter you are describing and its structure are user-defined. They are reflected in the specs as "Alarm_User_Data" and "Alarm_User_Data_Structure_Identifier". You can choose how to specify this part based on your application needs. It can simply be a text describing the alarm.
    The user handle is irrelevant for alarms in the current version of the stack, but it will serve a similar purpose to diagnosis tag (see diagTag tag in pn_api_iod_diagnostic.h).

    Thank you.
    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 135 points

    Hi Kamil,

    is this also the case for User Structure Identifier = 0x8320 (Process alarm with channel coding)? As I understand it a specific set of data consisting of channelNumber, PRAL_channelProperties, PRAL_Reason, PRAL_ExtReason and PRAL_ReasonAddValue is expected. Sorry, I think that part was missing from my initial question. 

    If that is the case it feels a bit shaky to just try and serialize that into some byte array and hope that the byte ordering and data sizes are correct for everything.

    Kind regards
    Philip

  • 0 in reply to Philip Kees
    TI__Intellectual 1990 points

    Hi Philip,

    I just took a look at the standard. It seems like the USI field for process alarms can be manufacturerSpecific or normative (e.g. 0x8320), so your statement is correct.

    Based on a quick look, I don't see any special handling within the stack for this field, so you can probably create a structure in your application (equivalent to PRAL_AlarmItem) and use it as an input to this function. Have you tried that already? is it working?

    Just a little hint, please make sure not to exceed the maximum allowed size for process alarm payload (PN_API_IOD_MAX_PROCESS_ALARM_LEN).

    Kind regards,
    Kamil

  • 0 in reply to Kamil Alkhouri
    Prodigy 135 points

    Hi Kamil,

    not yet, I was still in the early stage of collecting infos on how to implement it. I'll try it the coming days and let you know.

    Thank you!