slow velocity on a geometry of multiple short blocks

[lukewang]

Dear PMAC Support,

 

We are using Clipper.

 

When we came cross a geometry with many short blocks (about 1mm each), we found the actual velocity on the geometry is much slower than programmed one, and the worse, the velocity is fluctuating.

 

Important note here is that all these short blocks are tangentially connected. But it doesnt help on its feedrate.

 

We tried to replace these short blocks with SPLINE2, we tried to turn on lookahead function, we tried to adjust I13 segment mode, velocity on this geometry seems not affected, still very slow and fluctuating. Only way we can improve this is to reduce TA and TS, which is not what we expected as the machine becomes a bit jumpy with smaller TA and TS.

 

Pls help. Thanks.

 

Luke

[steve.milici]

If the acceleration time exceeds the calculated move time PMAC will extend the move time to the acceleration time (slowing the move) to accommodate this constraint (TA/TS). Note that segmentation for a Clipper is Isx13 (I5113 for CS #1). Set the TA/TS (Isx87 and Isx88) and Isx13 as small as possible and use lookahead (Ixx16/Ixx17) to constrain the motor in the motion program. See the description of the lookahead feature in the Turbo PMAC Users Manual for implementation details.

 

Note that Spilne modes cannot use lookahead.

 

[lukewang]

One thing I dont understand is that velocity may get slower in this high block rate situation but it should not get bumpy regardless how i set up I variables. The reason being bumpy is that small blocks have various lengths, unless I set a very small TS to meet constraint of shortest block, or velocity will fluctuate on blocks with different lengths.

 

Reducing TS/TA/Isx13 a lot or adjusting them on the fly may be not feasible due to machine dynamic contraints. Since TS/TA/Isx13 has been set up at initial machine tune-up, it is not feasible either to change them just for certain part of geometry.

 

I used to work on an interpolation algorithm. If it looks ahead 50 blocks, then it assumes the velocity must be decelerated to zero at the end of 50th block. For any block joints between, it works out a transition velocity on each joint point depending on the angle formed by two joint blocks. If all short blocks are joined tangentially, the transition velocity on each block joint may not be dropped at all.

 

This kind of lookahead will solve this problem. And it makes sense for a series of smoothly connected short blocks, velocity stays stable. Anyway Clipper can achieve that?

 

 

[Sina.Sattari]

Lukewang,

 

Please make sure that your motion program or G-code post has at least 2 or 3 orders of magnitude more resolution compared to your feedback resolution in order to prevent any digitization noise on the lookahead calculations.

 

For example, if you have 1 count per 0.001 inch, then your g-code post should have at least 0.00001 inch resolution. This will greatly improve the performance of the lookahead.