Welcome! Log In Create A New Profile

Advanced

Delta printer; Repetier; CuraEngine: holey inner structure

Posted by BigMan200 
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 02:42AM
Paul, there is no need to recompile the firmware to tune pressure advance in RepRapFirmware. You just send a new M572 command with a different S parameter. You can do this while the machine is printing so that you can see the effect almost immediately.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 05:30AM
I think that the biggest problem with pressure management in firmware is that firmware does not know whether the given segment is a bridge or not. And optimal pressure as well as speed will depend on this information.
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 06:01AM
Quote
hercek
I think that the biggest problem with pressure management in firmware is that firmware does not know whether the given segment is a bridge or not. And optimal pressure as well as speed will depend on this information.

Can you explain why you think that bridges need different pressure management compared to other extruding moves?



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 07:37AM
Quote
Paul Wanamaker
It's not surprising the so called Advance algorithm in Slicer/ (and Repetier if it uses Slicer code) works poorly for a bowden. Examine the output gcode (with verbose mode turned on) and you will see that it is just goosing the filament and retracting it the same amount. This is not helpful with a bowden.

Well, I'm ok with the idea of retracting, then pushing the same amount of filament, if we do that with proper timing. Repetier firmware was headed the right way I think, by starting to retract before the end of the move, and beginning to push before the start. See this video from 2011: [www.youtube.com]

Beside that, I'm ok with it being done at a post-processing stage. At least, it's great for debugging. But currently I can tweak all important parameters on the fly while printing (at least with repetier-dirmware), such as accelerations, temps, speed, advance, etc. And as your pointed, that's more difficult to do with a post processor.
Also I agree that the limits of doing that at firmware level is the context: it doesn't know if the movement is an external perimeter, a bridge, etc. So point taken for the post-processing stage.

Do you think it would be possible to put your code on github so that I can fork it and maybe help making some progress?

In the mean time, thanks and take care.
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 03:56PM
Quote
dc42
Can you explain why you think that bridges need different pressure management compared to other extruding moves?
I think there are two things to consider. They work against each other.
  • when there is an obstacle in flow (in our case the previous layer then it will flow more slowly at the same pressure)
  • then the extruded filament sticks to previous layer and the head moves across the previous layer then the viscosity of the melted plastics actually pulls the melted filament from the hotend
I do not think these two opposing forces cancel well because when I print bridges I typically do not get uniform thickness of the filament extruded in the bridge area. I see that the extruded filament seems thinner about first 3-4 mm and then it gets thicker. Overall it looks that there is more material in the first layer (maybe even first two layers) of the bridge. It is hard to tell the volume is definitely bigger but also packing is looser and I do not have precise enough scales to find out.

In general, the bridges should be printed with full fan, only very slowly (around 1 cm/s) and over-extruded. Or probably better first under extruded and then (over the same path and the same z-height) over-extruded. But this is strictly slicer thing and unrelated to your question whether pressure management should be in firmware.

Regardless of the above, of course, you can keep some pressure management in firmware (at least you can tune it during a print). And, almost for sure, you can properly compensate for possibly wrong firmware pressure management on bridges in slicer. So you can have part of it in firmware and part of it in slicer.
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 04:31PM
Bridges are bound to be extruded too narrow unless you increase the flow rate. If you normally extrude at 0.2mm layer height through a 0.4mm nozzle, the filament gets squashed between the nozzle and the previous layer. When bridging it doesn't, so for the same extrusion rate, the filament will solidify narrower and deeper.

Have you tried bridging with firmware that implements a good pressure advance algorithm, to see whether the filament width still changes after 3-4mm?



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 05:24PM
I tried bridges which where straight.
15 mm straight part, 20 mm straight bridge, 15 mm straight part.
That means the slicer segment was 14+20+14 mm log (1 mm for shell thickness).
That is my testing piece for bridges. I did these tests with speeds of about 1-2 cm/s.

I doubt pressure management would do anything on that 48 mm long line segment. I print everything at the same speed (bottom/shell/infill/top). So there are no real speed changes except when filament is (un)retracted. And my acceleration is 7200 mm/s². When speed is about 20 mm/s then the length of the acceleration segment is 0.028 mm (less than 3 microsteps). The travel speed is the only speed which is different (250 mm/s). The only pressure management I tried was the one in Repetier and I decided that it does more bad than good. But I do not really believe any firmware with a pressure management would print the bridge I described differently at the location where it matters (i.e. just around the bridge) ... and considering my acceleration/speed settings for this test piece. There is no retract near the bridge location.
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 05:28PM
Here is the test piece:
Attachments:
open | download - bridge-test.stl (11.8 KB)
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 04, 2016 06:49PM
Quote
DC42
Can you explain why you think that bridges need different pressure management compared to other extruding moves?

Bridging and sparse infill have similar issues (sparse infill being crossed layers that only touch at intersections), it shows up more as you can see the unsupported filament breaking. It's not really a different issue than with other large changes in pressure.

