Mach3 remove G0

[Feist92]

I was using 0.7.1 before and getting almost perfect results in mach3. Ive now upgraded to 0.9.9 and the amount of options are awesome in expert mode but I cant use it because G0 causes a dwell or pause every time its used. Is there and option to use G1 instead of G0? Frankly it was working so well before i cant see any reason to use G0 at all, I may have to resort to using the old version but i really need all the options that 0.9.9 offers

would greatly appreciate any input

[alranel]

Why would Mach3 pause when reading G0? That doesn't sound like a correct behavior.

[Feist92]

Thats what I initially thought but I used 0.9.9 to slice then replaced all of the g0 with g1 and im back to good smooth prints. Ive tried this on two different versions of mach3 as well with the same results. Im open to any suggestions you can think of

[mesheldrake]

From my EMC2 experience, G0 is not just full-speed G1. Here's a layer change with G0:

G1 X90.824 Y71.041 F2520.000 A7.90136   LAST LINE PREV LAYER
G0 Z0.500 F9000.000 A6.50136            UP TO NEXT LAYER, WITH RETRACTION
G0 X85.171 Y87.034                      TO NEXT LAYER START POINT
G0 F1500.000 A7.90136                   RECOVER
G1 X85.933 Y87.034 F3360.000 A7.92189   FIRST LINE NEW LAYER

Note that the A axis move on the second line won't happen at F9000, but instead will happen at the mach3-configured maximum speed for the A axis (also subject to acceleration settings for that axis).

There also might be an axis sequence for a rapid move, where A goes first, then Z, then XY, or A, then XYZ, or whatever - point being, with a G0 you may not be getting coordinated movement between all axes.

You might try disabling retraction just to see if that eliminates the dwell. If it does, your A axis top speed/rapid speed and acceleration settings might be the issue.

[nophead]

Seems wrong that G0 is use for retract and restart. I think it should just be for X Y travel moves, where the speed, acceleration and coordination are unimportant.

On 5 June 2013 09:07, Mike Sheldrake notifications@github.com wrote:

From my EMC2 experience, G0 is not just full-speed G1. Here's a layer change with G0:

G1 X90.824 Y71.041 F2520.000 A7.90136 LAST LINE PREV LAYER G0 Z0.500 F9000.000 A6.50136 UP TO NEXT LAYER, WITH RETRACTION G0 X85.171 Y87.034 TO NEXT LAYER START POINT G0 F1500.000 A7.90136 RECOVER G1 X85.933 Y87.034 F3360.000 A7.92189 FIRST LINE NEW LAYER

Note that the A axis move on the second line won't happen at F9000, but instead will happen at the mach3-configured maximum speed for the A axis (also subject to acceleration settings for that axis).

There also might be an axis sequence for a rapid move, where A goes first, then Z, then XY, or A, then XYZ, or whatever - point being, with a G0 you may not be getting coordinated movement between all axes.

You might try disabling retraction just to see if that eliminates the dwell. If it does, your A axis top speed/rapid speed and acceleration settings might be the issue.

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1212#issuecomment-18961275 .

[mesheldrake]

I agree.

[Area5142]

In Mach3 G1 moves are in straight lines with speed limit and G0 is moves as fast as possible with non coordinated axis (may be straight line, but no guaranty). This gives the trajectory planner problems if the moves are mixed G0/G1, resulting in stops and non smooth operation. Replacing G0 with very fast G1 moves will give a more smooth operation and keep the trajectory planner working (look ahead). As Mach3 will never exceed maximum speeds/acceleration for any axis the F parameter can be arbitrary high. I did this in the post processor for my laser engraver to solve the same problem.

[alranel]

@nophead, why do you think it's wrong? Combining travel with retraction in a single command is only possible with G0, because G1 will apply a huge slowdown to the retraction to synchronize it with the end of the travel move. Combining retraction and travel with G0 looks like a very efficient way for saving time instead of doing them in two separate steps. Don't you think so?

[nophead]

Because G0 is uncoordinated move. It tries to go as fast as possible and doesn't follow the trajectory. For example on my lathe driven by LinuxEMC it will take a short cut by rounding the corner when told to do a right angle with G0.

On 5 June 2013 14:48, Alessandro Ranellucci notifications@github.comwrote:

@nophead https://github.com/nophead, why do you think it's wrong? Combining travel with retraction in a single command is only possible with G0, because G1 will apply a huge slowdown to the retraction to synchronize it with the end of the travel move. Combining retraction and travel with G0 looks like a very efficient way for saving time instead of doing them in two separate steps. Don't you think so?

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1212#issuecomment-18976460 .

[alranel]

Sure, then I don't see why would that be a problem when combining retraction with a travel move. Both retraction and travel will start at the same time, and each one will finish as soon as possible according to its max speed.

What would be the common trajectory of a combined XYE move? :-)

[nophead]

Well it doesn't obey the F, it goes as fast as it can and may blend it with previous G0 moves.

On 5 June 2013 15:01, Alessandro Ranellucci notifications@github.comwrote:

Sure, then I don't see why would that be a problem when combining retraction with a travel move. Both retraction and travel will start at the same time, and each one will finish as soon as possible according to its max speed.

What would be the common trajectory of a combined XYE move? :-)

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1212#issuecomment-18977287 .

