Topics created by TechNi

@dwuk3d My current (not yet finished) macro if it is of any interest

;AlignXYZ.g ; G90 G1 U150 V290 F20000 G1 Z50 F1000 M98 P"0:/macros/FindProbeXY.g" M574 Z1 S2 K3; Set Z to Ball Probe G1 H4 Z{global.zHit} F300 if sensors.probes[3].value[0] = 0 echo "Probe not found" break ;G1 X235 Y179 F10000 G1 Z50 F1000 ; Find basic Z position var Zpos = {50,49,48,48,48} var Zrate = {300,200,100,80} var Xpos = {10,8,8,8,7} var Ypos = {10,8,8,8,7} var XYrate = {1000,800,300,100,100} var prev = false var pXM = 0 var pYM = 0 while iterations < 4 M574 Z1 S2 K3; Set Z to Ball Probe G90 G1 Z{var.Zpos[iterations]} F300 G91 G1 H4 Z-10 F{var.Zrate[iterations]} ;echo "Z", {move.axes[2].userPosition} var ZP = move.axes[2].userPosition G1 Z5 F5000 M574 Z1 S2 K0; configure Z axis endstop ; Now find X middle G91 G1 X{0-var.Xpos[iterations]} F5000 G90 G1 Z{var.ZP-0.2} F300 G91 M574 X1 S2 K3 G1 H4 X+10 F{var.XYrate[iterations]} ;echo "X1", {move.axes[0].userPosition} var X1 = move.axes[0].userPosition G1 Z5 F300 G1 X{var.Xpos[iterations]} F5000 G1 Z-5 F300 G1 H4 X-10 F{var.XYrate[iterations]} ;echo "X2", {move.axes[0].userPosition} var X2 = move.axes[0].userPosition G1 Z5 G90 var XM = (var.X1+var.X2)/2 ;echo "XM", {var.XM} G1 X{var.XM} M574 X1 S3 ; configure X axis endstop ; Now Y G91 G1 Y{0-var.Ypos[iterations]} F5000 G1 Z-5 F300 M574 Y1 S2 K3 G1 H4 Y+10 F{var.XYrate[iterations]} ;echo "Y1", {move.axes[1].userPosition} var Y1 = move.axes[1].userPosition G1 Z5 F300 G1 Y{var.Ypos[iterations]} F5000 G1 Z-5 F300 G1 H4 Y-10 F{var.XYrate[iterations]} ;echo "Y2", {move.axes[1].userPosition} var Y2 = move.axes[1].userPosition var YM = (var.Y1 + var.Y2) / 2 echo "G92 X"^{var.XM}, "Y"^{var.YM}, "Z"^{var.ZP}," ;---X1,2",{var.X1},{var.X2},"--Y1,2",{var.Y1},{var.Y2} echo "G92 U"^{var.XM}, "V"^{var.YM}, "Z"^{var.ZP+5} if (var.prev == true) echo "variation X:",{var.pXM-var.XM}, "V:", {var.pYM-var.YM} set var.pXM = var.XM set var.pYM = var.YM set var.prev = true if exists(global.ballProbeX) == false global ballProbeX = var.XM global ballProbeY = var.YM global ballProbeZ = var.ZP else set global.ballProbeX = var.XM set global.ballProbeY = var.YM set global.ballProbeZ = var.ZP G1 Z5 F300 G90 G1 X{var.XM} Y{var.YM} F2000 M574 Y1 S3 ; configure Y axis endstop G90

With find probe here

;FindProbeXY.g ; G90 G1 U150 V320 F20000 G1 Z50 F1000 G1 X235 Y170 F10000 if exists(global.zHit) == false global zHit = 44.5 ; See if already in correct position M574 Z1 S2 K3; Set Z to Ball Probe G1 H4 Z{global.zHit} F300 if sensors.probes[3].value[0] = 0 G1 Z50 F1000 G1 Y170 X230 F10000 G1 H4 Z{global.zHit} F300 if sensors.probes[3].value[0] = 1000 break M574 Z1 S2 K0; configure Z axis endstop var y = 150 M574 X1 S2 K3; Set Z ball to X while var.y<200 G1 H4 X270 F1000 if sensors.probes[3].value[0] = 1000 break G1 H4 Y{var.y+5} F1000 if sensors.probes[3].value[0] = 1000 break G1 H4 X230 F1000 if sensors.probes[3].value[0] = 1000 break set var.y = var.y + 10 G1 H4 Y{var.y} F1000 if sensors.probes[3].value[0] = 1000 break M574 X1 S3 ; configure X axis endstop back G1 Z50 F1000

Nevermind, looks like the reason F0 did not work was due to some connector issue.

And the wrong indication for F4 & F5 was probably due to Duet Web Control still being on 3.4.0 and not 3.5.0.

