Simple guide to getting Slic3r to work with the DaVinci (Page 1 of 2)

It's simple enough to script. I've got an OS-X binary that does the conversion automatically (attached), though I've only tested it on 64-bit 10.9. I expect to have a web service that will include a base64 encode option sometime in the next week, so this is still pretty crude.

You need to have your a slic3r config similar to the one from Jason at github.com/jasongao/DaVinci1.0/. Export the gcode from slic3r. Then run xyzify from the command line. It reads the slic3r gcode file from standard input, and writes the result to standard output. It's not base64 encoded, but the mac version of XYZWare doesn't care (which is why no windows binary).  You can then import the resulting gcode file in XYZWare and print from it.

Thanks guys for all the effort and info. I am on my way to attempt my first slic3r generated print as the part is too complex  for XYZware to generate the toolparths.

Could anyone please also post the starting gcode here that is in the manual so I can copy and paste both the starting gcode and ending gcode into Notepadd++? I don't plan on opening up my Da Vinci to get to the SD card (yet) so I have no access to previously generated gcode from the XYZware to get it myself.

Haha! w34's XYZ ware works as easily as advertized! I coudn't get my modified gcode to convert. Notepad++. It kept on freezing. So this is a saving! I thanked w34 on voltivo!

Edit:... except that is does not send the gcode though to the printer...or save as a .3w either.

Hey, W34.  I'm using your modified version on firmware I with no problem.  Drag the Gcode file over into the XYZ window, send to printer, no problem.  When I click save, it saves as a .3w file.  It sends the gcode file to the machine as offlineprint.gcode (or whatever the default name is--the printer's printing right now so I can't look).  In any case, I've had no problem using it at all and I'm extremely grateful.  It's actually made me question whether I want to do the firmware swap or just the filament resetter.

I noticed BTW that XYZware comments out the temperature lines when it slices the part.  It still puts it in the gcode, it just comments the line out.  I'm assuming since XYZ expects the cartridge to completely control the temperature.  In any case, adjusted temperature lines import over with the Slic3r gcode just fine and XYZ leaves them alone.

I haven't seen that XYZware version posted yet!  I want it-LOL.  I mainly wish I could just see the options that XYZware is using (like in your Slic3r pic).

Are people still having problems with the cartridge resetter?   I saw something about with firmware I the SN has to be changed or something.

@Ovrclck350: From what i've read 1.1.l firmware stores filament eeprom serial and usage to printer for comparison. I think I may have had the issue as well to verify that it does and you will have gaps in your print as their protection method. Reason why I have have stuck with G.

@Tryversol: I will upload the next iteration when I finish with it. I will leave the full option in, but have a option to show/hide it in the menu.

Yes, the default values will be whatever settings XYZWare defaults to so you will be able to see what values they use. You will be able to change the values and save as a new profile and then select which one profile you wish to use.

When I get home from work I will take a look at the XYZWare default values and post them up for you for the time being so you can compare the values to your slicer values.

The version I made a few days ago (non debug build) does not have 3w any longer for the export option (save option still works the same). It can import 3w, but when you export, it will only export gcode. I can upload this version later today for you if you would like.

Here you go
http://www.mediafire.com/download/rv680 … /XYZv2.zip

Edit: oh forgot to mention. When it is exporting, take a look at the log window underneath the 3d view. It will show you the settings they use with slic3r.

Hey there,

I'm a first time poster, semi-long time lurker. I've been using w34's modified XYZ.exe for a few days... thank you very much w34!

It's been very helpful to confirm the basic settings used by the internal version of slic3r. However, it's clear that there is still some "secret sauce" being added that I can't seem to identify based on the "recommended settings" for Slic3r.

Based on the samples I've printed it seems to me that there is something not quite right with the extruder feed. See the attached photo. The two samples on the left were sliced with the standalone Slic3r and imported into XYZware. I printed a lot of samples and no combination of feed rates or temperatures resulted in an acceptable print. All of the samples printed through XYZware at various speeds and layer thicknesses came out from good to very good. BTW, the hexagon in the middle of the post is intentional.

Would it be possible to decompile the "out.exe" file that is spawned to see what Slic3r settings are hard coded?

Thanks for all the hard work  to everyone who has helped make this hobbled machine run a little more freely!

Hi w34, My firmware is 1.1.I and the error message "XYZware has stopped working.. windows will notify you when a solution is available."

But it is a "big" complex industrial part I am trying to print. I should know better and rather develop from the bottom up but I'm kind of eager to show the stratasys resellers we can do this without their ridiculous R15 per cc rate that they suddenly came up with, throwing my development of 7 months in the water.

I also saw that there is some support material missing under the duck tale of the part. And I have the Spaceclaim STL prep module that I think would shell the part better. So I'm back on modelling level and I will try your XYZware on a smaller part as well.

But here is the STL and the gcode.. XYZ support US also sent me a generated g-code from the STL part but it had a skirt so even the XYZ support guys couldn't slice the STL with XYZware and used Slic3r or another software to slice this part!

Edit: It looks as if the gcode didn't upload. I guess the 17mb zip is over forum limits. So I can put it in google drive if you want it to test with.

I haven't printed gcode larger than 10mb's, so I haven't run into that issue yet. So I haven't had the need to look at XYZWare's upload procedure yet. Upload it, that way we can take a look and we can see what can be done to optimize/fix/change xyzware's upload procedures for large files.