Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Ways to print with 3rd Party Slicer
Just wanted to summarize two ways I have been exploring printing without the XYZ Software:

1) Slic3r > Add Header > Base64 encode
Use Slic3r to prepare the Gcode File.
It is important to setup the Custom Gcode Section to include :

Start G-Code:
; filename = composition.3w
; filename = composition.3w
; machine = daVinciF10
; material = abs
; layer_height = 0.2
; total_layers = 24
; total_filament = 181.38
; extruder = 1
G21 ; set units to millimeters
;M104 S200 ; set temperature
;M109 S200 ; wait for temperature to be reached
G90 ; use absolute coordinates
G92 E0
M82 ; use absolute distances for extrusion

End G-Code:
M84     ; Disable motors

You can not have any other special GCODES in your file or XYZWare will not import it.

Then put this whole GCODE file through a base64 encoder.
You can use mine here or any other you can find on the web.

Save this content to a file and change the extension to ".3w".
After that this GCODE can be imported into XYZWare and sent to the printer.

2) Print straight via USB
I have written a MAC OSX application which will directly communicate to the printer via the serial port.
It does work for a demo file. However, the XYZWare is calculating a CRC16 checksum over the data.
As with every checksum algorithm its pretty hard to reverse engineer what checksum was used.
So while I can print a capture of the original communication with no problems, I have issues generating the correct Checksum over my other GCODE files. I unfortunately don't have the time to fiddle with this for a long time, but I attached the sample capture below.
If you open it with a HEX editor, you will see the GCODE followed by 0x0000 and then the 16 Bit checksum of 0xCCC5.

If anybody figures out the logic behind how that checksum was built, I am happy to release that OSX app on the Apple App Store for everybody to use.

best regards,

it is almost impossible to determine the poynomial from only a single example. In addition, the computed crc could have something stupid added to it, like 0x0001 of 0x1234 etc.

In short, without analyzing the code generating the crc its difficult to know what they did. Ive looked at this for a little bit, and frankly Im not convinced generating the crc will be easy. Hope I am wrong.

I assume XYZware spit out the crc?

Yes Kieth, XYZWare sends the ascii GCODE followed by 0x0000 and then the 16 Bit CRC.

And I agree, it will be hard to find out the algo. It's not even clear what part of the data is CRC'ed.
The printer doesnt look for a CRC with my wifi hack. Smile

Oliver - Can you try to extract a few other simple dumps? Im no longer convinced this is a crc16. It is looking like it might be a crc32.

Here is the last bit from one of my usb dumps.

64 69 73 61 62 6c 65 20 6d 6f 74 6f 72 73 0d 0a 0d 0a 01 0d 0a 11
"disable motors

(hidden characters)

Hm. your dump below ends with CR-LF and then just a single 0x11 byte. Is there something missing ?
What I saw was 0d(CR) 0a(LF) 0x00 0x00 0xcc 0xc5 - I assume the checksum.

If you have the wrong number there the printer replies with "Checksum incorrect".
It being a CRC 16 was just a wild guess. I would use it, as a CRC32 would put a much heavier burden on the printer MCU.
01 0d 0a 11 is what I am assuming to be the checksum.

0d 0a 0d 0a seems to be placed at the end of every file sent, before the checksum, as it was in yours.

I could be wrong, but I didnt see additional transfer packets sent ffrom xyz>printer after the above but before the printer started printing.

Also, playing the entire [email protected]:4, mytest info, followed by the file I see the printer responds with "Offline NO" at the end. It does not start building. Ideas??

I've been independently working on a Python program to send GCode files to the DaVinci. I'm primarily a Linux user, and having to boot into Windows every time I want to print is a bit of a pain.

I almost have the uploader working. The latest breakthrough happened at 5AM last night... but it still doesn't quite work yet, so I need to figure out a little more.
Here's what I've figured out.

It's a serial connection: 115200, 8N1, software flow control.

The command set is [email protected]:#, where # is either blank or a number 3-8.
MACHINE_INFO = '[email protected]:'

XYZWare sends GCode files in chunks of 10236 bytes. There's a 4-byte checksum at the end, which corresponds to the integer value of all the ASCII characters in the chunk added up.

There's a "pre-header" that's sent before the GCode file is uploaded... it does send the file size to the printer.

The last thing I need to figure out is the EOF that the printer is expecting... currently, it resets after some short fixed time (I'm not sure how long yet,
Make sure you don't have blank lines in your gcode. Blank lines reboot the printer. A simple Slic3r post-processing script like this one is all that you need:

/usr/bin/sed -i.bak '/^$/d' $*

As for the header I didn't try that part yet. But looking into FW disassembly I can see that the FW parses out these vars: filename, material, layer_height, total_layers, total_filament, extruder. My guess would be that it needs total_layers or total_filament or both to display the progress information.

The CRC algorithm is easy to obtain from the XYZ Windows app. It's a .NET application so a tool like Reflector decompiles it into nice C# source code.
The Mac XYZ app I am using has no problems loading and printing unencrypted gcode files.
Ran one more trace tonight and figured out what was causing the issue. I've uploaded working code to github! :woohoo: Feel free to try it out.

I forgot that the GCode file needs DOS line-endings (CRLF) to work properly (I actually made a note of this a while back, but didn't re-read my notes). Since I was under Linux, the file just had linefeeds. Ran the GCode file through unix2dos and voila! I was able to print!

Couple of caveats: As bgm pointed out, it does parse the header in the file. I noticed that my test Slic3r files would not display progress information while printing. So I need to figure out how to get Slic3r to put the appropriate header info in the GCode, or add it in later while doing the upload.

The GCode file is hard-coded for now in the python program; change the appropriate variable to whatever file you want to print.

Not all the checks are performed... there's at least once that I blindly go through.

Line-Endings aren't checked either... need to implement code to do that.

But I've successfully printed two objects from Thingiverse sliced in Slic3r, and uploaded with my python program without touching Windows or Mac... so I'm a happy camper!
You don't need CR-LFs, I printed with LFs only just fine as long as there are no blank lines. Otherwise firmware crashes with a "!!!! HardFault_Handler !!!" message. You can see it if you attach onboard serial port to your computer. It's a 4 PIN connector in lower right corner of the PCB. The leftmost PIN is TX, next one I don't know, next one is GROUND. It's a 3.3v port, don't overpower it.
It doesn't seem to react to any input as far as I can tell. The output is of limited use to, only a handful of debug messages is displayed from time to time.

Also you can use 230400 instead of 115200 to upload the files to the printer. That's what they use in Mac XYZ app.
Seems like the total_filament var is all that's needed for the correct progress reporting. This is my current Slic3r postprocessing script. I am using Slic3r 1.1.2, didn't try it with 1.0.1.
/usr/bin/sed -ne 's/filament used = \(.*\)mm.*/total_filament = \1/p' "$*" > "$*".new
/usr/bin/sed  '/^$/d' $* >> "$*".new
/bin/mv -f "$*".new "$*"
To Make it a bit easier to create .3w files, windows users can use Notepad++.

Remove blank lines by:
Plugins - TextFX - TextFX Edit - Delete Blank Lines

Convert files by:
Plugins - MIME Tools - Base64 encode

Save as - "filename".3w

Note: Depending on the version of Notepad++ you have, you may need to install one or all of these plugins.
You can get these and more Plugins here:
(Including a hex-editor plugin)

I've created a simple guide (with pictures) to detail the process of using Slic3r with our printer. It's pretty much a dummies' guide, which is great for people who don't have the energy to hunt through threads like I've been doing. The guide is here.
Want to simply edit an INI file to change the slicer settings?

Okay, ready? Set! GO!

1) Install latest XYZware version. There are layer height bugs with earlier versions.

2) Copy the following and save it as RDtest.ini

---begin copy---
abs_position_x = 0
abs_position_y = 0
avoid_crossing_perimeters = 0
base64 = 0
bed_size = 200,200
bed_temperature = 0
bottom_solid_layers = 3
bridge_acceleration = 0
bridge_fan_speed = 100
bridge_flow_ratio = 1
bridge_speed = 30
brim_width = 0
complete_objects = 0
cooling = 1
cooling_speed = 20
default_acceleration = 0
disable_fan_first_layers = 1
duplicate = 1
duplicate_distance = 6
duplicate_grid = 1,1
end_gcode = M84 ; disable motors
external_perimeter_speed = 70%
external_perimeters_first = 0
extra_perimeters = 1
extruder_clearance_height = 20
extruder_clearance_radius = 20
extruder_offset = 0x0
extrusion_axis = E
extrusion_multiplier = 1
extrusion_width = 0
fan_always_on = 0
fan_below_layer_time = 60
filament_diameter = 1.75
fill_angle = 45
fill_density = 0.1
fill_pattern = honeycomb
first_layer_bed_temperature = 0
first_layer_extrusion_width = 200%
first_layer_height = 0.35
first_layer_speed = 30%
first_layer_temperature = 200
g0 = 0
gap_fill_speed = 20
gcode_arcs = 0
gcode_comments = 0
gcode_flavor = reprap
infill_acceleration = 0
infill_every_layers = 1
infill_extruder = 1
infill_extrusion_width = 0
infill_first = 0
infill_only_where_needed = 0
infill_speed = 60
layer_gcode =
layer_height = 0.4
machine =
material = default
materialid =
max_fan_speed = 100
min_fan_speed = 35
min_print_speed = 10
min_skirt_length = 0
notes =
nozzle_diameter = 0.4
only_retract_when_crossing_perimeters = 1
output_filename_format = [input_filename_base].gcode
perimeter_acceleration = 0
perimeter_extruder = 1
perimeter_extrusion_width = 0
perimeter_speed = 30
perimeters = 3
post_process =
print_center = 100,100
raft_layers = 0
randomize_start = 0
resolution = 0
retract_before_travel = 2
retract_layer_change = 1
retract_length = 1
retract_length_toolchange = 6
retract_lift = 0
retract_restart_extra = 0
retract_restart_extra_toolchange = 0
retract_speed = 30
rotate = 0
scale = 1
skirt_distance = 0
skirt_height = 1
skirts = 1
slowdown_below_layer_time = 30
small_perimeter_speed = 50%
solid_fill_pattern = rectilinear
solid_infill_below_area = 15
solid_infill_every_layers = 0
solid_infill_extrusion_width = 0
solid_infill_speed = 30
spiral_vase = 0
start_gcode =
support_material = 0
support_material_angle = 45
support_material_enforce_layers = 0
support_material_extruder = 1
support_material_extrusion_width = 0
support_material_interface_layers = 0
support_material_interface_spacing = 0
support_material_pattern = rectilinear
support_material_spacing = 2.5
support_material_speed = 60
support_material_threshold = 45
temperature = 200
threads = 2
toolchange_gcode =
top_infill_extrusion_width = 0
top_solid_infill_speed = 30
top_solid_layers = 3
travel_speed = 45
use_relative_e_distances = 0
vibration_limit = 0
wipe = 0
z_offset = 0
---end copy---

