Closed N4rki closed 6 years ago
I build on Windows with MinGW (using a customized Strawberry Perl available on the wiki) . You'll have to be savvy with GDB though.
My primary build system (when I am not debugging windows specific issues) is Debian Linux. I suggest using perlbrew on a development system, but Slic3r works fine with system Perl. Just install local-lib from the packages.
My preferred editor on both is (g)Vim :)
Add -g to your CXXFLAGS environment variable (or edit build.PL or the cmake directly).
@lordofhyphens Thanks, that helped a lot! And adding -g worked wonders for gdb :)
I'm happy to debug with gdb, but having some Vim integration for gdb with in-text highlighting would be a huge help. Do you use such a plugin when debugging on windows? I'm asking because I can't get ConqueGdb to work properly. The Conque Shell and gdb runs normally but without going through and highlighting the actual code in Vim. Google gave me nothing that worked. But I guess I'll just go with gdbgui then.
Concering issue 1, I explored this further. So basically I type something into the SVG header text in SLAPrint.cpp (SLAPrint::write_svg) just to see if my changes are implemented into the programm through compiling. Should be a no-brainer, since it's kind of the definition of compiling from source, right? But yet when I compile with perl build.pl
and then process an example with perl slic3r.pl torus.stl --export-svg -layer-height 0.2
the header in the generated svg file is in its original state, not what I changed it to.
Weirdly, when I then build the CLI only version from the exact same source code with cmake and MinGW in a separate folder, then run slic3r.exe torus.stl --export-svg -layer-height 0.2
, the generated svg file does have these changes in its header.
Do you have any ideas what's going on here?
[edit] Do you use perl -d slic3r.pl
to debug the whole application or are there better ways?
I try not to debug on Windows :)
Usually I don't need to go into detail on the perl side so my debug methods have been loading core dumps after the fact (as I am usually looking at crashes), or I am sticking diagnostic print statements into the source itself.
So I will try to have a better answer for you later.
Conque indicates that it needs Python support in gVim to work. That also means that the correct bitness (32 vs 64bit). :version
will tell you what it is and what options it is linked with.
I don't know if you've checked that support yet with :echo has("python")
and related things yet, but it's a good idea to do so.
https://stackoverflow.com/questions/4718122/how-to-enable-python-support-in-gvim-on-windows
Conque indicates that it needs Python support in gVim to work. That also means that the correct bitness (32 vs 64bit). :version will tell you what it is and what options it is linked with.
I don't know if you've checked that support yet with :echo has("python") and related things yet, but it's a good idea to do so. https://stackoverflow.com/questions/4718122/how-to-enable-python-support-in-gvim-on-windows
Yes I tried those things. My Vim had python. I went pretty deep down the rabbit hole with some of it. I though the fact that MinGW needs to have GDB might be the cause. Because I do have MinGW (from Slic3r Perl) and I do have GDB. I just wasn't so sure if my MinGW had gdb (and if that might matter).
The problem is that when getting MinGW through Slic3r Perl mingw-get.exe install gdb
gave me a lock error although I ran the CLI as admin.
So I deleted Slic3r Perl to start with a fresh plate when it comes to MinGW. Installed that the normal way, added gdb to it but got the exact same results.
I'm trying to get gdbgui to work now which is a mess on windows too. I'm very close to convincing my boss to use a linux virtual machine which he was open to as a last resort but it would still be frustrating after having come so close to get a workflow going on windows. Anyway thanks for the help, I'm sure I'll find a way.
If in the meantime, if anybody has any pointers for me on how to implement my feature that'd be cool, too! I'm not quite yet sure where exactly where I would take the color values of different objects in a .3mf from. I will update this with my findings.
For looking at 3mf, look over the existing importer first. You may need to extend the existing code for that.
Ok, last sanity check: your gvim and python are both either 64 bit or 32bit right ?
The default mswindow build of gvim is 32bit.
Yes, I matched the bitness of gvim and python.
I did find the solution to get gdbgui working though: I had not only install normal MinGW but also add all packages in the installation process. Don't know which one made the difference but apparently not everything thats needed is included by default. Didn't help the ConqueGdb Vim plugin but I'm happy with switching to gdbgui.
Finally I can start working :)
So the one wrinkle you may come across is anything that throws an exception; you need to make sure that SEH exceptions are being used. SJLJ causes hangs when exceptions percolate up to the Perl side.
I think the default exception model of gcc7 for mingw is SEH, but you should check your download to be sure.
It is the reason why I had rolled Slic3r perl (it is strawberry perl 5.24 with the gcc swapped out).
Thanks for mentioning that. This was indeed a problem, as I still need to be able to compile slic3r. I then tried it with this MinGW install (tried x86_64-win32-seh and x86_64-posix-seh. But had no luck compiling the CLI only version of slic3r. In case you're interested:
I did find a solution though: It seems that I can use the custom MinGW from Slic3r Perl and the normal installation in parallel. I just have to 'specify' which to use when. Since the normal MinGW is in C:/mingw64 (which is in PATH) I just change that folder to mingw64_1 whenever I want to compile Slic3r and change C:/Strawberry (which has the custom MinGW and is in PATH too) to Strawberry_1 whenever I start gdbgui. So whatever is not needed will not be available via PATH. This really isn't very elegant but doesn't take too much time and I'll take it for now.
The initial goal I specified in this thread has been accomplished. At first I was using the 3mf specific part_number that is already read from 3mf source files and parsed that as a materialID. This ID is then used to determining the color of each polygon in SVG Slicing (via Window -> DLP Projector -> Export SVG). Even more so, my fork is now utilizing the "Extruder" setting of each volume for this so the user can set it from the Object Settings window.
By the way, when my project is finished I am more than happy to discuss which parts might be of value to Slic3r and what I'd have to possibly change in order to make it more useful and fitting with the general programming guidelines that should be followed. I would love to contribute something!
Until then, there is another change I'd like to implement: It would be great if the produced SVG is not sized according to the bounding box of all ModelObjects, but instead takes the bed shape as size.
So this would be the const Sizef3 size
parameter in SLAPrint::write_svg
.
The bed_shape ConfigOption is contained in PrintConfigDef
(as well as class PrintConfig : public GCodeConfig
).
What I am not quite sure of is whether SLAPrintConfig already holds the bed_shape ConfigOption (because it extends SaticPrintConfig). Checking via this->config.has("bed_shape")
in SLAPrint::write_svg
returns false. Is there another way to directly grab this parameter from the PrintConfig?
Alternatively, a bed_shape configoption (or bed_size for that matter) would have to be added to the SLAPrintConfig and specified in the constructor in SLAPrintOptions.pm, right? So after having added ConfigOptionPoints bed_shape;
to SLAPrintConfig, how exactly do I grab bed_shape from PrintConfig in SLAPrintOptions.pm?
Here is the start of SLAPrintOptions.pm. I added that last line. Would this be the right way and if so, can somebody complete the last call for me?
sub new {
my ($class, $parent) = @_;
my $self = $class->SUPER::new($parent, -1, "SLA/DLP Print", wxDefaultPosition, wxDefaultSize);
$self->config(Slic3r::Config::SLAPrint->new);
$self->config->apply_dynamic(wxTheApp->{mainframe}->{plater}->config);
# Set some defaults
$self->config->set('infill_extrusion_width', 0.5) if $self->config->infill_extrusion_width == 0;
$self->config->set('support_material_extrusion_width', 1) if $self->config->support_material_extrusion_width == 0;
$self->config->set('perimeter_extrusion_width', 1) if $self->config->perimeter_extrusion_width == 0;
$self->config->set('bed_shape', <???>);
I thought I'd ask this here because it might be very easy for somebody who is more familiar with the config structure and perl.
I somehow got it to work :) I would say this can be closed now...
Version
1.2.9-1272-gdc9d7ed7
Operating system type + version
Windows 10 Pro
Description
For my bachelor thesis which involves multi-material slicing for Inkjet 3D Printing it would be great to have different objects within one .3mf file to be sliced to a multicolor SVG. Each color in the SVG should represent one of the objects. Right now, Slic3r produces SVG layers that show all objects in white.
Example with two objects (click)
I am more than happy to do the work myself. I also want to have a go at fixing bug 4283. But even after spending days reading and trying different things, as well as consulting a friend who is majoring in Computer Science, I'm still having issues getting started developing on slic3r.
What works so far:
My issues
These are somewhat separate but I didn't want to flood this forum with too many posts. Since they are all just ways to get to the same goal , finding a solution for one of them would effectively make the others void.
[solved] First off, when I change the text of the SVG header in SLAPrint.cpp, compile from source and do
slic3r.pl torus.stl --export-svg
it doesn't actually change the header of the produced svg file to what I specified. In the source file I added "Test1 SLAPrint - n4rki" in the first line of the header but it somehow doesn't show up in the svg file. The header text is also found in SVG.cpp (twice), so just to be sure I changed it there too. But no difference. Here's my code: SLAPrint + SVG code.zip Why are these changes not showing up in the svg files after compiling? --> found solution: I falsely assumed that perl only encompasses the GUI. I therefore didn't look thoroughly enough and missed print.pm, which draws the SVG in normal mode. Only when compiling and running CLI only mode without perl, this happens in SLAPrint.cpp. Must be due to the ongoing porting process.[solved] Even if the above worked, it would still be a rather inefficient way to program. Since I don't need to work on the GUI for now, I thought working with the CLI only Version might be easier. I managed to compile it with cmake, but it doesn't seem to work:
slic3r.exe donut.stl
returns "error: command not supported"slic3r.exe donut.stl --export-svg
crashes after a while and returns:The instructions on here describe that it works in a limited way, but there are no details on what should and shouldn't work. --> found solution: In CLI only mode there seems to be no default config. So one must at least provide a layer height.
slic3r.exe donut.stl --export-svg --layer-height 0.2
worked just fine.Building with Visual Studio 2013: The 2013 Version is hard to come by
and the download for the perl module patches is offline. Is this way still recommended? Anybody here who uses it or has experience with later VS Versions?How do YOU develop for slic3r? Is there a good way to do it on Windows and be able to debug etc. or should I just stop messing around, use Linux and get aquainted with Emacs + GDB?
As you can see I am a rookie at this - sorry for asking such basic questions! I'd really like to get started with this and I'm facing major roadblocks. Any help is much appreciated!