Slicer Behaviour - RRF RC3

[Garfield]

When using Prusa slicer the magnetic filament monitor isn't getting utilised properly and you see this in the dash / status window - note it thinks the layer height is 1mm - it is actually 0.15 and it thinks that the part height is 40.85 (it isn't it is 10.6mm)

The filament sensor is functional and works fine if I slice with Simplify3D.

What should I be looking for in the Prusa produced Gcode ?

It looks like the job height is coming from the last Z move - which is incorrect since the last Z move on Prusa generated Gcode is moving the extruder out of the way.

I cannot find anywhere that has a layer height of 1mm (I'd be surprised if I could).

G1 Z40.85 ; Move print head up
G1 X0 Y0 F3000 ; Move extruder out of way
; filament used [mm] = 5474.4
; filament used [cm3] = 13.2
; filament used [g] = 16.7

[Phaedrux]

Try changing this in the slicer end code

G1 Z40.85 ; E Move print head up

I think that should prevent the DWC scan from confusing that move as a Z height.

Alternateively, you can move the entire slicer end gcode into a macro called stop.g and then in the slicer end gcode just use M0. M0 will call stop.g at the end of the print and perform whatever you have in the stop.g macro. This allows you to have the end gcode in one place, and the slicer just has M0. It also keeps the DWC from scanning the end gcode as part of the print moves.

[Garfield]

That part is in the Prusa conditional GCode - I shall create a profile without it (I still run a MK3S and have no plans to stop doing so),

Any ideas on the 1mm layer ?

[Phaedrux]

@Garfield said in Slicer Behaviour - RRF RC3:

That part is in the Prusa conditional GCode - I shall create a profile without it (I still run a MK3S and have no plans to stop doing so),

Any ideas on the 1mm layer ?

The 1mm layer is probably part and parcel

[Garfield]

Fixes the height - the layer height remains broken ...

[Phaedrux]

What do you have in the start gcode?

[Garfield]

@Phaedrux

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

[dc42]

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.

[Garfield]

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

Mark Rod.gcode

Mark Rod S3D.gcode

[dc42]

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?

[Garfield]

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.

[Garfield]

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.

[dc42]

Are you running Duet 3 with SBC? If so then it may be a DSF issue.

[Garfield]

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)

[dc42]

Thanks, I'll ask @chrishamm to look into this.

[Garfield]

@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.

[Garfield]

A screen from Simplify ... working fine

[chrishamm]

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.