(DO NOT copy the "---begin copy--- ---end copy---")

3) Save the RDtest.ini file to C:\Users\[LoginUser]\AppData\Roaming\Temp

4) If it works 'Voila! (( havent 100% tested this.)

5) If it works, Convince someone to write a front end to edit the file easily. ;-)

6) As always, Enjoy!

Thanks for all the good info guys!

I still can't get any gcode I make with Slic3r to load into xyzware. I grabbed a gcode example from and used the Base64 encode tool. That file will work in xyzware. If I put my own STL into Slic3r export as gcode and them encode it the files do not work. Can somebody explain what each line in the start of the file does. I notice in the example lines like total_layers and total_filament have values, should those be different for different models?

I tried pasting the code Oliver listed at the start of this thread into slic3r, but that resulted in a bunch of duplicate lines, and a non-working file.

Please help, thanks

Scott, you might consider the wifi firmware hack or another alternative (sd card, or sd cable extension) to load your files directly to the printer.

The .3w file must have the correct header info to be imported into xyzware. So, most likely, even if your base64 conversion is correct, you may not have added the header to the gcode file before you base64.

Edit: The head is all the lines preceeded by ";" - best I can tell they are ignored by the printer but XYZ looks for them.

Yes, I need the correct header, I guess it was not clear enough in my first post. I have tried a bunch of different headers and none work.

in the example lines like

; total_layers
; total_filament

have values, should those be different for different models?

Using Olivers header and others have not worked but I used an example unchanged, ran it in the Base64 encoder and it does work. How do I get the right header for my file? I do not think one header works for any file, I bet you need the right total layers number?

Does anybody know? I do not want to cut the side of the printer to get to the SD card TY.

No need to cut the side. Thats hwy I mentioned the extension cable. Or wifi hack.

How about posting one of your created files and I will look at it to see whats wrong?

Also, what version of firmware and xyz ware are ou using?

Ok here is the first 28 line of gcode, of 45355 lines. Using notpad++ to edit. Tried notpad++ and Olivers base64 converter, they make the same code as far as I have checked. I tried to follow Olivers example as closely as I could, removed duplicate lines and blank lines. I'm a little puzzled why the set temp lines are commented out, but just following the example, I have tried it with the ; removed too but that does not seem to fix it. Thanks!

; filename = composition.3w
; machine = daVinciF10
; material = abs
; layer_height = 0.2
; total_layers = 24
; total_filament = 181.38
; extruder = 1
G21 ; set units to millimeters
M190 S105 ; wait for bed temperature to be reached
G28 ; home all axes
G1 Z5 F5000 ; lift nozzle
;M104 S200 ; set temperature
;M109 S200 ; wait for temperature to be reached
G92 E0
M82 ; use absolute distances for extrusion
G90 ; use absolute coordinates
G1 F1800.000
G1 Z0.350 F3600.000
G1 X77.408 Y79.206 F3600.000
G1 X79.228 Y77.456 F630.000
G1 X79.738 Y77.006
G1 X81.718 Y75.456
G1 X82.278 Y75.066
G1 X84.408 Y73.726
G1 X84.988 Y73.396
G1 X87.248 Y72.276
G1 X87.868 Y72.016

Forum Jump:

Users browsing this thread: 1 Guest(s)