When the Power PMAC rotary buffer reaches capacity, calls through Command() may stop returning instead of reporting the expected error 34. The same non-returning behavior was observed with GetResponse() and when commands were entered through the PowerPMAC IDE terminal. The available evidence does not establish whether this is intended blocking behavior, a library defect, or a controller-side command-processing condition.
Observed Rotary Buffer Behavior
| Command path | Observed result at full buffer |
|---|---|
Command() from gplib.h
|
The call does not return; expected error 34 is not reported. |
GetResponse() |
Shows the same non-returning behavior. |
| PowerPMAC IDE terminal |
Coord[1].RotStore stops increasing, but no error message is returned. |
Because all three paths exhibit the condition, the evidence does not isolate the problem to Command(). It indicates that command processing stops making observable progress once the rotary buffer is full.
Command That Reproduces the Condition
The buffer was filled using the following coordinate-system command:
&1OPEN ROTARYM5100==45 G1X385.000Y-635.000Z-300.000CLOSEThe evidence confirms this command can be repeated until Coord[1].RotStore stops increasing. It does not define the buffer capacity, the meaning of error 34 in this context, or the condition that releases stored rotary moves.
Diagnostic Procedure
- Monitor
Coord[1].RotStorewhile submitting the rotary command. - Record whether
RotStoreincreases after each accepted command and identify when it stops changing. - Repeat the test separately through
Command(),GetResponse(), and the PowerPMAC IDE terminal. - Treat a non-returning call combined with an unchanged
RotStorevalue as evidence that the full-buffer condition has been reproduced.
Run this test where a blocked client call cannot prevent required machine control or recovery. The evidence provides no supported timeout, return-code workaround, or library parameter that guarantees recovery.
Engineering Decision and Required Verification
Do not design the application around receiving error 34 until controller or library documentation confirms that contract. The demonstrated behavior requires the client architecture to account for a call that may not return when the rotary buffer is full.
Before selecting a permanent workaround, verify the documented rotary-buffer capacity, whether the API is specified to block when full, the event that frees entries, and whether a supported nonblocking or timeout mechanism exists. Those details are not present in the available evidence, so no product-specific handling sequence can be stated reliably.
FAQ
Why does Power PMAC Command() hang when the rotary buffer is full?
The evidence shows that Command() stops returning when the buffer is full, but it does not establish whether the cause is specified blocking behavior, a library defect, or controller-side command processing.
Does Power PMAC return error 34 for a full rotary buffer?
Error 34 was expected, but it was not returned in the reported tests. Confirm the documented meaning and delivery conditions of error 34 before using it as the application's full-buffer signal.
How can I confirm that the rotary buffer is full?
Monitor Coord[1].RotStore while submitting commands. In the observed condition, the value stopped increasing and calls through Command() and GetResponse() did not return.