For example: you have a .5mm nozzle, and you are printing at .6mm wide x .2mm layer height at 40mm per second. That is 4.8 mm3/second.

Then you print a bridge or sparse infill at the same speed...

The extrusion of the bridge/sparse infill will be circular - as it is unconstrained - and it must be very nearly >= nozzle diameter or it will snap.
So if it is also printed at 40mm per second then you get 3.14159 * (.25^2) * 40 = 7.85 mm3/sec minimum, which is a much higher rate. It takes time and increased pressure to extrude at that rate.

If you watch videos of bridging or sparse infill, you will see that the first CM or more of the first segment will be starved, and often the first line will drop from it's anchor point.
Also if the extrusion amount is not enough, then the sparse infill will also break as it crosses previous layers.

If the bridge/sparse infill is slowed way down then it can work as-is, provided the extrusion is enough.

However for higher performance there are two things that are needed to make this extrude properly from the start - when there is a large change in pressure.
1) insert a slower acceleration for the first MM - this gives time for the pressure to ramp. The amount needed will vary according to the extruder and hot end setup and friction in the system.
2) increase the starting pressure, so the higher volume is extruding - using a slightly larger unretract.


My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 05, 2016 05:09AM
Hmm, interesting way to look at it. That could mean that bridges do not have more material and there would be somewhat more material in the part after the bridge. Higher pressure from bridge would extrude a bit more when flow requirements are lower just after a bridge. But it nicely corresponds to my experience that the first few millimeters of a bridge filament are under-extruded.

Anyway, we have our G-codes almost all wrong. Our printers are mostly open loop. We should be sending an N-dimensional NURBS (e.g. X,Y,Z,ext1,fan1; or for a delta: tower1, tower2, tower3,ext1,fan1) and not our current G-codes. Jerk and acceleration should be slicer settings and not firmware settings. As well as cartesian -> delta transformation should be in slicer. PC has much more computational resources as well as much more information (and in a better form) about the printed part than firmware has.
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 05, 2016 05:06PM
Quote
hercek
Anyway, we have our G-codes almost all wrong. Our printers are mostly open loop. We should be sending an N-dimensional NURBS (e.g. X,Y,Z,ext1,fan1; or for a delta: tower1, tower2, tower3,ext1,fan1) and not our current G-codes. Jerk and acceleration should be slicer settings and not firmware settings. As well as cartesian -> delta transformation should be in slicer. PC has much more computational resources as well as much more information (and in a better form) about the printed part than firmware has.

I am in the unusual (for me) position of disagreeing with you. While gcodes are far from ideal, I believe most of the machine-dependent settings should be configured in the firmware, not the slicer. If I want to retry a print with different accelerations etc. then I don't want to re-slice. I can (and do) change speeds, accelerations, pressure advance etc. on the fly sometimes.

I would like gcode to be more portable between machines, which would mean doing less configuration in the slicer. I am thinking of redefining the (0,0) XY origin as being the centre of the bed on my Cartesian printer, so that I can print the same files on both it and my delta. Maybe also add a "Hot end temperature adjust" gcode to allow for different hot end characteristics. I guess nozzle size is one thing that the slicer will still need to know.

Your argument about computational resources for Cartesian to delta transformation might have been relevant four years ago, but is irrelevant now that fast 32-bit high pin count processors cost less than the older 8-bit ones. Also, the slicer would need to pass a lot of information to describe the motion of a delta printer carriage when the head is describing a linear move, including the acceleration and deceleration parameters. Auto delta calibration would be ruled out, unless you fed the results back to the slicer and then re-sliced.

I can see that there might be a case for including additional information in the gcode file, such as whether a move is a standard, bridging, or overhanging move. But on the whole, I don't think the firmware that interprets gcodes has much need of knowing about the model it is printing.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 05, 2016 05:26PM
PS - I just uploaded a short video at [www.youtube.com] showing how the application of pressure advance often requires filament to be retracted during the deceleration phase at the end of a move.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Delta printer; Repetier; CuraEngine: holey inner structure
April 06, 2016 04:08AM
Portable G-code files would be a good reason for advanced features in firmware. Though I do not think it is likely to happen. How many people use volume-metric E-axis to get nearer to it? Is it the default in at least one slicer now? Coordinate system center, speeds, fan, start/end G-code, and especially the nozzle size.
I doubt we will ever achieve portable G-code. Nor I think it would be good. Imagine how worse the situation would be when people would be posting only G-code files instead of STL files on thingiverse. All the CNC guys would be busted.
I also doubt many people want to fiddle with parameters during a print. I just find the right ones and do not touch them any more. The same with calibration. I do it once and do not touch it until I change the printer components.
Anyway this is idle talk. The industry will probably stay backward compatible. With G-code about the same as it is now.

The video on youtube is private.
Sorry, only registered users may post in this forum.

Click here to login