• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 256 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: Ind-Comms-SDK: Profinet Alarm Data

Philip Kees
Prodigy 145 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 2660 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 145 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 2660 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 145 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!

  • 0 in reply to Kamil Alkhouri
    Prodigy 145 points

    Hi Kamil, sorry for the delayed update. I finally came around to implement and test it. 

    For the specific case of USI = 0x8320 the stack seems not to accept the process alarm request. 

    This USI is for example required by the "IO Link Integration for Profinet" Specification, so I used a set of inputs that should be valid according to this document:

    Channel Number = 0x8000
    Properties = 0
    Reason = 0x9500
    ExtReason = 0x6321
    AddValue = 0

    USI = 0x8320

    I serialize these into a buffer accroding to PRAL_alarmItem from the Profinet standard and call PN_API_IOD_sendProcessAlarm() with it.
    The initial call to the PN API returns PN_API_OK, but after a few ms the stack stops and prints an error message stating a fatal error, with no further information. No alarm is sent to the PLC (checked with Wireshark)

    When I do the same but with USI set to something below 0x8000, e.g. 5, it works as expected. I can also see the data from the buffer in the Alarm Notification in Wireshark. 

    Kind regards
    Philip

  • +1 in reply to Philip Kees
    TI__Intellectual 2660 points

    Hi Philip,

    I just had some time to look into this. It looks like the stack is considering USI 0x8320 as an out-of-range value which is not compliant with the specifications. I will create a bug ticket and try to sort it out before our next release.

    However, a dirty solution to make this temporarily work would be to assign a manufacturer-specific value to the USI parameter (e.g. 0x0000), and to set the correct USI (0x8320) as the first element of the defined PRAL_AlarmItem structure (USI, ChannelNumber, etc.). This will help you bypass the stack's USI filter. The down side is that you will have to consider this shift on the receiver side as well.

    Kind regards,
    Kamil