Slicer Behaviour - RRF RC3
-
What do you have in the start gcode?
-
G21 ; set units to millimeters G28 ; home all axes G90 ; use absolute coordinates M83 ; extruder relative mode M140 S80 ; set bed temp M190 S80 ; wait for bed temp M104 S220 ; set extruder temp M109 S220 ; wait for extruder temp ;BEFORE_LAYER_CHANGE G92 E0.0 ;0.15 G1 Z0.150 F7800.000 ; move to next layer (0) ;AFTER_LAYER_CHANGE ;0.15 G1 E-1.40000 F2400.00000 ; retract G1 Z0.350 F7800.000 ; lift Z G1 X186.054 Y131.823 ; move to first skirt point G1 Z0.150 ; restore layer Z G1 E1.40000 F2400.00000 ; unretract G1 F1200 G1 X186.815 Y130.772 E0.02977 ; skirt
-
Is there a ";layer height = xx" or similar line in the comment lines at the start or end of the file?
If you make the whole GCode file available then I can investigate it.
-
No problem - there is no layer height comment in the Prusa generated Gcode at the beginning of the file, it does appear but it is at the end.
This is the same part sliced in both Prusa and Simplify
-
I've just loaded your file into a machine running RRF 3.01-RC3+ and it's displaying the layer height as 0.15mm in the file list in DWC.
What layer height do you see in your file list?
Which firmware version are you using?
-
RC3
Any ideas where to look ?? - it is currently running - see below - layer times are way off - I'm assuming because each 1mm layer consists of 6 and a bit layers ... the completion percentage seems OK.
-
I can send my entire config if needed - the zipped file is approx 6 meg - does the fact that I'm using RPi 4 have a bearing on this ?
Simplify 3D file is fine (layer height) - didn't allow the print to start.
-
Are you running Duet 3 with SBC? If so then it may be a DSF issue.
-
The SD card that was supplied with the Duet 3 is installed in the Pi, there is no SD card in the Duet itself.
I wouldn't know where to start with the framework - is that code available to read anywhere ? (edit - Found it)
-
Thanks, I'll ask @chrishamm to look into this.
-
@dc42 I've looked at config.json for DSF conf and the strings/regex seem odd - don't know why it would find in one file and not the other though. I'm not familiar with the regex patterns used
layer_height\D\u002B(?\u003Cmm\u003E(\d\u002B\.?\d*))
doesn't look valid - but it seems to work for S3D - why the + character (002b) and whats with the character case forcing \u ??
most likely Just my lack of familiarity with how these are used / parsed beyond the 'regex' context
It isn't the end of the universe and seems to affect only displayed values.
I appreciate the input.
-
A screen from Simplify ... working fine
-
Thanks for the file, I'll fix it in the next DSF version. the \uXXXX codes represent unicode characters, not sure why the JSON serializer thinks it is a good idea to encode them that way.