[v1.2.4-experimental] various "G4" pause commands of random length inserted in GCODE #2483

Closed
simonkuehling opened this Issue Jan 2, 2015 · 16 comments

Projects

None yet

6 participants

@simonkuehling

I just gave the 1.2.4 binary a run:

  • Ubuntu 14.04 64bit
  • Slic3r v1.2.4-experimental 64bit

and see a huge number of "G4" commands in my GCODE... like this:

G1 X106.893 Y108.797 E2.25910 ; perimeter
G1 X106.272 Y109.240 E2.27906 ; perimeter
G4 P253                                                            <-------------------
G1 X108.150 Y117.617 E2.50367 ; perimeter
G1 X108.216 Y118.575 E2.52880 ; perimeter
G1 X106.594 Y118.930 E2.57224 ; perimeter
G1 X103.983 Y119.191 E2.64088 ; perimeter
G4 P214                                                            <-------------------
G1 X104.367 Y118.700 F12000.000 ; move to first perimeter point
G4 P496                                                            <-------------------
G1 X104.352 Y118.166 E2.65487 F900.000 ; perimeter
G1 X101.164 Y106.774 E2.96437 ; perimeter
G1 X101.049 Y106.070 E2.98304 ; perimeter
G1 X101.089 Y105.328 E3.00247 ; perimeter

I have no clue where these come from :-)

Files to reproduce:
config
STL
GCODE

@alexrj
Owner
alexrj commented Jan 2, 2015

Those are because of Vibration Limit :)

@simonkuehling

(damn, that was fast! ;-)

Ah!

Can you give me a quick hint why it is implemented like this instead of reducing the print speed where needed?

@alexrj
Owner
alexrj commented Jan 2, 2015

I don't remember :-P

I think Vibration Limit should be deprecated some day, as it's no more than a hack for supporting bad hardware...

@simonkuehling

If i remember correctly, we started to use vibration limit as a workaround for the "minimum resolution" feature not being applied to support material paths...

Some organic models generated extremely fine segmented support paths (as a result of polygon offsetting etc). In order to avoid short stops in a print due to bandwith limits of the USB/Serial connection between host and arduino, this usually did the trick.

Maybe the the resolution issue is already resolved meanwhile? I do not find the corresponding github issue where this was discussed unfortunately...

@alexrj
Owner
alexrj commented Jan 2, 2015

Yeah, that was for gap fill before I used medial axis for it - it was generated with a very fine rectilinear infill which actually produced a superfast zigzag instead of straight lines. Some printers having not very rigid axes (because of inertia and/or elastic belts) suffered from resonance thus skipped steps. So I implemented vibration limit. But I really think the need for it is over and maybe I should start marking it as "deprecated"...
(G4 instead of F variation was probably because of implementation complexity, since F must be changed before the vibration takes place, whereby G4 can be added after it is detected.)

@simonkuehling

Ok, i agree that the vibration limit may safely be marked as deprecated...

But - is the "minimum detail resolution" feature also applied to support paths already or just to the 2D slice polygons before further processing?
This feature is already absolutely essential for a whole bunch of models that we see from customers on a daily basis - like super detailed 3D scan models and weird CAD exports and such.
To keep the communication bandwith with the arduino under control, it would be really cool to somehow limit the minimum segment length for all paths.

@alexrj alexrj added this to the 1.2.5 milestone Jan 4, 2015
@alexrj
Owner
alexrj commented Jan 4, 2015

Resolution is only applied to slices after perimeters are generated and before other things are done - including support material...

@alexrj alexrj closed this Jan 4, 2015
@sauce71
sauce71 commented Jan 9, 2015

I use vibration limit for noise reduction. Hope it stay, maybe refactor to slowing down when printing very short paths?

@triffid
Contributor
triffid commented Jan 30, 2015

I use vibration limit too, my printer is absolutely terrifying when it resonates.. would much prefer slowdown rather than pauses though

@alexrj
Owner
alexrj commented Jan 30, 2015

Altering speeds was complicated; I tried but failed to implement an algorithm for that. Since it's not in my priorities, I accept clean, nicely-coded pull requests. :)

@lordofhyphens
Collaborator

Something that might help is to use a sliding window of path segments, and allow the slicer to go back to an earlier segment and recalculate the speed for all steps up to the detection of undesired vibration. If we can detect what constitutes vibration, then we should be able to figure out how to alter speed to avoid vibration.

Anything that falls out of the window can be assumed to be not changing (and thus get printed out as gcode). Also I think that the speed of the segment should not exceed whatever it was originally. I will see what I can figure out. I suspect that the simplest arrangement, pushing everything that passes out of the window onto a queue, would also be the most memory intensive solution. I will have to study the path a segment takes to become gcode in the source.

Where is vibration detection implemented now? Libslic3r or perl?

This might also be solvable in firmware, but that depends heavily upon how much look-ahead the firmware had.

@alexrj
Owner
alexrj commented Jan 30, 2015

Yes, a buffer. But you need to check X and Y axes separately, and when you change a speed you also affect the slowdown applied to other lines. You'll see that it's not that easy. :)
There's a VibrationLimit.pm file where the current algorithm is implemented.

@lordofhyphens
Collaborator

I didn't think it would be easy :)

Lines as in other path segments or gcode lines?
On Jan 30, 2015 3:20 AM, "Alessandro Ranellucci" notifications@github.com
wrote:

Yes, a buffer. But you need to check X and Y axes separately, and when you
change a speed you also affect the slowdown applied to other lines. You'll
see that it's not that easy. :)
There's a VibrationLimit.pm file where the current algorithm is
implemented.


Reply to this email directly or view it on GitHub
#2483 (comment).

@alexrj
Owner
alexrj commented Jan 30, 2015

Same thing, as one G-code line contains at most one segment

@lordofhyphens
Collaborator

While this is going to be "fun" to try to implement in perl, the current
idea I had was to put the vibration check and change in-line; as it were,
and modify the information being sent to the next step. Then I would buffer
the lines internally. If buffer is not full function returns some harmless
noop. If buffer is full then the oldest entry is returned instead. This
should give our function freedom to change whatever it wants in buffer
without upsetting other parts of the slicer.

Of course I am spitballing here. I haven't studied the source yet.
On Jan 30, 2015 3:30 AM, "Alessandro Ranellucci" notifications@github.com
wrote:

Same thing, as one G-code line contains at most one segment


Reply to this email directly or view it on GitHub
#2483 (comment).

@ClusterM

I use vibration limit too, my printer (and table!) is resonates very much and loud. It's fine when it's limited to 15Hz.
But I want feature to define minimum/maximum amplitude too because I don't need this limit when distance is too short (less than 0.2mm).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment