@Notepad Any luck in understanding this issue any better?
I basically gave up printing over this , and not just bulging corners but start/end of layer issues. And without specific notes to confirm....prior to 3.x I have beautiful prints on the same printer!
One repeated theme throughout this thread is 0.6mm nozzle with Volcano (and Hemera). This too is my setup (well was since I gave up).

It also seems PA is missing a fundamental understanding considering Vol is a ^3 function and PA has been reported as a linear response function....but since the formulas have not been posted I could be wrong here.

Jerk will always compete with PA for material flow since Jerk reduces residence time but not flow at intersecting travel events, while PA having no knowledge of reduced time intersections event, compensates for excess flow at longer residence (during decel) times and increased flow and shorter residence (during accel) times. It would be really nice if the math were shared and some sort of temporal plot created whereby using the math alone, the zones of goodness could be determined vs wasting so much plastic to try and test this. It sure seems like a mm3/mm travel could be the output and the goal is to show where variation is minimized for various combinations. Every printer is different, but the math is the math and a perfect model should be the starting point. Fudge factors such as bowden tubes stiffness factors deviates from the perfect model, whereas a direct drive might be closest to the perfect model (choose your perfect model).

I finally closed up shop when I had holes, blobs and or bulging corners but never acceptable at all three locations that I could fix. In short I wasted too much time and plastic and finally gave up and stop by here occasionally to see if there has been any new insight.

There has to be a smarter way!

Config file with M906 to and M913

M913 Output

Could it be that there is any reason to believe that the M913 output is incorrect? My x& y motors are running pretty cool even though the output shows 100%.

@Notepad Any luck in understanding this issue any better?
I basically gave up printing over this , and not just bulging corners but start/end of layer issues. And without specific notes to confirm....prior to 3.x I have beautiful prints on the same printer!
One repeated theme throughout this thread is 0.6mm nozzle with Volcano (and Hemera). This too is my setup (well was since I gave up).

It also seems PA is missing a fundamental understanding considering Vol is a ^3 function and PA has been reported as a linear response function....but since the formulas have not been posted I could be wrong here.

Jerk will always compete with PA for material flow since Jerk reduces residence time but not flow at intersecting travel events, while PA having no knowledge of reduced time intersections event, compensates for excess flow at longer residence (during decel) times and increased flow and shorter residence (during accel) times. It would be really nice if the math were shared and some sort of temporal plot created whereby using the math alone, the zones of goodness could be determined vs wasting so much plastic to try and test this. It sure seems like a mm3/mm travel could be the output and the goal is to show where variation is minimized for various combinations. Every printer is different, but the math is the math and a perfect model should be the starting point. Fudge factors such as bowden tubes stiffness factors deviates from the perfect model, whereas a direct drive might be closest to the perfect model (choose your perfect model).

I finally closed up shop when I had holes, blobs and or bulging corners but never acceptable at all three locations that I could fix. In short I wasted too much time and plastic and finally gave up and stop by here occasionally to see if there has been any new insight.

There has to be a smarter way!

@phaedrux You are brilliant. This indeed was the issue.
Thank you!

No luck finding the Solved button - please tag this as so.

Also not sure if anybody noticed, "upload" without a file name deletes files...could be noted as a bug.

@siam try 20% slower out wall, then try outer before inner. Sometimes infill does funny things when % fill artifacts show up, try no infill.
Which slicer?

@mikeabuilder Quickly check with great hope that there is a Start.g file ...and no such luck, no start file.
I have homed by ALL, by axis and by individual G28 and G30 verification...all perform normally. Z=0 in all case both actual and display.
I suppose I could try a different Z starting point prior to each of these executions...I'll report back. But as I mentioned, I removed all slicer based start codes (blank field) and even tried a lone G90 Absolute Coord in the Slicer start code. This should have forced the axis to use the previously verified Axis conditions. What happens is the DWC reports first layer height @ Z=0.3 from the existing Z height. It appears that a G92 is getting inserted before the print starts.

Is there a debug mode to see all streaming executions? That would be the most helpful right now.

@owend
Issue occurs on all print files. Here is more of the same gcode from above. I just noticed I did not include the first layer (duh).
FLAVOR:RepRap
;TIME:2401
;Filament used: 3.806m
;Layer height: 0.45
;MINX:126.636
;MINY:144.069
;MINZ:0.3
;MAXX:183.364
;MAXY:165.931
;MAXZ:58.8
;Generated with Cura_SteamEngine 4.8.0
T0
M140 S65
M104 S245
M109 S245
M82 ;absolute extrusion mode
G28 ; home

