Leaving this for future reference.
https://forum.duet3d.com/topic/14544/guide-to-marlin-s-fast-bltouch-probing-feature-on-duet
![](/assets/uploads/system/avatar-default.png?v=1521803371351)
Posts made by yoshimitsuspeed
-
RE: Automated and 3D printed ski and snowboard Ptex/HDPE repair
Here is an example of the type of scanner I would be hoping to create but preferably with a cheaper and ideally smaller solution.
https://www.cncstepusa.com/cnc-laser-scanner-4500So far in the cheaper DIY 1D lidar the best resolution I have found is 1mm but I expect a little more searching should be able to find better than that.
I started wondering if even just the Duet IR probe could be an acceptable starting point but I assume it is not capable of doing a depth scan so would need to do a Z move on every measure point which isn't really any better than a physical probe. I also imagine non flat surfaces in the damaged area would mess with it.
What if I started at the most simple starting point of using something like a BL touch?
Let's say I built a mini printer with a flexible rack and pinion axis that would contour to the base and say 100mm x 100mm.
I assume something like a Duet 3 mini would have the capacity to do something like a 1mm x 1mm grid?
Then is the data for the bed leveling stored in a format that would be easy to download and either have as or convert to a point cloud or mesh?And or has anyone ever done other probing with a duet board and probe?
A quick search shows at least one possible alternate method but I would love to do it as native to Duet as possible.
https://forum.duet3d.com/topic/8685/3d-scanning-a-2-coin-with-3d-printer-and-diy-touch-probeThis looks promising.
Has that higher max points been implemented yet or is it still 441 points? I could probably work with 5k-10k.
https://forum.duet3d.com/topic/32739/increase-bed-mesh-size-for-sbc-users/3 -
RE: Automated and 3D printed ski and snowboard Ptex/HDPE repair
@mikeabuilder
Yes that is at least the starting goal.
The thought of removing material might have some merit if scanning and creating a volume from the gouges was too prohibitive but I don't think it should be too hard to do.The one big issue is that once you hit the core a proper repair takes a bit more work and generally you want to keep the exposed core as minimal as possible. I suppose you could do a manual fill of the core shots and then an automated cut and fill of the top layer but then you are kind of doing some work the way it is currently done and could just fill the whole thing at that point.
The original base material is also harder, tougher, and slicker than the fill material so again ideal is to keep as much of the original material as possible. Having a slightly expanded fill area isn't a big deal but is definitely something to factor as much as possible. -
RE: Automated and 3D printed ski and snowboard Ptex/HDPE repair
Welp can't post links so here it my response with them removed. That's BS.
The drip method is very far from ideal in many ways. The typical material is a softer more low density PE.
Burning it means inconsistent heat with at least some being heated above ideal temp. You are adding contaminants from the burning process. You also have very sub optimal control over temps and bonding between old and new material.
From a thermoplastics sciences perspective this method is horrible. It just happens it has worked well enough to be considered acceptable for DIYers.This is a much better solution which is basically a manual form of doing what I am trying to do in a more automated and controlled process.
The more you do these kind of repairs the better the results and you can get pretty good results but it is also possible for someone less experienced to get a lot of air voids, poor adhesion, etc.
Then you want to build up above the surface, and then cut back down. Oftentimes having little pockets that you come back and fill again. None of this is particularly hard but I think I would be pretty awesome to have something automated that filled the hole to a consistent say 0.05-0.1 above the surface that could be quickly lapped down.
An automated process gives far more control over temp, the ability to keep it in the optimal ranges for material properties and adhesion. Once set up it could even save time and might even have a place in pro repair shops if refined and developed enough.Yes there are similar scanners in existence already that mount to CNC machines. These systems are often designed to replicate. So they would scan a 3D object, convert it to geometry that it could then machine. This would basically just add the step of creating a volume out of the negative volume which could be easily extracted through best fit simple geometry. Or to start just through manually creating closed volumes over any gouges big enough to bother with.
I was trying to find an example of the older CNC scanners I was thinking of and came across this which is exactly what I want to do. Just on a lower budget level lol.
Here is an example of the older style I was thinking.
Base grinding is primarily for getting the edges sharp again. Or for those of us who ride rocks as much as snow at least trying to get back some semblance of an edge lol.
You can generally get quite a few grinds before it's just too thin and or compromised. But at some point any board or skis reaches the end of it's practical lifespan. -
Automated and 3D printed ski and snowboard Ptex/HDPE repair
I have been thinking about this idea to fix ski and snowboard ptex with 3D printing.
Last year I made a little manual repair tool out of a hot end with a base and spring setup where I could push the hot end down into scratches, then feed PE repair filament by hand as I moved the repair tool by hand.
This was a pretty cool proof of concept and I think my results were probably at least as good as traditional methods but still not perfect.I could make a simple working prototype for flatter areas by making something pretty close to a traditional 3D printer that mounts to the surface and prints a small flat area but this doesn't address the curved areas so I would love to make a working prototype that at least started to show something could work on non flat geometry.
One idea was wheels that roll along the surface and a pressure wheel that rolls along the back (or really top) side. Even this has challenges with the width changing and some skis and snowboards having non flat top sides. Along with wanting to be able to print right up to the edge of the board.The other big challenge if this is recognizing the gouges, assigning them a coordinate system, and then slicing and printing.
I could do this by doing something like mounting a printer, 3D scanning the surface with some reference points on the printer I can use to assign coordinates, then do some mesh work to fill the void and create a solid object to put into a slicer. This again works easier for flat areas.More ideal would be to be able to scan the surface from the 3D print head. If you had an axis that rolled along the curved surface and say a laser scanner or something that scanned perpendicular to that axis it could then basically interpolate the scan as a flat surface.
I have been wondering if there is anything that could be done easily that could take advantage of existing bed leveling firmware.
Would it be possible to do this with a capacitive sensor or is there anything similar that could easily work mostly off existing tech and firmware?Then the next question would be whether you would need to send the scan to other software. I expect the answer is yes but I have been wondering how hard it would be to take that "bed mapping" determine a best fit surface, detect any imperfections say more than .1mm deep by a couple mm squared, create a watertight geometry of the scratch/gouge, generate a simple slicing profile for that geometry and fill it in.
I recognize this would be a good ways beyond your average bed leveling gcode but I am curious if it would be possible to achieve with a reasonable amount of work.
Otherwise we could do something like send scan to a mesh editor, create 3D geometry, send to slicer, generate Gcode, then back to the printer.Another thought i had the other day was using a robot arm to do this. This eliminates the issue of trying to get a 3 axis machine to track a non flat surface. I imagine it would add a good bit of complexity in other ways though. A quick search makes it look like at least some development is going into getting Duet to run a robotic arm.
This could allow the arm to be mounted separately. If the arm scanned the surface the scan would be tied to it's coordinate system. Then it is just that matter of creating geometry for the voids, slicing, and sending back to the machine.I know this would be a pretty big undertaking.
If a finished product could be delivered for the right price I think there could be some interest in the ski industry. If it was dialed in I suspect there are even some hobbyists would would be interested in building their own. -
RE: Nonlinear extrusion
Haha I made the suggestion ages ago to adjust heat based on volumetric flow rate here and in Prusa Slicer forums and more people than not basically told me I was being stupid lol. I will check it out as that would be huge especially with filaments like TPU which I print with a lot.
I think nonlinear extrusion is still valuable especially with TPU.
I am currently running 3.5 RC2 but I have had frustrations with nonlinear extrusion for ages and several different versions. -
Nonlinear extrusion
I have been using nonlinear extrusion for years with mixed results. I have gotten setups dialed in better than running without it but it always felt like it wasn't consistent.
I have been using this calculator.I tried setting it up doing static extrusion tests marking 100mm on the filament then extruding 100mm.
I found a better method has been to see where a print is under/over extruding then tweak those tables.I started to feel like sometimes trying to increase extrusion by using a lower number at higher flow rates actually decreased the flow.
Tonight I think I finally confirmed this with the volumetric flow readout on the Duet web display. I was printing something that should have been 5mm3/s.
I started with a moderately aggressive NE number. Like say 100 at 0mm3/s and 78 at 6mm3/s (this is for TPU BTW).
The display showed something like 5.1mm3/s
So I went to an aggressive number. Something like 68 at 6mm3/s and the number Duet was reporting went down to 5mm3/s.
So then I clicked through the history and started selecting various ones I had tried before and finally found one that bumped it up to 5.3mm3/s. This was a less extreme ratio than at least one but I think several of the others I tried. Reverse engineering the numbers I think around 72 at 6mm3/s.I can test this more soon but it makes me think maybe this isn't working like it should and maybe that is why it has been such a struggle for me to dial in these settings.
All of the threads I have found on this are either very old and include these two calculators often discussed, or are newer and really don't have much information.
I will admit that the math goes a little beyond me so I need a calculator or an easy way for me to get from seeing under extrusion at a flow rate and understanding how to change values to address it.
One thing that would be amazing is if there was actually an interface in the web interface where you could just enter values to create a curve then it just does the math in the background. Even better if there was a way to link it to slicer profiles or something but that's probably getting complicated unless the slicers worked to integrate something there too IDK.Anyway I love the concept and when it works it is amazing but it feels about like 50% science and 50% pulling the lever on a slot machine. Or maybe I'm just doing it totally wrong.
-
RE: duet for 4+ axis lathe
Thanks for the input.
There wouldn't be any easy way to use a Duet board controlled by LinuxCNC or something like that would there?
-
RE: duet for 4+ axis lathe
@T3P3Tony
Yes you are talking about constant surface speed and that would be critical to a properly functioning turning setup. But it's not what I was talking about.
I guess what I was reading about must be what @dc42 is talking about. -
RE: duet for 4+ axis lathe
It's my understanding that RRF doesn't do constant state or infinite rotation type operations, or something related to the spindle . As I remember from what I have read that seems to be the big hangup but I feel like I read of other things that sounded less than ideal as well.
Also to clarify, this would be using a stepper or servo motor on the spindle with a toothed belt or similar so spindle angle is fixed to the motor to be able to do threading and operations like that, and hopefully eventually fifth axis machining. So it wouldn't just be "set spindle voltage or PWM to approximate RPM" but would be operations that precisely tie the spindle moves to other axis moves.
Of course now I am trying to find the threads or places I found this being discussed and can't find it.Ah here is one. So I guess the issue is less regarding defined rotation operations but theoretically infinite or continuous rotation operations.
-
duet for 4+ axis lathe
I have been toying with the idea of making a lathe with a 3D printed toolchanger and ultimately I would love to make it 4 or 5 axis but that would be a long ways down the road.
Reading the posts here it sound like Duet might just not be acceptable but I am running Duet boards on my printers and I would love to stay as much as possible in this ecosystem. I would also love to build it around a board like the 6HC and avoid buying controllers, drives, etc, If I'm going to use a single board I would love for it to be Duet.Is there any way to get away from RRF if it won't be acceptable for this?
I am most familiar with using linuxcnc for non 3D printer stuff so that would definitely be my prefered route if going outside the Duet web interface.
So for example would there be any way to set up a 6HC board to be run by linuxcnc?
Or other similar alternatives that would work better and overcome the mentioned shortcomings of RRF? -
RE: Proper gcode for multiple drives and extruders
@deckingman
I have different 592 and 572 settings for various materials. Particularly different TPU materials and profiles. So I have those profiles saved in my slicer custom Gcode.Also the way these call out D instead of E makes it a little confusing as well. With commands like 567 that call out E it seems to accept the value:value format for multiple extruders but I haven't seen anything that shows how to address ones that call out D0, D1, etc.
It would make a lot more sense if it all used E value:value
-
Proper gcode for multiple drives and extruders
I have an IDEX machine and I want to know the right way to set pressure advance and nonlinear extrusion for all configurations.
I have it set up so that tool 1 is the left print head, tool 2 the right print head, and tool 3 set up as duplicate where both heads print identically with a fixed offset from each other.
I am a little confused how the gcode should look for this.
Tool 1 prints as drive 0 and tool 2 as drive 1. Then tool 3 prints with drive 0 and 1.So if I am making adjustments in the console how should that look.
Like let's say I am printing with tool 1 using drive 0 I assume it's just something like this?
M592 D0 A-0.125378 B0.197786
M572 D0 S.2
Then for tool 2 it would just change to D1 correct?Then for tool 3 where it is using drive/extruder/heater 0 and 1 is where I'm really confused.
Like would I do
M592 D0 A-0.125378 B0.197786
M592 D1 A-0.125378 B0.197786
Or
M592 D0 A-0.125378 B0.197786:M592 D0 A-0.125378 B0.197786
Or something else?Then in Prusa Slicer in my filament custom gcode section how would I do the gcode to apply the proper nonlinear extrusion and pressure advance for all configurations?
To clarify, if I am using a given filament profile and select "extruder 1" in filament settings and all extruders to 1 in print settings it applies the correct nonlinear extrusion to drive 1, and same with extruder 2, but then if I select "extruder 3" in Prusa Slicer having it apply nonlinear extrusion and pressure advance to drive 0 and 1.
At least at the moment I don't think I would ever need to run a different parameter for drive 1 for tool 1 or tool 3. If I can specify in one place that D0 gets the same nonlinear extrusion and pressure advance whether tool 1 or tool 3 is selected that should be fine.Thanks
-
RE: Volumetric temp change
It's kind of mind boggling to me that people keep talking about trying to prove the concept.
Like am I really the only one who changes temp manually during printing to maximize performance? I mean not on a regular basis but in special situations.
Like if you have a big model that you want to print fast you can set it to print nice and hot and fast.
Then if there are a couple detail areas that are getting too hot you just turn the temp and if needed feed down in those areas.It works really well. It would just be nice to be able to automate it and if it was then it would add a lot of capability to printing. It's weird to me this concept seems so foreign or unheard of.
-
RE: Volumetric temp change
@droftarts I would love to do or be involved with something like that.
I am at the level of coding where I can oftentimes do what I want to do with instructions. I am a little more advanced when it comes to things like firmware code, gcode, Linux, and a couple other things but still not advanced. I feel like it would take more time than I feel like I could afford to spend trying to work that out completely on my own.
Do you know of any resources that might point me in the right direction and make it relatively easy for me to do?I have wondered the same thing about trying to code something straight into Prusa Slicer but again I am a little too unfamiliar with the territory to try to dig into it on my own. I feel like it would probably be pretty easy to do but I have yet to find any interest in doing it. I also feel like within Prusa most of the code is probably already there considering it already monitors and controls volumetric speed. It seems like you could probably almost steal something like the Dynamic overhang speed code and just change overlap to volumetric flow and the enterable parameters to desired change in temp. Or something like that.
But again I feel like I'd be getting in a little over my head on my own. I guess if I got bored I could at least get the PS or Super Slicer source code and start poking around. Hasn't made it that high up the priority list though. -
RE: Volumetric temp change
@dc42
I am a little unclear on how the feed forward functions. It is designed to predict temp drop or rise when rapid flow changes happen but will ultimately aim for the target temp ultimately correct?
Or is it or could it be used to add an adjustment real time to heat more at higher flow rates and less at lower? -
RE: Volumetric temp change
@dc42
It has been so long since I ran normal heaters I don't remember how they compare but I run Maxiwatt cylindrical heaters and I am confident they change temp fast enough to make this work.
One thing to recognize is that there is a decent bit of give to most the parameters. The acceptable temp window is pretty big so moving to stay within that window gives a lot of range to float. But being able to move that window could allow faster printing with better low speed quality.
Also things take a bit of time to cause a problem. For example if I'm running TPU at 250 and it gets really slow it will print fine for 10 more seconds or more before it starts popping or bubbling. So if there is a spot that slowed down for less than 10 seconds it could just not do a temp change, or signal a temp change but would be fine if the temp didn't change much.
Similarly if it then went back to max volumetric flow rate and was at say 215 it would take a few seconds before it started under extruding. Even if it under extruded for a couple seconds it wouldn't be the end of the world. Especially since my external perimeters are at a slightly lower volumetric flow rate so any under extrusion would be momentary on internal paths.Doing a quick test changing temp from 200C to 210 my setup took about 5 seconds to get to 205 and 8-9 to get to 210. And then 210-200 about 8 seconds to get to 205 and 15 to get to 200. Filament going through it should cool and drop faster.
If we could add a 10 or even 5 second look ahead I think the temp could easily stay within an acceptable window over a wide range of speeds pretty much all the time. Any potential deviation unacceptably outside that window probably at most for a couple seconds and only in places with more extreme rapid volumetric changes which would likely be something like infill. -
Volumetric temp change
I am wondering if there would be an easy way to get the nozzle temp to change based on volumetric flow rate. I made this suggestion in the Prusa requests because the slicer seems like the most logical place to implement it but it got no response.
I print a lot of production TPU where speed is important and where you can gain a good bit of speed if you turn the temp up a bit but when it gets to low volumetric flow areas it overheats the filament.
To implement in the slicer I was imagining something basically like defining a low and a high. So say at 4mm3/s temp=210 and at 10mm3/s temp=250
Then ideally I was thinking something like a ten second advance and smoothing. So say the temp is the average for volumetric flow over 10 seconds and if the flow changes enough to warrant a temp change it triggers that change 10 seconds in advance so that the nozzle has some time to change temps.I'm not sure how far Duet looks ahead in the code or how much of this might be possible through the board but I am curious to know what might be possible. If it was possible for me to manually or in custom Gcode tell the firmware something like 4mm3/s temp=210 and at 10mm3/s temp=250. This would work for my production parts.
And or I would be curious if there would be something similar like the ability to activate a mode that read the gcode temp and then just added some kind of modifier like say a nominal flow rate of 6mm3/s and a +-15% temp change over +-15% volumetric flow change or something like that? -
RE: Optimizing IDEX machine and Prusa Slicer
Oops mixed up left and right extruders in second to last post but trying to edit now is getting flagged as spam.
-
RE: Optimizing IDEX machine and Prusa Slicer
The next big issue is that the extrusion factor sliders don't appear to work in duplicate mode. It sounds like they are over ridden by M567 in the T2 firmware code.
If there was one clear bug/improvement from all this so far it would be that the extrusion factor sliders should not be overridden by the M567 code and that the sliders need to be able to adjust extruder 0 and extruder 1 independently while in duplicate mode.
I thought I found a workaround by manually entering something like M567 P2 E1.02:1.0 into the console and I thought this was working but now I am wondering.
Either it was not working and I have just been running spools close enough in diameter to work fine, or it is working if I enter this before starting a print but it does not seem to be changing extrusion on the fly.For example last night I was running a duplicate print and Extruder 0 was under extruding. I started the print at M567 P2 E1:1 so while running I tried M567 P2 E1.01:1.0 and say no noticeable change, then bumped it to M567 P2 E1.02:1.0, and still saw no noticeable change. A change in the extrusion factor sliders from 100% to 102% would have made a huge difference so I started wondering if M567 in the console or at least on the fly is even doing anything at all.