Everything works fine now. Issue not related to 3.5.0-rc.1.

Please disregard.

@dc42 excellent news, thank you!

@TechNi also post your deployprobe.g file.

Nevermind...

@techni It looks generally flat along the X axis, but bowing in the Y axis. Assuming the aluminium bed is actually flatter than the probe results, I'd look at whether the carriage is rotating around the Y axis as it travels. If you have a carriage that is heavy on one side, it may be twisting the Y axis. If your probe has a large offset in the X direction, it will also exaggerate any twisting of the carriage.

Ian

@t3p3tony @dc42 Sorry for late reply, we are involved in other projects.

We will update to 3.4.0 beta6 now and see if it's gone. By the way, we use SBC mode.

EDIT UPDATE: with the 3.4.0beta6 the missing boards when M999 is still there:

9/11/2021 13:26:47 PRINTER READY, TRY HOMING ALL 9/11/2021 13:26:46 extruder driver: 2 9/11/2021 13:26:42 Error: M584: Driver 40.0 does not exist Driver 41.0 does not exist Driver 42.0 does not exist Driver 43.0 does not exist Driver 44.0 does not exist Driver 45.0 does not exist 9/11/2021 13:26:27 CORS disabled 9/11/2021 13:26:27 CORS disabled

@techni said in 3.4b2 - Unable to restore cooling fan speed?:

Note that replacing the last line with "M106 P0 R2" does not work. This is probably the reason why my printer did not restore the fan speed after toolchange. Not sure if this is intentionally or not.

Yes, it's intentional. Most slicers don't know about M106 P parameters, so they generate M106 with no P parameter. RRF recognises this as a command to set the speed of the "current print cooling fan" and it remembers the last-selected speed requested in this way separately from speeds requested of numbered fans.

@techni You have stated that you don't want to use a prime tower, but would you consider an ooze shield?

Depending on your slicer you can either generate an ooze shield or extend your skirt upward to keep it the same height as your object. If all your filament changes happen outside that perimeter the ooze will usually get scraped off by the ooze shield instead of sticking to your print.

Depending on your model geometry an ooze shield can represent a lot less plastic waste than a purge tower.

The IceSL slicer has a specific option to generate a close-contoured ooze shield which wastes as little plastic as possible while still being easily removed after the print finishes.

@techni thanks for confirming.

Side note: If you havent PID tuned your bed yet, do that too. The pulsing of a bang bang controlled heated bed can deceptively look like z wobble ...

@TimMacey the maximum number of fans was increased to 32 in RRF 3.5.

@jay_s_uk ok makes sense, thanks!

@owend This is neat. I've never used global variables before but this might actually solve other problems too, thanks!

@fcwilt @Phaedrux I think I'll use G92 then in combination with global variables. Thanks a lot!

@techni I would guess that your belt paths aren’t straight where they need to be.

Ian

@techni

Hmm...
I think 0.4mm (total tolerance) per meter is pretty good for a plate of about 5-8mm thickness. Adding up to this comes the tension in the plate due to heating up bottom to top and the tension due to thermal expansion while being fixed on standoffs. Depending on your standoff-positioning you could deform the bed if you use more than 3 screws. There is also the deformation due to its own weight...

Did you contact clever3D and ask for a thicker plate? For everything over 300mm per side i think the plate must be ticker than the usual 8mm - should be more like 10-12mm.
Have you measured your bed with a BL-Touch for example? How is the heightmap looking?

/Julien

Just to mention:
PanelDue uses resistive touchscreen not capacitive one - so putting any glass lens in front of it will make touch unusable.

@stuartofmt Thanks, this looks great! Is it possible to remove the scroll bars?

I checked the crimps, switched the drivers again, tried M84 (executes without error message but motor still doesnt respond after that) and also updated the firmware. Nothing. Problem still persisted.

Fortunately, I think I have found the problem and seems like it's the G-code which would be logical since the reset always happens at the exact same location in the G-code. And the reason for the "bad" G-code is an .stl file with a bad mesh. Funnily enough, it is one of the most downloaded files on thingiverse: the Benchy. After I fixed the mesh in PrusaSlicer, the Benchy printed just fine. The reason why this also happened in Cura is because I am not sure if Cura fixes the mesh sufficiently.

May it be possible that this is also a firmware problem? Considering how often the Benchy is printed with a faulty mesh and without mesh fixing, most firmwares probably still somehow manage to deal with this.

Well going back x lines can be either a very short or long time, depending on the model's dimensions. In the worst case you might even skip a layer, thus you will need to take that into account, too.

The tip forming method sounds interesting, has nobody found out what Gcode they use for it? If the tip is formed inside the hot zone, it's probably just a sequence of retractions/unretractions and maybe a temperature change.