Gcode from slic3r is shown in white

[rickarddahlstrand]

Hi,

Thanks for a great application and the best gcode viewer. If you fix this issue a donation is coming your way!!

When I view a gcode from slic3r it is displayed in white and if I load a gcode from replicaterG I get the nice golden display. Probably an easy fix.

Rickard.

[sbliven]

Slic3r compatibility would be awesome.

Some specific things that don't work:

• Always colored opaque white regardless of speed, local density, etc
• The first layer is empty, so switching to 2D initially appears to be broken (but actually works fine with higher layers)
• Slic3r objects are not centered

I did some tests for what gcode features might be required for proper display.

• Removing all comments from the ReplicatorG file results in a 2-layer display, with colors repeating aperiodically across different z-heights
• Removing all comments plus the initial move to the top-left corner (G1 ... Z150 for me) results in normal coloring, plus an empty layer 1
• Removing all comments plus all G* commands from the header results in the correct number of layers & coloring
• Adding ( 0.X) lines to the Slic3r output fixes the empty first layer. Adding or removing lines changes the number of layers displayed
• Adding M101 commands to the Slic3r output after each G92 line resulted in reasonable coloring & proper transparency when moving the layer slider

So without looking at the code, it seems like Pleasant3D:

1. Checks for embedded XML, and uses that to determine layers if present
2. Look for G* commands. Every time the Z increases, add a new layer
3. Every M101 command, create a new group of paths. Each path in a group has the same color and opacity

So to improve Slic3r compatibility, we generally need:

• Ignore initial non-extruding moves, so that homing commands don't modify the centering
• Start new path groups more flexibly. At a minimum, each new layer should trigger a new group. Better would be to start a new group after every travel, where a travel consists of M101 or a non-extruding move

[sbliven]

This issue is fixed in @miwucs branch, which also includes a bunch of code from @hackable-devices. I'm not sure what the plans are for merging that code back into this repo, but the newer version is working for me.

[tchapi]

Hi all,

The @hackable-devices tag v2.3 contains all the changes made by @miwucs and some other improvements discussed together, that should cover most of the problems with Slic3r.

This branch also includes estimated time and filament cost for each extruder head, as well as weight of printed part, and a better way of displaying double-extrusion gcodes.

I'm actively working on it at the moment to address all the remaining little things (the centering is one of them) and keep up with the new slicers that are used by the community right now, so don't hesitate to post an issue on the repo in case you find something, or PR any changes you find relevant.

Plans for merging have not yet been discussed with @zaggo since he hasn't been authoring lately, but I would be delighted to merge these improvements back if everybody finds them useful !

Best, Cyril

[sbliven]

@tchapi Nice! I didn't notice at first that you'd rebased @miwucs changes. I'll switch to your branch.

I'm sure plenty of people would appreciate an official v2.3 release, if @zaggo has time to bless the code and build a binary.

[zaggo]

@tchapi thanks for your work on Pleasant3D. Sorry, that I hadn't any time to work on Pleasant3D lately. Please send me a Pull request for your changes and I'll try to review (and integrate) them to the main branch as soon as possible. Cheers, Eberhard

[tchapi]

Hi @zaggo, good to hear from you !

No problem for your time, that's what the community is for. I think a lot of people (including myself) are already very happy that you released the code under GPL v3.

I'm still tuning some stuff here and there, I'll make sure everything is wrapped up correctly before I send a PR over to you. Also, in my branch, I've routed the Sparkle updates to our servers (since we're pushing for a lot of people to use Pleasant3D as their main Gcode viewer, I had to be able to push my code updates to them seamlessly).

Best regards, Cyril

[zaggo]

Ok, the pull request from tchapi is now integrated, i.e. the slic3r issue is fixed.

There are still some issues with memory management (especially concerning the Quicklook plugins) in the current HEAD (a76bd05acc12e4f132f9badac9c2443b089ea652). I'm already working on this and I'll push theses changes as soon as possible...