You will need something like this: <?xml version="1.0" encoding="utf-8"?>
<LibraryCategories xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="LibraryCategories.xsd">
</LibraryCategories> Put it into a FileName.libcat.xml file and you should be able to load it in the dialog for the category selection. Replace the zeroes with a random GUID and the CategoryName with the name that you want to have in TwinCAT. Be careful about creating libraries with different categories. If you proliferate them too much, then users of your libraries will get a mess in their TwinCAT library manager.
... View more
Hello Nexeed development team, I have two suggestions regarding OES/CPS that I would really like fulfilled in future versions: 1) When declaring a struct or enum at a unit in the model tree, it will pretty much always have a name like <UnitName><SemanticName><Struct/Enum>, for example the ParImm struct of my Module1 ModeHandler will be called Module1ParImmStruct. First of all, when I add a new structure or enum, maybe it can be called "Module1NewStruct"/"Module1NewEnum" by default, instead of "Structure" and "newEnum". That will help people stick to the coding guidelines. Bonus points if the new structure name is already in edit-mode (as if I pressed F2) and the cursor is at the right position between Unit name and type suffix, then no need to insert "New" in the default name. What's next, when such a type is added to another one, e.g. I drag+drop my Module1ParImmStruct to Module1Unit, it is automatically called "ParImm" instead of "InstOfModule1ParImmStruct". If it starts with the unit name, strip it, if it ends in Struct or Enum, strip it, if nothing is left (because the user chose a weird type name) just call it InstOfX like before. Bonus points: If the remaining name of the new member starts with Par, give it the Parameter direction property Input, if it starts with Out then give it Output direction. Although this is quite debatable I think. 2) I often review software or need to debug some software from somebody else. Understanding the model tree is easy because I can just look at it. What is giving me a little trouble are the add-ons, because it is easy to miss if people randomly add them to deeply nested command handlers where I did not suspect them. If possible, could we please have a small icon next to the handlers in the model tree that depict if it has any add-ons attached to it? Bonus points: Make it a smaller number 1, 2, 3, 4, 5, 6, 7, 8, 9, or * to indicate the numbers, the asterisk (or some other character) meaning more than 9. Add-ons are an important part of each model tree, but they are completely invisible in the nice graphical overview that the project explorer provides. I would love to see that change. In general such behavior could also be modifiable in the OES/CPS settings. At the moment there is almost no customizability of OES. While this is good for things that affect project standardization, when it comes to usability aspects I think it's perfectly fine to allow users to change such behavior. Just some food for thought. What is everybody else thinking? If you like these new feature suggestions, please show your support so we maybe get it implemented 😛 If you have other suggestions, please feel free to add.
... View more
When I change the UnitStateReq to OPERATIONAL, as opposed to BACKBONE_CONTROLLED, then the backbone signals related to the Exec state machine are also not executed anymore it seems. Today I learned this very surprising fact when I was debugging why a switch of operation modes would not trigger a unit's cancel as I expected. I always thought that the UnitStateReq only affects the Unit state, as the name also suggests, but not that it would also affect the Exec state. I guess this behavior is intentional. If so, then I would like to raise the point if this is really a good idea. Which use case exists where this is behavior desired? If you think this is exactly how things should be, then I want to stress that this needs some documentation. I scanned the training book and couldn't find this mentioned (2019 version). Also I could not find a descriptive comment in the NxBase library where I would expect it. In particular the OpconUnitStateReq enum could use a serious hint that it also affects the behavior of the exec state machine. I was really surprised by this behavior and I thought I understood quite well how the framework works. Also debugging this was not easy at all.
... View more
You can remove the addon from the handler again, which basically stops it from being called. I wouldn't call this "clean" either, since the Nexeed framework clearly does want you to do that. And depending on what the add-on is doing exactly, it may have some weird consequences. If you do it straight at the end of OnUnitInitialize (after the exported code), it should be fine in most cases though. You can also link this to the unit state if you wanted to, but that requires you to either manually add this to all your handlers or create new handlers that extend the Nexeed version, like we have in our ATMOx handlers anyway. I'll contact you separately how to do this, I don't really want to advertise this solution publically. Maybe the Nexeed developer team picks up on your requirement and adds this to the official framework someday.
... View more
If I need to temporarily "disable" an add-on, then I go to the hosting handler's OnInitHierarchy and remove it from there. If it is not added to the handler, then it will never be executed. Since the code is inside the OES generated code, the next export will bring it back. For a slightly more permanent solution, you can wrap the OES part in an IF ( FALSE ) and copy-paste everything except the add-on below your END_IF. Never did it like this, but it should work. Then export will have no effect anymore, so other changes to children etc. will also not be updated. So it's also a temporary solution at best. Also, add a !!!BIG WARNING!!! pragma in that OnInitHierarchy to avoid bad accidents if the software unexpectedly changes hands.
... View more