@Marco-Bona said in Strange behavior with Bl touch:

@Phaedrux, I have understand where the problem lies, I have a small motor very close to the probe, if I enable the motor before touching the bed it creates some disturbance at bltouch.

From what I read before I went with BLTouch sensors on all my machines, they're very sensitive to noise. To combat this, on all my machines I've threaded the wires through a braided shield I bought from McMasterCarr. It's paid of as I don't have any repeatability issues with any of them, and two of them run next to motors and heater wires. I do heat shrink both ends to prevent the braided shield from fraying.

Interference-Shielding Expandable Sleeving
1/4" ID

I had a similar issue on a machine that showed vertical walls like in your picture. In my case, my extruder current was my issue. I increased my current from 600mA to 800mA in config.g and that took care of the weird striping issues. I'm assuming the backpressure inside the nozzle caused it to over/under extrude on a regular basis creating the bulging.

It's an easy test to increase your extruder motor current and then print again. Just something I've experienced with similar results as in your picture.

I know this sounds a bit silly, but have you tried turning the second board off and back on a few times and try to connect between each power on?

I have (4) Duet 0.8.5 boards each with unique MAC addresses and IP Addresses, and every so often when I turn them on they don't respond on the network properly. In my case, I shutoff the machine, give it a second, and then turn it on again and try to connect. Sometimes it takes 2-4 attempts before the boards respond on the network. No idea why it works, no idea why it doesn't sometimes. I have found its more frequently an issue when a machine goes un-powered for a longer period of time which means it could be some capacitor issue in the 0.8.5 design is discharging over time causing the issue and the repetitive turning it on and off recharges it enough to behave.

I also found it happens less frequently when I changed my config lines for M552 to include the S1 parameter, but I still see this happen every so often.

@fcwilt

A laser engraver would be one example where you might use G29 to measure your bed surface, and then perform a G30 to re-zero your Z axis against an object your going to engrave to set the proper z height for the correct focus length. You want the laser to move in a consistent plane, but will want a different Z position for laser focus against an object.

The same can be said for a 3D engraver or a small milling machines.

Only thing I had to do with my Ender-5 when I installed a Micro-Swiss All Metal Hotend was rerun the PID tuning. It used the same thermistor and same heater cartridge, but had a different nozzle/heater block/throat/cold zone so I figured it'd be a good idea to re-tune the PID with the new hotend.

Beyond that, I didn't have to change anything else. Even my retraction stayed the same until I fitted the E3D titan as a direct drive.

When I did a similar setup on my Duet 2 Maestro, when I upgraded to Version 3.1.1 I had to change my deployprobe.g and retractprobe.g files to P0 instead of the P3 that I used with V2 firmware.

I don't know if that's relevant to your Duet 2 Ethernet, but something to try since you said your deploy macros don't work.

@ÖrjanE said in Files in /sys on RRF3:

Ok. I guess the relevant bin-files to keep are DuetMaestroFirmware.bin, DuetMaestroIAP.bin and DuetWiFiServer.bin. The others coming from the .zip seem to be for Duet3 or the other Duet2-cards.

DuetWifiServer.bin isn't something for a Duet 2 Maestro, its for the Duet 2 Wifi board so that one could be deleted also.

It might be nice if the M308 page actually told you that you can only have Sensors 0-31 defined. I converted my Duet Maestro config which used Virtual Heaters 100,101,102 to the RRF3 and took a little while to notice I couldn't setup sensor 100. Trial an error messages only let me go up to 31. It would be helpful if there was a note on the M308 GCode command.

I'm including this here for the next guy who ends up with the same issue I had trying to create the Virtual Heater 100, 101, 102.

