Unclear documentation and Z lifts?

[Rencio7]

I compiled the latest Miracle-Grue - took me a while to figure out....I wish it was more clear in the first place..

I got qtk sdk but it kept saying stuff about Mesh.cc and Mesh.h in the libthing submodule...

I then read about scon on the mac style of compiling it..

So I downloaded scon for windows and tried scon --gui in cmd in the main folder and :D it compiled.

Knowing I couldn't use the normal gcode with A for the extruder part I eventually found the command

"useEAxis" : true

Which allows me to use Miracle Grue on my Mendelmax 3D printer.

But unfortunately on layer changes the Z axis plummets into the print (a tiny bit) and then up to the next layer height...

I don't really understand what's making it do this from the gcode but here is a snippet at the first layer change..

X4.430 Y-4.120 Z0.254 F1800.000 E5.759 (d: 0.38608)
(infill path, length: 2)
G1 X-4.430 Y-4.120 Z0.254 F1800.000 E5.872 (d: 8.86)
G1 F6000.000 E3.872 (snort)

(Slice 1, 1 Extruder)
(Layer Height: 0.254)
(Layer Width: 0.406)
G1 Z0.508 F1380.000 (move Z)
(insets: 0)
(infills: 0)
(support: 0)
(inset path, length: 5)
G1 X4.430 Y4.430 Z0.508 F9000.000 (move into position)
G1 F6000.000 E5.872 (squirt)
G1 X4.430 Y-4.430 Z0.508 F4800.000 E5.986 (d: 8.86)
G1 X-4.430 Y-4.430 Z0.508 F4800.000 E6.099 (d: 8.86)
G1 X-4.430 Y4.430 Z0.508 F4800.000 E6.213 (d: 8.86)
G1 X4.430 Y4.430 Z0.508 F4800.000 E6.326 (d: 8.86)
(connection path, length: 2)
G1 X4.797 Y4.797 Z0.508 F4800

A list of available config commands would be useful...as I had to search around for them..
This 'Z lift' is almost like the Z lift feature in kisslicer which removes slop theoretically.
But the thing is it goes down instead of up on the first lift.
It would be great if I could remove all of the starting header too as it is just annoying removing it each time - I tried adding my own header in config but it just amends at the top so I think it's hard coded. I'l recompile myself and edit it if it isn't done or optional as I really like the gcode Miracle Grue generates and the coarsness option.

Many thanks and great work :)

Rencio

[Rencio7]

I've tried all versions I could find including Makerware version and I still get this problem....hmm I will check my firmware and gcode sender.

Update: -

On Z lifts (up to the next layer) in the gcode error logs/console it says unknown command E0.000 S0 - I don't see it in the gcode so I don't know how it's a problem. :(

[jsadusk]

There are actually a few changes necessary for the gcode to be reprap
compatible, most noteably the fact that it always currently treats 0,0 as
the center of the bed. I didn't have time to work on this before because
we had to get a release out, but now that things are calm, I've actually
been doing some of this work this weekend. I have a mendel at home, so
it'd be nice to be able to use my own software:) I'll post here if I get a
working reprap compatible version. In the meantime, I'm going to make a
reprap_compat branch in git, and I'll put development there if you'd like
to track.

Joe

On Sun, Sep 23, 2012 at 10:44 AM, Laurence Stuart Laycock <
[email protected]> wrote:

I've tried all versions I could find including Makerware version and I
still get this problem....hmm I will check my firmware and gcode sender.

Update: -

On Z lifts (up to the next layer) in the gcode error logs/console it says
unknown command E0.000 S0 - I don't see it in the gcode so I don't know how
it's a problem. :(

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-8799085.

[Rencio7]

That would be great :) - I found the configuration.cc with the commands so I'll take a look.

I'm using repetier host too so there might be a bug - but I will check...I will use printrun to take out the chances.

I didn't have much problem getting printing it was just this Z lift thing and that was it.

[jsadusk]

On that note, I don't know why it'd be dropping into the bed after the
first layer change. The logic for layer changes shouldn't be machine
specific and the gcode you posted only has a positive Z move. Also, what
starting header are you removing? The comment block at the beginning?
That really shouldn't have a problem with reprap firmwares, commenting
gcode is standardized. If it is causing problems the solution shouldn't be
to remove it, it should be to do it in a comment style that works. I'll
add that to the list.

