A user is facing an issue with a protocol developed in-house.
There is some logic to change the Parameter Description at runtime depending on a parameter that is polled from the device. This in general works well. Unfortunately this is not working when the element is replicated to another agent. On the replicated element the setParameterDescription function seems to be doing nothing. Any ideas why ?
The replicated elements get their information from an SLNet subscription and don't have any actual information loaded in SLProtocol. Because SLProtocol only is used as a connector to setup the subscription, not everything is loaded like in a normal element.
In short it's advised to not use protocol calls on replicated elements. If the description.xml got updated it could just be a matter of restarting the replicated element. I believe the forward is blocked in SLProtocol to SLElement since it's not able to do certain operations on a replicated element.
Configuration through the UI:
Manual,
I tried doing this on a replicated element through the UI and this seems to work. In the element card top left in the hamburger menu, if you select parameter names you can configure the overridden description. I’ll update my post with a screenshot so you can see what to configure. Please try this first, if this works then we probably need to have to take a look at your connector.
Hi Davy,
I tried what you suggested and setting the custom name on the replicated Element manually via Cube is working. I also now tried again to set the parameter with the following two functions:
int result = (int)protocol.NotifyDataMinerQueued(127/*NT_UPDATE_DESCRIPTION_XML */ , elementDetails, updates);
protocol.SetParameterDescription(Convert.ToInt32(parameterIdStart + “00”), “Status (” + transponderDescription.Trim() + “)”)
Both are working properly on the local element but do not update the parameter description on the replicated element. Is there any other function that could be used?
Manuel,
If this works in DataMinerCube on a replicated element and you are using the same call with the same arguments for the NT_UPDATE_DESCRIPTION_XML this could probably easily be fixed by trying through the SLNet connection instead of the protocol object. Thats the last idea that I have, if that doesn’t work feel free to create a ticket so this can be looked at.
Hi Davy,
thanks for the explanation!
Restart of the element did not help.
Unfortunately we have the requirement to display information that are received during runtime from the device as parameter description to create meaningful alarms. Is there another way how this can be achieved even though we replicate the element?