G Code Generation

I think that this might be a limitation in the current LinuxCNC.

The problem is that the trajectory planner only looks as far as the end of the next move.
In effect all the way through move N it blends to move N + 1 and assumes that move N + 2 is a dead stop.

This means that on very short moves the speed is much lower than it needs to be.

This is pretty much top of the list of things that will be changed in the next version. (i.e., LinuxCNC 3.0)

That might be a long wait, though.

In the meantime, you could try longer moves, and let the LinuxCNC blending smooth it out.

diegoroman17 wrote:

Now understand the because of slow moves but why it problem if LinuxCNC have look ahead?[/quote[
The point is that LinuxCNC does't look ahead very far. If the next 3 moves are all one nanometer long then LinuxCNC will only move at the speed that allows it to stop dead in 3nm.

How can I recreate a parametric curve with large moves?

Maybe make the step/precision bigger?

diegoroman17 wrote:

Andy could we try to make that improvement LinuxCNC now?

I am not currently involved in that part of LinuxCNC, and it is a huge change. The whole nature of hoe G-code gets to motor commands needs to be done differently.

The idea, as I understand it, is to convert the G-code into a linear list of moves, and then to propagate allowed speeds back down the chain (backwards in time).

Interesting reading here: thread.gmane.org/gmane.linux.distributio...evel/6450/focus=6499

From the user side there is this chapter

linuxcnc.org/docs/html/common/User_Concepts.html

From a programmer side you would have to examine the code.

John

I'm not sure if your asking a question or not? If you are can you describe it a bit differently?

John