Hi everyone,

I'm using theAPL_GS block (FB1721)from theDriveES PCS 7 APL libraryto control a SINAMICS drive via PROFINET inPCS 7.

I encountered an issue where theAcBusyoutput remains constantly TRUE, even though:

• The drive hasno fault(confirmed via status word and faceplate)

• GrErr,SFBErr,ReqErr,RcvErr,SndErr,WdogErrare all FALSE

• AcStart is set toTRUE

• I have tried pulsing RstLi := TRUE, and also tried Restart := TRUE for one scan cycle

• No other blocks are accessing the same drive or using the acyclic communication channel

• The axis is operating normally and can be started/stopped from the HMI

Despite all of the above, theAcBusybit never resets back to FALSE.

I suspect the block is somehow stuck waiting for the fault memory to be read, but no fault exists to read.

Has anyone experienced this behavior before? Is there any workaround to force AcBusy to reset, or is this a known bug in the APL_GS block?

Any insights would be greatly appreciated.

Thanks in advance!

Did you try to turn AcStart = 0 for several scans while GrErr is false?

I don't have a live system to double check, and memory is not good enough, but I'm assuming you are comparing this against other drives and this is the only one with AcBusy = 1 all the time?  Else it might just be indication that you've set AcRead = 1.

EDIT: from PUD:
With the input AcStart you enable acyclic communication. If the input is set to "TRUE", the channel for acyclic communication is currently not being used by other applications. The channel can be used by this block. If the block occupies the acyclic channel, the AcBusy output is set to TRUE. No other application must use the acyclic channel now.

So I think it's normal, but you can tell us if its only happening on 1 drive.

Which specific Drive ES APL Library version?

There are several hotfixes in the 9.x > 9.1 SP2 range that should be typically applied.