Posts made by bot

@r4ffers Did you try this print with different E jerk/accel?

@r4ffers Make sure your slicer start gcode doesn't disable PA. Check every .g file on your SD card, too.

@r4ffers One thing I would try if I were you would be to increase the E jerk a little, and drastically decrease the E acceleration. You never need that much E accel. It becomes completely pointless -- essentially no E acceleration is ever applied because there are not enough steps to interpolate speeds across.

Try E Jerk 500 and E Accel 2500.

@mortarart Sorry, I meant the parts that are attached to the stepper. You have to ensure that the stepper will actually stall, and not just damage everything in its path.

AFAIK this is totally fine and there is zero chance this will damage the electronics. You could reduce current while doing so to make sure no mechanical damage is possible.

DC42 had technical reasons for choosing the placement. There was already concerns that it was not fully contained close enough to the beginning of the file. I think if the thumbnail is at the end the performance of loading it would suffer dramatically? I forget.

@ccs86 sadly this is why I've not yet tried IS. All my prints are highly segmented to the point that IS would seldom play a role.

Sounds like I should try Cura 5.0!

@v3dprinting what is your nozzle diameter set to under printer settings?

IIRC, PrusaSlicer has different behaviour if the extrusion width <= nozzle diameter

Perhaps, increase the default extrusion width to .42 or .45. Otherwise, PrusaSlicer might be choosing different weird values for you (I forget the exact behaviour, but PrusaSlicer likes to do lots of things).

@v3dprinting I was not aware of elephant foot compensation on S3D. Are you manually creating that by using multiple processes?

Also, PrusaSlicer defaults like to have weird extrusion widths and layer heights for the first layer. Triple check that there is not some funny setting somewhere you didn't expect. Use explicit widths instead of percentages, and don't leave any extrusion widths blank otherwise Prusa will automatically choose a weird number for you. Make sure your nozzle is set to the right size too. In some of those auto-selected width cases, prusa uses the nozzle width to determine things.

@fcwilt FYI, there is no need to have the numbers in the displayed name if you want to manually enforce an order. if you put the number followed by an underscore, the numbers will be omitted in the display, but used for ordering. See here: https://docs.duet3d.com/User_manual/Tuning/Macros_tasks#naming-and-ordering-macros

@stephen6309 yup I'm aware of that. The prusa team seems very busy in the background. If you ask me, they're developing a lot of stuff in private for the upcoming XL. So, there will be sparse activity for a bit, I think.

If anyone cares to take a peek into the source to see what might have changed, I would look at the commits surrounding the find and replace in g-code function that was added to 2.4.1 or whenever it was added.

@jay_s_uk I do seem to remember that around the time this seems to have popped up, prusa team changed the way/order that the post processing scripts work. So, it's very likely something the prusa team did.

@jv do your travels contain more than a single G1 travel move? I.e., are the travels single straight lines, or a combination of several line segments to avoid certain regions?

AFAIK, RRF will come to a standstill between travel moves if Jerk Policy 0 (default) is used.

@elvisprestley https://docs.duet3d.com/User_manual/RepRapFirmware/Updating_firmware#fallback-procedure-2

It looks much more like extrusion-related problems than positional problems.

@t3p3tony This is a good point. An idea that just came to mind is to use the approximate length of the move queue. iirc, about 40-60 moves? Or perhaps, half the move queue? There might be some logic behind the number of lines to send to each system. I'm open to ideas. Perhaps I will make it configurable at first, by the user.

@o_lampe Yes, certainly it would be nice to have the speeds of moves automatically adjust, if requested. However, I'm still trying to ort out a way to use the time estimates in such a way. So, for now, I'm going to try and get a quick-and-dirty test build up, so testers can have a bit of help. It doesn't seem, to me, like there is an easy way to interleave two object g-codes, besides with a slicer or script. But, if there was a script or method to easily achieve the quick-and-dirty interleave, I could focus more time and effort on the coordinated timing, etc., and skip the mvp... it's up to the testers really, which they would prefer.

I will begin work shortly preparing a rudimentary minimally-viable custom PrusaSlicer build to support concurrent printing of multiple objects. So far, the plan would be to copy and modify the sequential object printing feature to interleave the two object g-codes instead of outputting them sequentially. M596 and M400 would be emitted when needed. Is there anything else that would be required or helpful to get started testing this? At first, time estimates and other helpful features would not work.

What about shims to adjust hot end Z height? On my printer, I'm able to add shims to the top of the hot end to lower its nozzle's Z height.