Slicer Behaviour - RRF RC3

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