ADI's in ProfiNET GSDML
Is it possible/typical to place any sort of information in a ProfiNET GSD for each ADI that is available via acyclic communication? Obviously, there is an entry in the GSD for each ADI that is accessed cyclically via the process data. If so, does anyone have any example GSD's I can look at?
-
I did find the usage of "ParameterRecordDataItem" in a different vendor's GSD (a vendor who is using an Anybus ProfiNET CC40 module and ADIs). It was located under ISO15745Profile->ProfileBody->ApplicationProcess->DeviceAccessPointItem->VirtualSubmoduleItem->RecordDataList
Can anyone confirm I'm on the right track?
0 -
This isn't necessary to do because a variable that is available to acyclic services will be so regardless of if it is listed in the GSD file or not. You need to know the slot/index, but after that you should be able to access it. The 'settings definitions' will target an ADI in the end since that is the only data-transporting container we have, but an ADI does not have to be listed/defined in this way to be reachable for acyclic services.
"ParameterRecordDataItem" is related to something else as I understand it, defining 'configuration settings' that a programming tool can display to an end user and send down to the peripheral device. It's a way to declare to a configuration tool which index values can be used for configuration information so that the user doesn't have to do this manually. There is an example in the Network Guide for the ABCC40-PIR on page 17 of 259
0 -
Ok, I understand what you are saying about it not being required. That makes sense.
I'm wondering whether it is still a good idea to document all of the ADI's this way? Perhaps some ProfiNET tools can make use of this information? For example, in our EtherNet/IP version, we made all of the ADI's available in the CIP Parameter object. We also documented all of the ADI's in the EDS as parameters. With a special Rockwell code all of our ADI's were available in the Rockwell configuration tool (see attached picture). This gives the PLC Engineer the ability to see what parameters are available, and also the ability to quickly change their values without writing a function block.
0 -
Yes, I can see how this can be convenient. I'm not an expert enough on the PROFINET configuration tools, like TIA Portal, to know if that would be beneficial for them.
You could create a ticket in order to get in touch with our embedded engineers who are experts in PROFINET.
0 -
I've been trying to understand some of the ProfiNET features some more, and I've come across some information about different types of ProfiNET device parameters that may help frame the discussion (https://profinetuniversity.com/profinet-basics/profinet-device-parameters/).
If my understanding is correct, if I put my ADI definitions in the GSD, they will be available as "Standard Parameters". This means that the Engineering tool (e.g., TIA Portal) will be able to provide a dialog to allow the Engineer to modify the value. Then, this value will be downloaded to my device every time the controller connects to the device.
The downside to this method is that most of my parameters are changeable via other methods (e.g., Web pages, using Read/Write record function blocks, other fieldbus connections, etc.). This could cause an issue next time the controller connects to my device, as it will set the parameters back to the values configured by the Engineering tool. Am I understanding this correctly?
If I am understanding things correctly, my use case would be better facilitated using "Dynamic Parameters (iParameters)". This would allow my ADI's to be backed up to the iPar-Server so that if my device is ever swapped out, the ADI's may be automatically reconfigured to their last state.
So, my question is, does the ABCC40-PIR module provide any services that facilitate connecting with an iPar-Server? Or, would I have to implement something in my device's host application?
0 -
I'm still on the quest to list my ADI's in the GSD, in some manner, in hopes that some tool out there can make use of the list. The RecordDataList along with ParameterRecordDataItem comes pretty close. The problem, as mentioned above, is that the values are sent from the tool (e.g. TIA Portal) to the device upon connection. I want the PLC engineer to be able to choose which parameters get sent at startup, and which are ignored.
I did come across AvailableRecordDataList. This seems to allow me to list my ADI's in the GSD, though it isn't clear that any engineering tool (e.g. TIA Portal) makes use of this. However, it does seem to have some usage by OPC-UA (PROFINET GSD - 6.7 Data Objects (opcfoundation.org)). Does anyone know much about the intent of the AvailableRecordDataList in a GSDML? I've read the GSDML specification regarding it, but it tells more about how to use it rather than the intent.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
6 Kommentare