Oh and finally, yes, definitely use scons to compile. There are qt creator
.pro files, but that was an abandoned build system. scons is vastly
superior, and our scons builds have been kept up to date unlike the qt
build. I'm not sure about the --gui build. It should work, but it's not
kept up to date especially well. It was an early attempt to put a gui that
was dropped in favor of the rest of the makerware stack. If you're
comfortable using miracle grue on the command line, that is much more
actively maintained.

Joe

On Sun, Sep 23, 2012 at 10:49 AM, Joseph Sadusk
[email protected]:

There are actually a few changes necessary for the gcode to be reprap
compatible, most noteably the fact that it always currently treats 0,0 as
the center of the bed. I didn't have time to work on this before because
we had to get a release out, but now that things are calm, I've actually
been doing some of this work this weekend. I have a mendel at home, so
it'd be nice to be able to use my own software:) I'll post here if I get a
working reprap compatible version. In the meantime, I'm going to make a
reprap_compat branch in git, and I'll put development there if you'd like
to track.

Joe

On Sun, Sep 23, 2012 at 10:44 AM, Laurence Stuart Laycock <
[email protected]> wrote:

I've tried all versions I could find including Makerware version and I
still get this problem....hmm I will check my firmware and gcode sender.

Update: -

On Z lifts (up to the next layer) in the gcode error logs/console it says
unknown command E0.000 S0 - I don't see it in the gcode so I don't know how
it's a problem. :(

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-8799085.

[Rencio7]

Thanks so much for the quick replies - much appreciated :)
So you are saying the gui has a different backend?
Is the command line a newer version?
It says it's still 0.04 on a few versions but I think that version string just hasn't been updated.

[Rencio7]

I'm fine with comments - I think they are very helpful inded :)..

It's just the starting part where it extrudes a little on its own - it's not too much problem though.

[jsadusk]

The GUI links to the same libmgl library as the command line, but the
interface between the two isn't as separated as I'd like. And because the
command line is what is called by MakerWare, that's what has gotten
tested. So, if there's some crucial piece of data that we added that
libmgl needs, that never got added to the GUI, I know I wouldn't have
caught it. On the other hand it may work fine. I don't know! It'll get
tested eventually, though that particular gui may get replaced with
something else.

Oh and yeah, heh, 0.4 just never got updated. I'll get to that.

Joe

On Sun, Sep 23, 2012 at 10:57 AM, Laurence Stuart Laycock <
[email protected]> wrote:

Thanks so much for the quick replies - much appreciated :)
So you are saying the gui has a different backend?
Is the command line a newer version?
It says it's still 0.04 on a few versions but I think that version string
just hasn't been updated.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-8799191.

[jsadusk]

Oh that! That's the anchor, on replicators and rep2s it was helpful to
flush the nozzle by drawing a line up to the object. It really should be
made into an option though. Another thing for the list:)

Joe

On Sun, Sep 23, 2012 at 11:00 AM, Laurence Stuart Laycock <
[email protected]> wrote:

I'm fine with comments - I think they are very helpful inded :)..

It's just the starting part where it extrudes a little on its own - it's
not too much problem though.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-8799208.

[Rencio7]

I managed to find out what it was - you see the (d : 8.86) next to some of the lines - the gcode senders I've used don't like the colon - I remember this from when netfabb engine had a comma in the gcode and I had a similar problem...

I removed all the colons and it's still printing right now :)...

So it seems it's just the colons :)..

Cheers

Rencio

[Rencio7]

Apologies for the slightly false information - it was actually one of the comments though - I'm not 100% though it's one arounnd the layer change...

I did this in notepad --- replace '(the letter at start of comment' with ';(the letter at start of comment' so it actually detects it properly as a comment and doesn't read it.

I'll send youa pic of this print when it's done :)...

It's definitely not doing the plummet on the Z now - 100% :D - so it's the comments - I'm thinking one beginning with 's' as it came up with unknown command 'E0.000 S0' in 2 gcode senders and 2 different firmwares..

[jsadusk]

Interesting, I guess different gcode parsers expect comments in either
parens or after a semicolon. I can make that configurable as well, but its
less of an easy fix because I've got hardcoded comment strings all over the
place. Anyway, I really appreciate the info and testing, everything helps.

Joe

On Sun, Sep 23, 2012 at 12:33 PM, Laurence Stuart Laycock <
[email protected]> wrote:

Apologies for the slightly false information - it was actually one of the
comments though - I'm not 100% though it's one arounnd the layer change...

