We are still working on migrating to the new Bosch Connected Industry Online Portal. Stay tuned! Click here for the latest updates.
03-15-2023 09:05 AM - edited 03-15-2023 09:06 AM
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!
Solved! Go to Solution.
03-15-2023 12:48 PM
The export code is compiled before execution, so it is really fast. There are thousands of lines of code executed on every export, and the whole code generation doesn't contribute that much to the total export time. What takes longer is reading the existing code from TwinCAT, comparing it to the generated code and updating it if necessary.
03-16-2023 05:49 AM
I have a similar use case from time to time. The solution to export some {error '...'} into the PLC code is fine, but I was wondering if it was also possible to generate errors directly in OES somehow which are then listed in the output window. That would make it a bit more convenient for the user, too.
03-17-2023 03:18 PM
I'm not sure if this is an intended feature or not. I've tested it in OES4.11, but I assume it works in other version. I've only used this method for debug statements during object development, but I think it could work in a released version as well.
One option is to create a Custom.otd and return a text string if the error condition is present.
You'll need to adjust the error check, and the message returned. The following is based on @PKlein original question. It should be trivial to check for other conditions and display more specific messages.
<%
if (@this.Parent.NodeType != Bosch.OpCon.Engineering.ControlSystems.HierarchyNodeType.CommandHandler )
{
return @this.UnitInstance.FullName + " at " + @this.Parent.UnitInstance.FullName + Environment.NewLine +
": illegal parent NodeType" + Environment.NewLine +
"MES@AE AddOn must be on a parent CommandHandler-NodeType" ;
}
%>
In the Object.ood file you'll need to add
<Object>
<Common>
<Templates>
<Custom name="Export\Custom.otd"/>
</Templates>
</Common>
</Object>
This will give a message displayed during export similar to the following.
Actually now that I look at this more, a better option is to display the MessageBox ourselves in the custom.otd file. This way we're not relying on a feature that might not be intended or only exists in certain versions. You also get more control over the MessageBox.
<%using System.Windows.Forms from System.Windows.Forms %>
<%
if (@this.Parent == null )
{
MessageBox.Show(@this.UnitInstance.FullName + Environment.NewLine +
": illegal parent NodeType" + Environment.NewLine +
"MES@AE AddOn must be on a parent CommandHandler-NodeType",
"Error Detected during export",
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
else if ( @this.Parent.NodeType != Bosch.OpCon.Engineering.ControlSystems.HierarchyNodeType.CommandHandler )
{
MessageBox.Show(@this.UnitInstance.FullName +
" at " + @this.Parent.UnitInstance.FullName + Environment.NewLine +
": illegal parent NodeType" + Environment.NewLine +
"MES@AE AddOn must be on a parent CommandHandler-NodeType ",
"Error Detected during export",
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
else if ( @this.Parent.BaseTypeId != "A467FB1C-013E-11E1-8619-000423132FC8")
{
MessageBox.Show(@this.UnitInstance.FullName +
" at " + @this.Parent.UnitInstance.FullName + Environment.NewLine +
": illegal parent NodeType" + Environment.NewLine +
"MES@AE AddOn must be on a parent Command Handler Template ",
"Error Detected during export",
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
%>
That seems a little better to me.
The biggest disadvantage I've seen to this method is that the Export won't finish until the MessageBox is closed. If you're doing other things during export, it's not difficult for the MessageBox to get behind the main window. I've read adding MessageBoxOptions.DefaultDesktopOnly could be one solution to this, but I haven't fully tested.
Maybe someone else has a method to send these messages to the existing output window, but this is all I can come up with.