M83 ;relative extrusion mode
G1 F2100 E-0.85
;LAYER_COUNT:131
;LAYER:0
M107
G1 F1800 Z0.6
G0 F4800 X128.489 Y145.729 Z0.6
;TYPE:SKIRT
G1 F1800 Z0.3
G1 F2100 E0.89064
G1 F1800 X129.014 Y145.295 E0.05604
G1 X129.587 Y144.925 E0.05611
G1 X130.199 Y144.625 E0.05607
G1 X130.674 Y144.449 E0.04167
G1 X130.992 Y144.347 E0.02747
G1 X131.652 Y144.177 E0.05607
G1 X132.328 Y144.086 E0.05611
......finish layer 1
;MESH:NONMESH
G0 F1800 X174.765 Y152.667 Z0.75

@mikeabuilder
Thanks for the comments.
Home All, HomeZ & commands of G28 and G30 (all for good measure) result in bed being properly homed and at correct height physically and reported. I can confirm 0mm is 0m at the bed and display. The BL repeatability is 0.02mm on repeat probing.
It is only when I invoke a print job that the problem appears. The DWC will state first layer height, e.g., 0.3mm, but will be at whatever height the Z axis was at when print was initiated.
In the start code, I have tested blank, w G28, no G28 (printer is homed), added extraG90, added Mesh or removed it...basically all options. The end result is the same whereby Z axis starts print and current Z height.
Again this can be manipulated. For example, I can home axis, change Z to 20mm (or anything) and start print job. The DWC will say report first layer height @ 0.3mm but is now physically @ 20.3mm. Hope that makes sense?

I hope this is a very simple problem, but has baffled me for over a month. Using Duet V3.3 , Wifi 1.6 and DWC 3.30 and Cura 4.8.0.
Here is the problem statement, when starting a print, the z axis begins printing at whatever Z state the printer is at + first layer height and I cannot figure out why. It is as if the axis gets a G92 for Z after homing because the new Z value is at the print first layer height, but it is off the bed by Z after homing. I can manually add more Z and print again, and it will start at that new Z +first layer height. Mesh is confirmed invoked.

Homing of all axis are very robust. Confirming with command line M28, G30, or stepping to Z=0 and consistently confirms Z=0.
I then tried putting G90 in the start code to make sure an errant G91 was floating around and finally gave up. Please help me figure this out.
Also here is a snapshot of the G code.
;Generated with Cura_SteamEngine 4.8.0
T0
M140 S65
M104 S245
M109 S245
M82 ;absolute extrusion mode
G28 ; home
;G29 S1 ;Load Mesh
G90 ; Absolute Positioning
G1 E1 F300 ;Extrude 1mm
M83 ;relative extrusion mode
G1 F2100 E-0.85
;LAYER_COUNT:121
;LAYER:0
M107
G1 F1800 Z0.6
G0 F4800 X105.874 Y105.579 Z0.6
;TYPE:SKIRT

BTW - the forum posting guide says to use "Up Arrow" to upload file..Forum does not have this feature. I was looking to get copies of my files to share here and wondered if there was a neat feature option to group files from DWC and poked atthat, but saw no path. I intended to hit "cancel", but hit "open" instead without any filename (empty) and poof, my config.g file has vaporized. I searched high and low for any file created in the last 24 hours. This is kind of a cruddy software bug. My Config.backup is shared here, but is a few days old...not sure what state that was in. homez.g homeall.g heightmap.csv bed.g config (2).g

@janjoh I would guess the corner mount like will have it's own artifacts. It may or may not matter, but looks like a spring board and will certainly have a dominant frequency related to the mounting alone. Simply test on a nice solid block of Al or something by mounting in the same fashion and give it a few taps in x, y, z directions and see what you get.

It seems many have had recent trouble getting the latest shipped Wyze V2 variant to allow any mods to work, but it still can be done. The key is that the expected documented Dafang Hack response or even native Firmware updates are different than previously reported.
Upon loading the initial demo.bin boot loader file, the camera seems to lock up with blinking yellow light and never seems to properly finish the firmware upload. The same is true when subsequently adding the Hack Mod directory as the camera basically seemed to no longer load firmware. However after several hours of random SD card write protect events and fiddling at other load sequences attempts and downgrading, etc., I noticed that my router had already connected the camera many hours before. I then simply had to login with ID and PW via Firefox at a new Tab URl and the cam is now able and present anytime I launch DWC Cam tab.
Pretty happy overall and glad to get rid of handicapped Android phone approach.