Waterline machining proposals

[user1234]

Hello!

I thing that depends strongly from the controller which runs at the machine, and the machine itself.

That is clear. This is the reason why i wrote, that newer machines have no problems with that. And for stepper only G01 is really not good.

there are no G command at it, - just N commands:

Look at the code. Ther are only G01 orders! N means number. If you wrote

Code: Select all

N10 G01 .....
N20 G02 .....

than the controller make at first N10 and than N20 means

Code: Select all

N20 G02 .....
N10 G01 .....

is the same order of work. And when you write

Code: Select all

G01 X.... Y....
X.... Y....

the order G01 permanent as long you set no other G order. The code that you posted is starting from line number 36 (N36) only G01.

Greetings
user1234

[JoshM]

the order G01 permanent as long you set no other G order.

I know what you're driving at. G01 is Modal, so feed-rate remains constant. G02/G03,etc are also Modal so you can run those and for no specified Feed-Rate it stays at speed. The Post-Processors have a MODAL flag, which I believe drops the explicit FR from lines until it changes, or goes to a non-modal command. I believe the LinuxPP MODAL flag may have an issue--and/or an issue with Drilling Op.

Agree this depends heavily on controller. I use Mach3 at work, and I don't think it matters if you give it a bunch of lines or an arc. I wouldn't count on it across machines.

As Chris mentioned, it's a pain reading through though. I've used PCB Milling software that outputs lines--lots of them. Easy to break tools and hard to restart correctly.

And, I tend to agree with Gene's point about typical user base of FC PathWB needs.

PathWB outputs it's own internal code--including G02/G03, etc. The PP interprets those. If the wires fed to it by the developer include arcs, they get passed as such. Julian suggested the mesh approach is something he has experience developing, and that experience says the benefits outweigh the negatives. Put me first in line to use the tool if he implements it
Josh

[JoshM]

Out of curiosity, I created processed a Cut Sphere Job, with a BallEndMill using the algo I have worked on.

I make a face on the top of the stock model from the OuterWires of the Radial offset ToolSurface.
From that, I use PathFeatureArea to create a Zig-Zag or Offset pattern onto the stocktop.

The wires of the tool path pattern are projected using

Code: Select all

 makeParallelProjection(path_wires,-Vec_Z)

onto the Radial offset ToolSurface. In the projection, the result is in lines, and the inspect-GCode shows G1 codes.

GCode__Projection.png (264.06 KiB) Viewed 700 times

In contrast, if I use Part.Section to slice the same Radial offset ToolSurface generated in my script, then make a Path.FromShape, the GCode generated uses G1/G2/G3, as needed.

GCode__PartSlice.png (195.39 KiB) Viewed 700 times

Path's Wire->GCode generation supports either. Where mesh results in lines, can they be converted to arcs?

[routalot]

I have been watching this thread for a little while and find the topic of great interest.Once refined,this will allow us to do a great deal of interesting stuff and I look forward with considerable excitement to seeing the project advance.I regret that I lack the depth of computer knowledge to help push it forward and I thank those who do.