Duet2 CPU struggling to keep up with this gcode?

deckingman

@edgars-batna I still don't get it. Your 1/10 resolution gcode file is still mostly made up of segment lengths that are 0.05mm and even less. Why? What's the point? If you want that fine a detail, you should be using something like a sub 0.1mm nozzle and filament that is maybe 0.5m diameter (and either bloody good eyes or a magnifying glass to see it).

Edgars Batna

@deckingman It's not about resolution but narrowing down on the problem. As soon as the Duet runs out of breath strange things happen. Those crazy files just exaggerate the problem to demonstrate it. The problem occurs even on a completely normal file like this: 0_1564172383619_PA tiny segment test EccentricGearTest.gcode

The average distance in the "fine" file is 0.1. At least that's what I've programmed the interpolation to do. I can change this to any value actually.

bot

Well, there is indeed a reason to use detailed gcode: to get detailed prints. A tiny flick of the nozzle goes a long way in dispensing plastic where it needs to be or avoiding areas it doesn't.

That said, I also feed insanely detailed gcode into the duet and experience no such issues.

I didn't study your settings or look at your gcode, but you must be asking the printer to do something that is physically unreasonable for it to do. Pressure advance asks your extruder to do some pretty funky things, if you let it.

Edgars Batna

@bot I'm definitely not asking anything impossible from my printer. If anything, I'm disappointed to run into such issues in 2019 or even using "8bit" and the year in teh same sentence... heh... Duet is, after all, not cheap.

bot

@edgars-batna You are likely "asking" your extruder to move faster than is physically possible for it to do while gripping filament. Intentional or not.

I'm pretty sure I also have segment lengths in the nanometer range, but I don't see a problem. Again, I haven't studied your settings so I'm just saying take a look at everything, and dial some things WAY back, slow it down, and see when you can get it to work nicely... that'll be your max-capability, no?

Phaedrux

Can you describe your extruders? They look like 2 nema23s with planetary gearboxes running in tandem.

deckingman

@bot @Phaedrux Have you tried running his gcode file like I have?
I get the same bad behaviour but have never experienced anything like that with anything I've ever printed, including "real world" printing at 300 mm/sec using 5 extruders.
That's why I believe the problem lies with the file.
Strongly advise that you try printing his file, before looking elsewhere for the cause.

Edgars Batna

@bot said in Duet2 CPU struggling to keep up with this gcode?:

@edgars-batna You are likely "asking" your extruder to move faster than is physically possible for it to do while gripping filament. Intentional or not.

Have you looked at the videos? There is no filament inserted. I've spent so much time on this, all the while changing extruders, hotend, PTFE tubes, motors, configuration that I'm 99.9999999% sure it's not my printer.

@phaedrux said in Duet2 CPU struggling to keep up with this gcode?:

Can you describe your extruders? They look like 2 nema23s with planetary gearboxes running in tandem.

It doesn't matter how I connect them or what microstepping I use, it's consistently reproducible with the files provided. Frankly, if I increase microstepping then the whole thing runs way too slow (which is a bummer, that's why I think we should have been done using slow CPUs for CNC machines). Currently I've got 2x 2A Nema17 with 5:1 gears, but, as I said, I've tried it all already. No combination fixes the problem. It's partly documented in other threads.

Phaedrux

@edgars-batna said in Duet2 CPU struggling to keep up with this gcode?:

it's consistently reproducible with the files provided.

Garbage in garbage out?

Do you have any actual gcode files produced by a common slicer that exhibits this to test?

I just printed your gcode file described as "completely normal" 0_1564172383619_PA tiny segment test EccentricGearTest.gcode

It sets acceleration to 10000 and then starts hammering.

Here ya go: https://www.dropbox.com/s/y6jict6tpgdfvxr/IMG_6027.mp4?dl=0

I added my start and end gcode so it would actually print. The acceleration and print speeds are pretty insane for such a part, but it didn't stutter at all.0_1564268355944_config.g

I think your print settings are unusual to say the least?

Edgars Batna

@phaedrux Thanks for trying it out. By no means it's all garbage. Have you looked at the other thread, linked in the beginning? It fails at completely normal prints and so far all indicates that this is the culprit with PA enabled, which gets even worse with higher PA values.

The "PA test" macros are from 2nd layer onwards. Could you remove filament, set PA to 0.6 and run the "PA tiny segment test EccentricGearTest" file? The extruders should start acting up. I just ran the same with 0.035 PA (as per your config) and they still acted weird at certain points but not as much because there are no sharp turns in this gcode.

Here's the actual printable gcode: 0_1564303068509_EccentricGearTest 0 0 volumetric.gcode. It does print, but there the PA is only slightly shy of skipping steps. With slightly higher move count the PA commands the extruders to skip because the Duet can't keep up. The extreme demonstration is contained within the "fine" and "superfine" macros.

Here's the "fine" macro with E: 0_1564304231040_EccentricGearMacroProcessedFine.gcode
Here's the "superfine" macro with E:
0_1564304239370_EccentricGearMacroProcessedSuperfine.gcode
WARNING: remove filament before trying
IMPORTANT: enable PA and try different low and high values when trying

The macros are for quick reproduction and are not printable. By "normal" I referred to the remarks by other users regarding the segment count and resolution.

EDIT #342354: Had to resort to contacting Akismet so that they stop blocking my edits...