[nophead]

It might be OK for retract. I don't know where it gets the A max feed rate from as my CNC machines don't have an A axis. The G0 XY speed comes from a slider in the GUI.

I definitely don't think it is a good idea for the fast forward as you want that closely synchronised with the following G1 and at the correct speed, which might not be as fast as possible.

On 5 June 2013 15:07, nop head nop.head@gmail.com wrote:

Well it doesn't obey the F, it goes as fast as it can and may blend it with previous G0 moves.

On 5 June 2013 15:01, Alessandro Ranellucci notifications@github.comwrote:

Sure, then I don't see why would that be a problem when combining retraction with a travel move. Both retraction and travel will start at the same time, and each one will finish as soon as possible according to its max speed.

What would be the common trajectory of a combined XYE move? :-)

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1212#issuecomment-18977287 .

[alranel]

Uhm, is G0 blocking or non-blocking? In other words, doesn't G0 wait for previous line to complete?

What happens if we have a travel followed by a restart like this:

G0 X10 Y20 G0 E1

Will this wait for the nozzle to be at 10,20 before moving E?

[nophead]

No not in my experience in LinuxEMC. If I go G0 X100 Y0 followed by G0 X100 Y100 it starts the Y axis moving before the X axis stops. I.e. I get a rounded corner instead of a right angle so it can keep the speed up.

On 5 June 2013 15:38, Alessandro Ranellucci notifications@github.comwrote:

Uhm, is G0 blocking or non-blocking? In other words, doesn't G0 wait for previous line to complete?

What happens if we have a travel followed by a restart like this:

G0 X10 Y20 G0 E1

Will this wait for the nozzle to be at 10,20 before moving E?

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1212#issuecomment-18980648 .

[alranel]

Ok, thank you. I thought it was blocking (i.e. unsynchronized among axes in the same line but still blocking for next line). This leads to the conclusion that G0 is wrong for the restart. I'll change this one.

[nophead]

It is blocking. I.e. it doesn't start Y at the same time as X in the example I gave but it is blended with much looser constraints than G1, so it rounds off the corner.

On 5 June 2013 15:52, Alessandro Ranellucci notifications@github.comwrote:

Ok, thank you. I thought it was blocking (i.e. unsynchronized among axes in the same line but still blocking for next line). This leads to the conclusion that G0 is wrong for the restart. I'll change this one.

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1212#issuecomment-18981636 .

[alranel]

Okay, so I switched to G1 for restart after retraction. Slic3r is still using G0 (when Mach3 output is selected) for travel moves (XY and Z) and retraction. Does this sound more correct?

[nophead]

Yes for a 3D printer. I was quite surprised by the G0 corner cutting as on a lathe, or when 3D milling it could cause a tool collision. I guess G0 is not used even for travel moves in those situations where the axes need to be coordinated.

On 5 June 2013 16:00, Alessandro Ranellucci notifications@github.comwrote:

Okay, so I switched to G1 for restart after retraction. Slic3r is still using G0 (when Mach3 output is selected) for travel moves (XY and Z) and retraction. Does this sound more correct?

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1212#issuecomment-18982217 .

[alranel]

Yeah, we don't assume nor rely on travel straightness. ...uhm, actually we rely on it when "avoid crossing perimeters" is enabled. No risk of collisions, just risk of defeating the purpose of that feature by crossing corners. Okay, I'll switch to G1 in that case too.

[alranel]

Done in 8c40cefe1ed8dbaecafc02282ba40326d9171dbc

[markotime]

Um, Mach3 has enable / disable constant velocity / contour, so that at rapid speeds, you can either enable corner rounding or insist on a stop. Don't know about EMC, but it strikes me that this issue should be kept separate from the retraction one. I'm gonna run away and try G1. Not facile enough with scripting to rewrite the gcode to retract during, rather than before, a move. I think I'd rather have a bit of a thread than a wimbledon.

[Area5142]

In my experience (Mach3) switching between G1/G0 moves empties the trajectory planner and give non-smooth overall operation. When this happens the overall performance are very low. This can be fixed by replacing the G0 moves with G1 and high feed rate and only use G0 moves when the distance is long. There is nothing gained with short G0 moves. Mach3 should be in Constant Velocity mode (G64) and not Exact Stop (G61) for best performance and smooth operation. The more detailed setup for G64 can be done on the configuration page. I would choose G1 moves even if overall performance was a little lower.

[Feist92]

Thats what ive found too, the trajectory planner seems to halt every time it sees g0 then has to catch up to whatever look ahead you've set before things start moving again. In mach3 at least its actually detrimental to use g0 at all unless its to return to zero at the end of a print

[alranel]

So, this issue should be resolved by the two commits referenced here. Can anyone confirm we can close this one?

[markotime]

yes, thank you. Update on my own H1 problems - new hot end and new nozzle designs seem to have solved most issues with dribble. thanks for support /mark

Alessandro Ranellucci wrote:

So, this issue should be resolved by the two commits referenced here. Can anyone confirm we can close this one?

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1212#issuecomment-20551644.

No virus found in this message. Checked by AVG - www.avg.com http://www.avg.com Version: 2013.0.3345 / Virus Database: 3204/6468 - Release Date: 07/05/13

[alranel]

Thank you for feedback!