As far as I know, there is no order dependency apart from X and Y have to be homed before you can probe with Z. (Even that may be a wrong assumption if you just called a G30 no matter if X and Y was homed or not. I've never tried that.)

You can make it do whatever order you like in your homeall.g file, and specify your own order.

As far as stopping homing X without homing Y, you could put

G91 ; relative positioning
G1 Y1
G90 ; absolute positioning

into your homex.g file or some standard Y axis movement at the start of your homex.g file. If your Y axis isn't home'd, you'd get a fault for "insufficient axis homed" which would prevent X from homing if Y isn't done first. I would consider this more of a hack than customizing the homeall.g file.

Try increasing your extruder motor current or even try printing at a higher temperature.

You can get a similar repeating pattern if the nozzle builds up pressure that the extruder drive can't overcome. If your system is a bowden system, that could also have issues if the nozzle builds up pressure that the system can't overcome.

The nozzle pressure issue can look like a z-axis wobble problem when its not.

@fcwilt

A laser engraver would be one example where you might use G29 to measure your bed surface, and then perform a G30 to re-zero your Z axis against an object your going to engrave to set the proper z height for the correct focus length. You want the laser to move in a consistent plane, but will want a different Z position for laser focus against an object.

The same can be said for a 3D engraver or a small milling machines.

@fcwilt

Or you can just include a M561 in your homez.g and homeall.g files before your G30 ever gets called. This wipes out anything a G29 may have set.

Personally, I like the fact the machine doesn't make assumptions in the firmware. Assuming to ignore the G29 could be bad for certain applications but good for others. Making the user use the available Gcode commands to wipe or remember settings is a positive and makes RepRapFirmware very flexible for multiple platforms outside 3D printers.

I had a similar issue on a machine that showed vertical walls like in your picture. In my case, my extruder current was my issue. I increased my current from 600mA to 800mA in config.g and that took care of the weird striping issues. I'm assuming the backpressure inside the nozzle caused it to over/under extrude on a regular basis creating the bulging.

It's an easy test to increase your extruder motor current and then print again. Just something I've experienced with similar results as in your picture.

@meistron said in Duet 3 and laser:

I tried to wire them in different way but I couldn't control the laser with M3 . I go only permeant laser with full power.

According to Endurance Laser's website there's this snippet of how it works with a Duet board about half-way down the page.

How to Connect to Duet3D Wifi Board

The PWM input of the laser is connected to the Fan0 output of the Duet board.

Power control teams
M106 S127 – 50% power
M106 S255 – 100% power
M106 S0 – Laser Off

On another page on the Endurance Website it has this section close to the top of the page

Duet3D

Wiring to FAN0
G-code command M106 P0 S1 /// min power
G-code command M106 P0 S255 /// max power

Learn more >>> https://duet3d.dozuki.com/Wiki/Connecting_and_configuring_fans

I don't think you can control the laser with M3, based on their website you have to use M106.

I'm curious. Is your problem with the original E3D V6 thermistor that goes under the screw or with the newer original E3D V6 thermistor cartridge?

Unless I'm remembering something wrong, there used to be different B values for the thermistor before they switched to the thermistor cartridge. Or it was different B values with older RepRapFirmware configurations.

@Chriss

M98 P"0:/sys/homey.g"

@Chriss said in Homeing order change?:

I think I was not clear enough. There is a order, at least in the web ui. You get the message "insufficient axis homed" if you click on "HOME Y" with a "orange" "HOME X" button. My idea was to reverse exactly this order.

I'll have to check my systems, but I could have sworn I've homed Y without homing X. Especially when I'm only interested in moving Y for some reason. I'm pretty sure I've done it from the PanelDue too.

You've peeked my curiosity now, I'll have to try it out again and see if it demonstrates the same behavior you mention.

What motors are you using? 1.6A seems rather high for motor currents.

I'm basing this on my steppers on my CoreXY are rated for 1.6A but I have them set to 600 in my config and they're as quiet as can be. It might not be related, but worth checking at least.

As far as I know, there is no order dependency apart from X and Y have to be homed before you can probe with Z. (Even that may be a wrong assumption if you just called a G30 no matter if X and Y was homed or not. I've never tried that.)

You can make it do whatever order you like in your homeall.g file, and specify your own order.

As far as stopping homing X without homing Y, you could put

G91 ; relative positioning
G1 Y1
G90 ; absolute positioning

into your homex.g file or some standard Y axis movement at the start of your homex.g file. If your Y axis isn't home'd, you'd get a fault for "insufficient axis homed" which would prevent X from homing if Y isn't done first. I would consider this more of a hack than customizing the homeall.g file.