Open bseater opened 1 year ago
Sorry I am not ignoring this issue, but most of the team is on assignment so it is going to have to wait. Not many people realize you can do this, but if you add the .library file as an existing item under the PLC node in a TwinCAT project you can view/edit the source. If you want to experiment with potential fixes you can save the project as a library with version e.g. 100.0.0 and install it to your local repository.
If you can get a fix and wish to share I can pull it into the dev side an push a new official build.
When I add a .library file it doesnt build. I get 500+ errors. It seems like the global data types somehow dont get through to the project. Not sure what the proccess is for this could you explain?
When I add a .library file it doesnt build. I get 500+ errors. It seems like the global data types somehow dont get through to the project. Not sure what the proccess is for this could you explain?
there is video help for this here : https://beckhoff-usa-community.github.io/SPT-Libraries/Getting_Started/Videos.html
I'm running into an issue where I am unable to reset the overall machine module if a module has a component alarm. This is in a XTS project, which I suspect is part of the issue.
When a component has an issue (either a business logic failure, or something like an axis losing the Enable signal during a move), it raises an alarm evet. The parent module sees the component alarm and raises it's own E_BaseAlarms.ComponentError. The machine sees this and changes to a Stopping state, which is then passed back down to all the other modules. This is all working as expected.
I am unable to recover from this, though.
When I trigger a machine reset (using ControlSource.MainPMLControl_Simplified.ResetPressed from a HMI), the machine goes into a Resetting state, and then on the next PLC cycle it changes to Stopping and then Stopped. The module never goes into a Clearing state to deal with the alarms. I suspect there is a race-like condition between clearing the alarms and detecting alarms and responding to them.
As a quick test, with a change to Machine SubModuleMonitor I can get it to clear. Adding "AND _CurrentState <> E_PMLState.ePMLState_Resetting" to the big IF statement at the top of SubModuleMonitor and ORing it into the ELSIF section lets it actually reset. I suspect the issue will crop back up if there is an alarm that would cause the machine to Abort though.
I think the root cause is in FB_Machine.Resetting in the XTS example project. It waits for the XPU to be enabled before calling the base Resetting method, but before the XPU can enable SubModuleMonitor has seen the Module alarms and stoped everything. I tried moving the XPU.Enable() call, but then the movers alarm on the initial reset. I haven't dug into the XPU logic yet to find a way around that.
AB#5323