I am sure I was on RRF 3-RC3 stable so it was very weird. I did now do the config tool to get all the latest parameters and everything should be good - except temp issue somehow out of order. I made a new fan shroud and will do more testing
RRF 3.0 created some default endstops and fans, to try to smooth the upgrade path from RRF2. But that caused issue for some users. So as described in the upgrade notes for 3.01beta1, in RRF 3.01 no default devices are created:
If upgrading a Duet WiFi/Ethernet/Maestro from the 3.0 release, note that default fans are no longer created. Unless your config.g file already used M950 to create the fans explicitly, add commands M950 F0 C"fan0", M950 F1 C"fan1" and M950 F2 C"fan2" to config.g before your M106 commands. Likewise, default endstop switches are not set up, so you will need to set up X and Y endstops (and Z if needed) explicitly, using one M574 line for each, and specifying the port name. Example: M574 X1 S1 P"xstop".
The most strange thing about carbon filled was printed with microswiss hardened nozzle 0.6 mm but I could not get the walls right with tuning flow. It was printing over 0.8 mm lines at 100% flow and could never get right width on the walls. Nozzle was brand new
I had the same problem once, and it cleared up by itself. I think it was because I was accessing the web control from my iphone. I shut down the iphone app, and the wifi worked again after a Duet restart. May have been coincidence, but maybe not.
If you're talking about the physical bed levelling process: When you get it running remember that one cycle may not get it perfect. On the core xy I used to run I needed to run it three times in order for it to converge on the perfect solution.
Thanks, I have that covered thanks. I might sound like a noob but it is just RRF I can wrap my head around as I need to figure out how to get the features I am used to having as stock
Ideamaker inserts M1001 and M1002 gcodes into the generated gcode file, which RRF doesn't support (they are ideamaker firmware specific IIRC).
That doesn't stop the print from working, but if you want to get rid of them to avoid a pop-up about the unsupported gcode, you have to delete them manually from the generated gcode because they're not part of the custom start/end gcode you can configure.
G90 ; absolute positioning
G1 X90 Y95 F6000 ; go to first probe point
M558 A1 F300 ; Set single probing at faster feed rate
G30 ; home Z by probing the bed
M558 A5 S0.03 F60 ; Set multiple probing at slower feed rate
I would like to be able to limit the acceleration on the small perimeters to keep the motion a bit smoother.
Just a thought Wes but I'd imagine that if the small perimeters are segmented as is likely, then acceleration won't come into it much. It'll start a small segment at the jerk speed and finish at the jerk speed so if it's a small segment then there isn't likely to be much of an acceleration or deceleration phase. All in all, I'd have thought that changing instantaneous speed threshold (jerk) would have more of an effect on the motion of small perimeters than changing acceleration (but I could be wrong - often am ☺ ).
It's possible to do that using the old 3-, 4- and 5-point bed compensation support (G30 commands in bed.g), however that feature is deprecated and likely to be removed in a future firmware version. The recommended alternative is to use a mesh of just 4 points, one near each corner of the bed. On prusa-style printers with beds moving in the Y axis, this has the advantage that it will compensate for Y axis twist too.