A multi-axis Cimatron postprocessor produced equivalent operations at A0 instead of honoring selected negative A-axis orientations. Changing the generated Heidenhain command from PLANE SPATIAL COOR ROT to PLANE SPATIAL TABLE ROT allowed positive and negative A-axis angles to coexist in one program. The evidence identifies postprocessor output—not the work coordinate system (BKS) or angle preference alone—as the root cause.
Recognize the Failure Pattern
The failure appeared when selected procedures needed an inverted orientation near A-180 to avoid a collision at A0. Although the BKS and preferred negative swivel direction were configured, the posted program retained A0 whenever the operation could also be machined there.
| Configuration or observation | Reported result |
|---|---|
| Align BKS enabled | Operations that could run at A0 remained at A0 instead of using the requested negative orientation. |
| Preferred A angle set to negative | The preference affected all eligible operations rather than only the selected procedures. |
| A-axis range constrained toward -180 | Operations that could run at A0 were also posted at A-180, so this did not provide procedure-level selection. |
| Align BKS disabled | Rotation occurred, but the reported result was A-90 B0 instead of the required A-90 B-90. |
Separate Angle Limits from the Postprocessor Fault
The reported manual limits were initially -61 and +91, and the limit entry could be disabled. Changing the range or global preferred-angle setting altered which solution the postprocessor selected, but it could force every eligible operation to the same side. These settings therefore did not solve the requirement to post only selected procedures at A-180 while leaving other procedures at A0.
Use angle limits only to describe permitted machine motion. Do not treat a global range restriction as a procedure-level orientation command. Before changing limits, confirm the actual machine travel from the applicable machine configuration; the evidence does not establish universal limits for GROB machines.
Identify the Command-Level Root Cause
Postprocessor support identified the emitted command PLANE SPATIAL COOR ROT as the cause. A revised postprocessor emitted PLANE SPATIAL TABLE ROT, after which the same program could contain both positive and negative A-axis orientations.
This result also explains why changing the BKS, preferred A angle, and manual range did not reliably correct individual operations: those inputs still passed through a postprocessor that generated the unsuitable rotation form. The evidence establishes the command change as the successful correction, but it does not identify a Cimatron version, Heidenhain control model, postprocessor revision, or firmware boundary.
Correct the Postprocessor
- Post a small test containing one procedure intended for A0 and one intended for the negative A-axis orientation.
- Inspect the generated Heidenhain program and determine whether the orientation output uses
PLANE SPATIAL COOR ROT. - Have the postprocessor supplier revise the output to use
PLANE SPATIAL TABLE ROTfor this machine configuration. The reported solution came from an updated test postprocessor. - Regenerate the complete program from the CAM system. Avoid manually combining separate posted programs because that hides the postprocessor defect and can expose the next operator to an incorrect orientation.
Verify the Corrected Output
Verification must demonstrate selection at the procedure level, not merely force every operation negative. Check that the regenerated program contains both the intended positive or A0 solutions and the intended negative A-axis solutions. For the reported case, success meant retaining suitable operations at A0 while allowing selected inverted operations near A-180 in the same program.
Also review the previously incorrect compound orientation: the observed failure produced A-90 B0 when A-90 B-90 was expected. Confirm that each affected procedure now posts the commanded rotary-axis combination and remains inside the verified machine limits. Treat collision avoidance and end-switch clearance as mandatory machine-simulation and controlled prove-out checks; the evidence does not establish safe clearance values.
FAQ
Why does Cimatron post A0 when I selected A-180?
In the reported configuration, the postprocessor emitted PLANE SPATIAL COOR ROT and selected A0 when the operation was geometrically possible there. Changing the postprocessor to PLANE SPATIAL TABLE ROT allowed selected negative and positive A-axis solutions in one program.
Can I force A-180 by changing the postprocessor angle limits?
A range biased toward -180 forced all eligible A0 operations to post at A-180 in the reported case. That global restriction did not provide the required per-procedure choice.
How do I verify the PLANE SPATIAL postprocessor correction?
Post a test containing an A0 procedure and a negative-A procedure, then confirm that the output uses PLANE SPATIAL TABLE ROT and preserves both intended orientations in one program. Also check any required compound position, such as the reported A-90 B-90 case, before machine execution.