A PMAC system with six Macro drives intermittently stops after repeatedly downloading and executing a motion program. Motor Status Bit 11, labeled Block Request, remains set, yet the same uploaded program runs when the terminal issues &1 B1 R. This evidence narrows the fault to the transition between program download and automatic start; it does not prove a drive-ring or motion-program failure.
Observed Failure Boundary
| Observation | Engineering implication |
|---|---|
| New PMAC system, six Macro drives, and new driving software | The control interface and command sequence require validation; the evidence does not isolate any component. |
Only X500Y130Z0W500 changes between cycles |
Compare a failed transaction with a successful transaction at the generated move line and subsequent start command. |
| Motor Status Bit 11 Block Request remains set | The stop coincides with an outstanding block request, but the supplied evidence does not define why PMAC leaves it asserted. |
&1 B1 R starts the program normally |
The downloaded program is runnable through coordinate system 1, buffer/program 1, using the reported manual command. |
Most Defensible Root-Cause Hypothesis
The strongest hypothesis is an intermittent command-sequencing, command-delivery, or response-handling problem in the new driving software. The successful manual &1 B1 R command shows that recovery is possible without changing the motion program. It therefore shifts initial investigation toward whether the automatic path sends the equivalent start command, sends it in the intended order, and confirms its acceptance.
This remains a hypothesis. The evidence contains no PMAC model, firmware revision, communication trace, response codes, drive status details, or timing data. It cannot establish whether the request is retained because of a controller state, a communications fault, or another interlock.
Diagnostic Procedure
- Log every command transmitted by the driving software from
OPEN PROG 1 CLEARthrough the automatic run request. Record each controller response without filtering or overwriting it. - On a successful cycle, preserve the complete command-and-response sequence. On the next stopped cycle, capture the same interval and identify the first missing command, different response, or ordering difference.
- Confirm that the failed cycle completed the closing operation after the move line and that the automatic path attempted the same effective run operation demonstrated by
&1 B1 R. - After the stop, issue only
&1 B1 R. If this consistently resumes execution without reloading or editing the program, prioritize the software start sequence and response handling. If it does not, expand the capture to controller and drive states because the reported recovery condition is no longer reproducible.
Program Context to Preserve
CLOSE
END GATHER
DELETE GATHER
DELETE TRACE
OPEN PROG 1 CLEAR
LINEAR
ABS
FRAX(W)
TA700
TS100
F100
DWELL0
P96=1
X500Y130Z0W500
DWELL0
P97=1
CLOSEDo not change acceleration, S-curve time, feed rate, or dwell statements merely to clear Bit 11; the evidence does not connect those values to the intermittent stop. Preserve the exact generated program and correlate it with the communication log before testing program changes.
FAQ
Why does PMAC Block Request Bit 11 stay on?
The supplied evidence does not establish the internal cause. Because &1 B1 R runs the uploaded program, first check whether the driving software omitted, reordered, or failed to confirm the automatic start operation.
Does a successful &1 B1 R command prove the program uploaded correctly?
It proves that the reported uploaded program can run through that manual command. It does not prove that every automatic download response was handled correctly or that the software issued the intended start sequence.
Should TA700, TS100, F100, or DWELL0 be changed?
Not from this evidence alone. Capture and compare successful and failed command-response sequences before changing motion parameters.