About SteffenR-

It is planned to provide a successor method for CheckUnitDone and CheckAddonDone, in which accessing SetExtEvent would also be helpful to show an error message if the provided unit/addon is not RUNNING (= coding error in application code). Therefore we have internally the same request like you. What's your use case? ... View more

Alternatively to nexidator's hint (one cycle is finished after two parts) you can also use two instances of the Cycle Time Assist add-on and measure both lines independently. For both solutions you have to keep an eye on the invalid cycles to get a plausible result in the diagram. Solution 1 (one CTA add-on): If only one part is produced due to missing parts, it is an invalid cycle because it is probably faster than processing two parts. Solution 2 (two CTA add-ons): If only one part is produced, one instance has a regular cycle and the other instance has an invalid cycle due to missing part.   Handling invalid cycles with the CycleTimeAssistInvalidReasons enum is for example done in the example project Digital Machine: https://developer.bosch.com/products-and-services/sdks/nexeed-automation-downloads/controlplus#samples/digitalmachine In this project there is also made a difference between TargetCycleTime of Cycle Time Assist (which is the real target cycle time) and the TargetCycleTime of Part Counter (which is actually just an average target cycle time, that means TargetCycleTime x TargetOEE). ... View more

It is not recommended to link the FSoE variables of FSoE slaves into the PLC. These FSoE signals not always represent the physical input. The FSoE communication between the logic terminal (EL6910 etc.) and the input terminal (EL1908 etc.) also runs via these FSoE variables. Maybe the signal is correct in 99% of the time, but if the machine shows wrong errors or has a wrong behaviour in 1% of the time, it is hard to find the reason. If you have a standardized TwinSAFE configuration, you could create your own EL6910 peripheral that includes the suitable IO links. But if you don't have a standardized TwinSAFE setup, the current TwinSAFE configuration in CpStudio is really not good (too much effort, too many possibilites doing something wrong, IOs of IO terminals are not part of the IO terminal but the logic terminal => AML import does not work, etc.). There were already some conceptual meetings with the Nexeed development team in the past. It would be possible that all IOs are part of the safety IO terminals in CpStudio (i.e. AML import works and EtherCAT diagnostic represents physical architecture) and the CpStudio IO linking links the EL6910 signals with the BinIo variable in the PLC. But this new feature has not yet been priorised by our development team. If you (or anybody else) is using TwinSAFE or ctrlX Safety and need an improved handling in Control plus Studio, give feedback in the forum or via Helpdesk. ... View more

As of now there are these solutions: No. Interface Peripheral Object 1 Profibus DP via B&R controller from Weiss NexeedPdpWeissNcxxxTbb NexeedWeissRotTableDriveBeRa 2 EtherCAT (SoE) via IndraDrive from Rexroth (not from Weiss; the mechanics can be from Weiss) NexeedEcRxIdMPB, NexeedEcRxIdMPC, etc. NexeedRotTableDrive, NexeedRotTableOpenLoop 3 Digital IO from Weiss - NexeedWeissRotTableIo   Anything else must be solved in your application or a new peripheral/object is necessary. ... View more