Topics created by axiom

@axiom only create a bed mesh of the area of the print: https://forum.duet3d.com/topic/37242/mesh-bed-leveling-only-in-printing-area-using-orca-slicer

Ian

@axiom have you tried inverting the pin logic by putting an ! mark in front of the pin name in the M591 command:

https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m591-configure-filament-sensing

https://docs.duet3d.com/User_manual/RepRapFirmware/Migration_RRF2_to_RRF3#pin-name-format

@axiom 1736183041163-flow.jpg

@stuartofmt Thank you for the answers, everything actually works if I simply copy the IP address from Motion....sadly my new raspberry 5 said goodbye after 1 hour...despite the expensive original fan and expensive power supply

@axiom octoprint can be run on an rpi5 https://community.octoprint.org/t/raspberry-pi-5-octoprint/60487/2

@engikeneer thank you very much, then I will just print a few tests

@jay_s_uk
wow, thank you so much! That was the solution, now I just have to figure out the input shaping....have a nice Sunday, cheers, Don

@axiom you can install Raspbian bookworm which supports the RPi5 and then use OctoPrint Deploy https://github.com/paukstelis/octoprint_deploy -- I haven't tried this myself (for lack of an RPi5) but it's a suggestion straight from the OctoPrint community forum.

@axiom

What do you mean when you say "If I set my z-offset at a certain point"?

With the deviation you have in your bed you are going to need to use Mesh Bed Compensation which is what the height map is needed for.

You mentioned "bed leveling" and I don't know if you mean true bed leveling using G32 or are simply using the wrong term for Mesh Bed Compensation.

Are you setting the Z=0 Datum using G30 are a fixed location like the center of the bed?

You must set the Z=0 Datum before you create the height map and before you load the height map at the start of a print.

Also it is best to create the height map at the same bed temperature that would be used during printing.

Frederick

@axiom

You can use G92 to sync up the logical position with the actual physical position.

But if you can move past the endstop until it is no longer triggered you would have to insure that every Z homing operation began with a relative move to be sure you were no longer past the endstop. And that move could cause a problem if you happened to be near the max end of travel.

As you can see I deal with that problem by insuring that endstop can be triggered all the way to the end of travel regardless of where it is initially triggered.

Frederick

@OwenD Thaks a lot!!!

@axiom said in Position change after mesh bed compensation (G29):

@axiom Oh I saw fcwilt's reply too late....thanks! But again when do I use the G29 command and when the G32? Unfortunately, I can't do anything with the translation into my language

To use them as intended:

G29 runs mesh.g G32 runs bed.g

The file mesh.g is associated with the feature known as Mesh Bed Compensation. This feature tries to compensate for bed irregularities during printing. The file should contain the commands needed to probe the bed and create the height map.

The file bed.g is associated with the feature known as Bed Leveling, though as discussed it should be termed Bed Tramming and you may see folks refer to it that way. The file should contain the commands needed to probe the bed and "level" it using either automatic or manual modes. Manual Mode requires 2 or more "thumb screws" which can raise/lower the bed at different points around perimeter of the bed, say, Left Rear, Center Front, Right Rear. Automatic Mode requires 2 or more Z steppers and the replaces the manual adjustment of the thumb screws with automatic adjustment of the Z steppers.

Here is an image of a new bed that is being fitted to one of my printers. The three "tabs" extending from the main bed area are where the three thumb screws attach to level the bed when using Manual Mode:

SAFPRO Bed.jpg

Here is a quick-and-dirty video showing my printer which is fitted with 3 Z steppers for auto leveling:

Automatic Bed Leveling Demonstartion

Frederick

@axiom look at Phaedrux post https://forum.duet3d.com/topic/15030/can-t-access-wifi/32

You can create a file with the SSID and password in it and run that to provision the new board.

@axiom the over temperature message is specific to that driver. Does it feel hot? You can get spurious messages if the SPI bus (used to communicate with drivers to set their configuration) is damaged, or a damaged driver is sending garbled message, but this seems pretty consistent that driver 4 (E2 on a Duet 2) is damaged. You can disable the driver and messages in config.g using

M569 P4 R-1

Ian

@axiom If you use two motors on one driver (either by using the two outputs on the Z axis, or by wiring the motors together and connecting them to the single output on any driver), that driver will have to work a bit harder, but so long as these aren't particularly big motors, or trying to go very fast, it should be fine. Ideally you'll be using a 24V power supply.

With the motors on separate drivers, you are spreading the load, and the motors can even be controlled independently. That's why people often use them for the Z axis, because the axis can then be levelled automatically. People with CNC routers often have two motors on Y, and put these on separate drivers, which allows them to square the X gantry to the Y axis. Normal commands to the axis are carried out by both motors unison. Though this isn't a particular advantage in the way you want to use them, as your motors are connected to the same belt.

I'm assuming you're using RepRapFirmware 3.x. If you are older firmware, please post your current config.g and the response to M116.

X motors connected to different drivers

If you connect the second motor to E1 (driver 4), you should add an M569 to set that motor driver. So add something like this to config.g:

M569 P4 S1 ; physical drive 4 goes forwards M584 X0:4 Y1 Z2 E3 ; set drive mapping

If the extra X motor turns the wrong way, change M569 P4 S1 to M569 P4 S0. There's also an example on this page https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_configuring#using-more-than-one-motor-on-an-axis-with-a-separate-driver-for-each-motor

X motors connected to Z driver

If you connect both X motors to the two Z driver outputs (the labels don't really matter, the Z driver is driver 2), it's probably easiest to swap the Z motor onto the X driver (driver 0), assuming you only have one Z motor. This leaves your E1 driver still available:

M584 X2 Y1 Z0 E3 ; set drive mapping

If the extra X motor turns the wrong way, you'll need to adjust the wiring of the motor, and swap the two wires of one of the phases in the plug. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_connecting#using-the-internal-drivers for an explanation of the motor phases. Lower on that page is a description of connecting two motors to the ZA and ZB connector.

X motors wired together in series, connected to the X driver

Alternatively, you can wire the motors themselves in series to one plug, and connect it to the X driver. You won't have to change M584 for this:

4072e6c5-0875-4a14-aa76-15aefae64f8c-image.png

If you're still not sure, please post your current config.g and the response to M116, so I can see what firmware you are on.

Ian

@dc42

I just ran into the same thing... 2 of my drivers were complaining about over heating...yikes!
This is on a Duet 3 Mini 5 with 6 active stepper motors.

So, I'm off to print a backing plate with taller stand-offs and a mount for a blower fan. My stepper motors are all fairly cool, but the amperage draw makes sense. My FLIR ONE camera came in handy yet, again! ; )

Cheers!

@Phaedrux Puck.jpg
The part with the blue cap is the capacitive sensor, the part on the glass plate on the heatbed is the "puck/microswitch". Contact with the printhead triggers it...that works

@Phaedrux Worked great! Thank you Phaedrux!!!!👍

How can you do such an automatic measurement with a macro that older filmware could also interpret, e.g. 2.02(RTOS) (2018-12-24b1)!?
video1
https://www.youtube.com/watch?app=desktop&v=gvwfQ_r7xoU
video2
https://www.youtube.com/watch?app=desktop&v=00g7d2wuFAI

@axiom said in steps of my x-axis are not correct:

,...............Are the steps of the x-axis adjusted in the same way as with the extruder..........

No. Extruders are different because there are variables such as how far the teeth that grip the filament bight into it. With belts and pulleys, no such variables normally exist, so the calculated value based on known dimensions should be correct.