[3.4.6+SBC] DWC - "Object Height" issue/bug?

Phaedrux

Is it only happening on files larger than 25mb?

oozeBot

@Phaedrux No - our test deck has some very large files that work just fine.. we haven't pinpointed what's causing it, but it appears to have something to do with multiple objects.

OwenD

@oozeBot
I can more or less reliably replicate this, however it seems more related to file size than to the number of instances.
These are mostly all the same parts, just with varying instances to achieve different file sizes.
I also did a couple of large parts with a single instance.
At around 25-29MB, I get a height of zero with the multiple instance files.
This suggests RRF/DWC might stop parsing the file looking for the height after this.
But with the single instance files, it was much higher.
The boxes are the same size with differing infill percentage.

I wonder if your larger files have already been printed or simulated?
Did they have thumbnails?

For reference I'm running
Duet 2 WiFi 2WiFi 3.5.0-rc.2
Duet Web Control DWC 3.5.0-rc.2
Prusa Slicer 2.7.1+

oozeBot

That huge file in the screenshot that is over 500MB was uploaded moments before I took the screenshot - Object Height reads just fine. So it's definitely a head scratcher..

@dc42 - any insight as to what is going on or what RRF uses to calculate Object Height? FYI - our slicer profile already injects the following in the "End G-Code" section as suggested in several other threads.

;NUM_LAYERS [layer_num]

chrishamm

@oozeBot NUM_LAYERS has nothing to do with object height detection and in SBC mode, RRF doesn't parse G-code file info either - that's done by DSF in this case. And DSF looks for the last absolute G0/G1 Z parameter, which is then returned as the object height.

I'd need to see your full end G-code to tell you what's wrong. Maybe you lift Z at the end but don't switch back to absolute mode as in

G91 ; relative mode
G1 Z5 ; lift Z by 5mm
G90 ; absolute mode

oozeBot

@chrishamm

Here is the ending gCode (minus comments) for one of the files which fails to parse Object Height. The routine which runs after the job is complete is encapsulated in the custom mCode M9001.

Perhaps it has to do with M486? I believe that was introduced as a feature in PrusaSlicer 2.7.1?

I can provide a full file if necessary.

G1 X263.999 Y139.759 F12000
G1 F6000
G1 X260.696 Y143.062 E.21742
G1 X260.707 Y142.418 F12000
G1 F6000
G1 X263.354 Y139.77 E.17427
G1 X262.488 Y140.003 F12000
G1 F6000
G1 X260.949 Y141.542 E.1013
M486 S-1
G10 ; retract
M9001
;TYPE:Custom

chrishamm

@oozeBot It might be that your last true G1 Znnn command is too far in the file and DSF just gives up before it is reached - this can happen if your last layer is really long. In that case I suppose you could work-around it by inserting a custom G1 Z{layer_z} code right at the end using PrusaSlicer. That new G1 Z move should then be ignored by RRF but it should be picked up by DSF for the object height detection.

I haven't tested it yet but it should work.

oozeBot

@chrishamm This makes sense and is likely the culprit.. The last layer change on this file is at line 2013568. The last line in the file is 2034064. That's a bit over 20000 lines and I bet it is scanning way less than that.

oozeBot

@chrishamm Placing a G1 Zxx.xx at the very end of the file fixes the issue. While I understand this won't affect the machine's travel, I'm not thrilled with this being the solution.

Perhaps a marker could be added similar to NUM_LAYERS which, when present, would populate the Object Height without further scanning of the file?

oozeBot

@chrishamm - thanks for the nudge on where this is parsed. We were on the fence about building custom versions of DSF (we wanted to keep these stock), but for now, we went ahead and rebuilt for publishing on our package server.

What we did was added a new custom parameter that can be added into the End G-Code section:

;TYPE:Custom
; OBJ_HEIGHT: 24.23

which results in:

chrishamm

@oozeBot Looks good, feel free to send me a PR for this!