AddOn define to specific level (ModeForwarder, ModeHander, CommandHandler)

[PKlein]

Hello everyone,

I would like to have your feedback. Would make sense to define addons on a certain level (ModeForwarder, ModeHander, CommandHandler).

Sometimes it makes sense that I can add an AddOn to the CommandHandler or the ModeHandler.

At the  MES@AE objects I have AddOn's, where I want the user to only be able to set them to the ModeHandler or CommandHandler. Today I check this at the StartupParams.otd with an additional code. But this checking is for the programmer maybe too late because he already set it to the CommandHandler and gets the error message (tag) at the Twin-Cat, and it increases the export time of the OES/CPS. 

With a possibility to define addons for certain levels, the programmer would not make the mistake and it could reduce the export time.

What do you think?

Thanks for feedback!

[nexidator]

If I understand correctly, your question is whether we could introduce a feature in Control plus Studio, allowing add-on object definitions to specify a specific parent type required by the add-on.

At the moment, the hierarchy rules consider the node type, nothing else. Add-ons are allowed on every handler, that's it. Sure, it would be possible to introduce another field in the OOD file specifying the required parent type. But this would be quite a big effort, because it affects drag/drop and copy/paster operations as well. And I don't know how frequent this use-case would be.

Actually I find your solution perfectly OK. Generating an error pragma in the PLC code is not super-nice, but it works. (I don't see how this should perceptibly increase export time.)

My other question would be: Why does the programmer expect this add-on to work on a handler where it should not be placed? If the add-on really doesn't make sense on a specific handler type, he shouldn't have a motivation to put it there. Or at least the mistake shouldn't happen very often.

I don't say your feature suggestion doesn't make any sense. It's just my feeling that it's not very urgently needed.

[PKlein]

So this is the code what I put at the StartupParams.otd:

if (@this.Parent.NodeType != HierarchyNodeType.CommandHandler ) {
sErrorText = ": illegal parent NoteType; AddOn must be on a parent CommandHandler-NodeType" ;
}

else

{...}

 

If I now starting the "Export" from OES/CPS the program must run through the code, or not? I always thought, the less code in the StartupParams.otd, the faster the export. Or dose have this no influence at the export time?

From my point of view, I don't need it, because I know which AddOn's come on which level. Nevertheless, I see in the field that it is often happens.

But maybe for the NxEventListAddon could it also help, because this makes also no sense to put it on CommandHandler-Level!

Maybe I thought the solution was too simple, because the behavior for addons that are set on units already exists. See picture!

[nexidator · Accepted solution]

I don't think you will be able to measure the time it takes to execute this code. That's what I meant with "perceptibly".

About the NxEventListAddon: You are right, I also don't see a usage for it on a CommandHandler. But it works there just as well. So, no, there has never been a requirement to be more restrictive there.

[PKlein]

Ok, if the influence is so small, is ok for me! Does the statement also apply if an AddOn's is used 20 times in the OES/CPS?