I did this in notepad --- replace '(the letter at start of comment' with
';(the letter at start of comment' so it actually detects it properly as a
comment and doesn't read it.

I'll send youa pic of this print when it's done :)...

It's definitely not doing the plummet on the Z now - 100% :D - so it's the
comments - I'm thinking one beginning with 's' as it came up with unknown
command 'E0.000 S0' in 2 slicers

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-8800050.

[Rencio7]

I know this isn't really the place to put this but I couldn't find your email soo..

Here was my first print with miracle grue - http://horobox.co.uk/u/Rencio7_1348566576.jpg
I was pretty happy with it :) - I think the fact it was only on 2 shells and 0.2 infill didn't help at all on surface quality - as there were a few gaps - I've got the coarseness setting pretty fine - there maybe more detail than the next kisslicer one even...I was impressed with the support material coming off easily :)...

Here is a comparison with my tweaked settings in kisslicer : - http://horobox.co.uk/u/Rencio7_1348604377.jpg
Pretty high infill - same layer height - I did use a setting to help with z slop though which may of helped.

Overall I almost prefer miracle grue's toolpath - it seems more efficient - from what I've seen - I'm going to use it from now on and see if I can tweak it even more..

One thing I really like is the volumetric calibration - I had to make no tweaks at all - except filament diameter - which is nice...usually I have to at least up the flow rate or decrease it - a little with new slicers.

I'll update with more photos if you think useful/relevant

One more thing - I do all the slicing via the gui - so ye it works :)........

I had a look with Qt at the form/gui in Qt designer - I'd like to tweak it myself and see if I can make more config accessible/tweakable through it - it seems not very hard to do from the variables - although I've never done C++ before...

I managed to find where the bracket option for comments was in the code and changed it myself to ; to test...
Ye it doesn't change all of them - like you said some are hard coded in....

The only real bug I've seen (maybe).... is 1 diagonal line of infill not being filled in on some layers

I'll analyse the gcode later.

Cheers

Laurence

[jsadusk]

Settings I'd play with are layerWidthRatio and insetDistanceMultiplier.
Some of the blobs you're getting may be from too much plastic being used on
shells, and those are the main ways of controlling that. And yeah, its
completely volumetric. As long as your E_STEPS_PER_MM is correct, the flow
rate should be correct. A caveat I'll give, it doesn't yet handle very
small layer heights (sub .2mm) well. That requires a more complex volume
calculation that we haven't implemented yet. That's coming in the next few
months.

And yeah, we've put a lot of work into optimizing the toolpath, though
there's still more work to be done. We use a graph based approach to
figuring out what order to do the pieces of a layer in, and how to connect
them. We're currently optimizing for turning off the extruder as little as
possible, so if we can connect two things in a layer by only crossing
infill, we'll just draw an extra line across that infill. It makes prints
faster and parts stronger with fewer strings, but on parts with very
complex outlines it can end up with a lot of internal lines. We're working
on a balanced approach for the next version. Z slop minimization is
something I definitely want to do also, and I have some ideas.

Thanks for trying it out!

Joe
On Tue, Sep 25, 2012 at 3:46 AM, Laurence Stuart Laycock <
[email protected]> wrote:

I know this isn't really the place to put this but I couldn't find your
email soo..

Here was my first print with miracle grue -
http://horobox.co.uk/u/Rencio7_1348566576.jpg
I was pretty happy with it :) - I think the fact it was only on 2 shells
and 0.2 infill didn't help at all on surface quality - as there were a few
gaps - I've got the coarseness setting pretty fine - there maybe more
detail than the next kisslicer one even...I was impressed with the support
material coming off easily :)...

Here is a comparison with my tweaked settings in kisslicer : -
http://horobox.co.uk/u/Rencio7_1348604377.jpg
Pretty high infill - same layer height - I did use a setting to help with
z slop though which may of helped.

Overall I almost prefer miracle grue's toolpath - it seems more efficient

• from what I've seen - I'm going to use it from now on and see if I can
  tweak it even more..

One thing I really like is the volumetric calibration - I had to make no
tweaks at all - which is nice...usually I have to at least up the flow rate
or decrease it - a little with new slicers.

I'll update with more photos if you think useful/relevant

One more thing - I do all the slicing via the gui - so ye it works
:)........

I had a look with Qt at the form/gui in Qt designer - I'd like to tweak it
myself and see if I can make more config accessible/tweakable through it -
it seems not very hard to do from the variables - although I've never done
C++ before...

Cheers

Laurence

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-8846084.