It’s actually very common, the two Z axis stepper motors are for bed slingers to have a stepper on each side of the X axis gantry, so the force holding it up is equal on both sides.
I wouldn’t recommend doing that when you have printers set ups with more than 16 microsteps.
X,Y,Z0,Z1,E that’s 5 motors (very common)
A few very large bed slingers use 2 Y motors… they would use 6 I guess but they typically use 8 driver boards or proprietary boards.
Thanks for the response. I finally have had an opportunity to resume working on this.
I did want to clarify though, does the parallel wiring of the two z steppers sharing one z driver mean you cannot even use sensorless homing at all or does it just make it extremely inaccurate and unreliable as you guys have mentioned. I also saw that the official Klipper documentation advises against using sensorless homing for Z axis but it never mention you cannot.
I have been looking into what other people usually do and see that they typically tend to use auto-levelling probes or end stop sensors as a more reliable way to home a dual z platform. However, does this necessarily mean sensorless is not an option at all or does it just mean its unreliable? I was wondering because I’m not actually building a 3D printer so it does not really concern me to have the z levelling exact like you would for a 3d printer.
In my klipper config, I have only defined stepper z and the z driver as such: [stepper_z]
step_pin: PC6
dir_pin: PC7
enable_pin: !PA9
microsteps: 16
rotation_distance: 6
endstop_pin: tmc5160_stepper_z:virtual_endstop
position_endstop: 0
position_max: 120
homing_retract_dist: 0
homing_speed: 5
[tmc5160 stepper_z]
cs_pin: PB10
spi_bus: spi2
run_current: 1.1
sense_resistor: 0.075
stealthchop_threshold: 999999
diag1_pin: ^!PC3
driver_SGT:4
I have two z motors connected to motor slots 3A and 3B on the MANTA Board however and noticed that both motors would home on the software but would not physically move to home. Since the system now thinks the motors are homed, I was then able to simultaneously move both z motors to the same position to achieve dual z motion.
Would anyone have any ideas as to why it has not been physically homed. Could it be a lack of current going to both motors as you guys mentioned earlier. When I set the run current above 1.1 the Pi essentially crashes and nothing moves so I suspect that I have surpassed the rated current for the motors, as the motors I am using are only rated for about 0.6 A each.
Would I need to define a stepper_z1 object? Although, if I do, how could I do so without using the driver pins reserved for the other extruder axes? Can I duplicate the z driver pins by also assigning stepper_z1 to the z driver pins?
At the heart of things, this isn’t a sensorless homing issue.
The whole point of homing a stepper motor is to establish it’s position. If you have two stepper motors wired in parallel, there is no way you can determine the position of both stepper motors - it doesn’t matter sensorless homing is used or a physical endstop micro switch, a BLTouch sensor, an inductive sensor, etc.
How did you establish the driver_SGT value of “4”? If you are starting the homing operation (ie G28 Z) then you should see some movement until the mechanism attached to one of the motors comes into contact with something.
If the motors don’t move, then you haven’t set up the SGT value correctly.
That would be my recommendation.
You can’t do that - you’re setting up another stepper motor driver so you need MCU pins to do that.
If you’re stepper motor socket limited with them M5P then look at using a CAN toolhead controller for a stepper driver that doesn’t need to be a TMC5160 (in this case it can be a TMC2209 or TMC2240) or consider using a Manta M8P.
Thanks for the reply. So essentially I was able to determine what my driver_SGT would be because I’m using the same actuator on the x and y axis as I am for z when testing and was able to get the actuator homed properly when using a threshold of 4 on the x and y axis. All I have been doing to now test it for z is moving the actuator to the M3A slot on the board. So I’m not sure why it wouldn’t be homing? How else could I have set it up wrong? I’ve also ensured to use the same velocity and run current as I did for x and y so don’t think those variables could be wrong.
The only explanation I can currently think of is because I’m sharing one driver amongst the two motors so I can see how the suggestions you listed go.
Could you provide some drawings/pictures of your wiring and set up? It’s really impossible to understand what you’ve describing from a text description alone.
I have no idea what you are physically trying to do - I don’t think you’ve ever given a description of your hardware.
Stallguard (the TMC hardware that implements sensorless homing) monitors a change in the resistance of a singular stepper motor through the changes in current flow when the motor is physically stopped and there is no back EMF.
Having two motors in parallel will provide different operating conditions both running and when one or both are stalled.
This goes back to me asking for a description of what you are doing.
I don’t understand why you feel that setting the position of one stepper motor will give you a good idea of where the other stepper motor is located.
I’m not sure you realize that Stallguard will give only give you a repeated position to within 0.5mm or so - that’s find for X/Y in a 3D printer but not adequate for a 3D printer’s Z axis and you will not get an accurate position for both stepper motors.
Do you understand how a bedslinger 3D printer works with two Z axis steppers set up with Z-Tilt enabled? I would think this should be your basis for your Z axis.
Managed to get it working with an M8P which was less of a headache and ended up needing the extra driver slots anyways for added functionality. Was able to get it working by assigning separate drivers to Stepper Z and Z1 and am able to home them together by assigning the diag signal from Z to both end stop pins or home them separately by assigning their own diag signals to their end stop pins.
I did have another question now about utilising a IR Obstacle Proximity Sensor Switch with the MANTA Board. So I wanted to check two things:
Can I integrate the input from this sensor into Klipper and my own app by essentially assigning it to the pin outs of an unused end stop switch or proximity sensor and then in my app I can essentially program a motor to start running when a signal is detected by the allocated signal pin?
This sensor requires 5V DC input voltage. Does that mean I can connect it directly to one of the MCU pins? I was reading and saw that the Manta M8P MCU operates on 3.3 V logic so does that mean feeding in a 5V signal would be detrimental? Does the board already have inbuilt ways to pull the output to 3.3 V similar to how the USB power supply works or is it safest I just get a sensor that operates on 3.3V?
I’m glad you have a solution for your Z axis stepper motors.
Can you provide more information about the “IR Obstacle Proximity Sensor Switch”? Datasheet and pictures would be most helpful.
What kind of motor are you talking about? If it’s a basic DC motor (or an AC controlled by an SSR) yes, easily using a gcode_button statement.
If you want start a stepper motor turning, I don’t think Klipper can handle that as it is designed to move steppers in a defined manner, not have them “start running” without homing or moving to a specified position.
Again, more information about the sensor would be helpful.
The short answer is that you’ll probably be okay but I would like to see documentation about the sensor and have you specify which pin(s) on the Manta M8P you want to work with.
I have attached the data sheet for your reference no worries.
Basically would want it to start turning one of the stepper motors that will behave akin to an extruder. This stepper will act as a roller in my model and will be connected as Motor 5 to driver No. 5 on the board with the following Klipper config:
[extruder]
step_pin: PG13
dir_pin: PG12
enable_pin: !PG15
microsteps: 16
rotation_distance: 33.500
nozzle_diameter: 0.4
filament_diameter: 1.75
heater_pin: PA0 # HE0
sensor_pin: PB0 # T0
sensor_type: Generic 3950
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
[tmc2130 extruder]
cs_pin: PG14
spi_software_mosi_pin: PG6
spi_software_miso_pin: PG7
spi_software_sclk_pin: PG8
run_current: 0.800
stealthchop_threshold: 999999
Since it is an extruder, isn’t there no need for it to be homed first. I’m happy to wait for the x, y and z axes to home first and then the roller start rolling when it detects an object being fed so wondering if this would be possible?
Also since I am not using this driver’s end stop pin and do not require any sort of homing for that roller, I thought I could connect this sensor to the MANTA’s end stop 5 switch pin PF0:
#End Stop 5
[filament_switch_sensor material_0]
switch_pin: PF0
Appreciate the support!
E18-D80NK IR Sensor.pdf (731.7 KB)
The Optical sensor should work without issues with the end stop sensors.
Rather than using the filament_switch_sensor statement, I would say start with a gcode_button statement.
However, you still have the same issue of wanting to run a stepper motor while other operations are taking place - as far as I understand it, Klipper can’t do that. This is why I said previously that you would need to have a DC motor that would run continuously.
Klipper runs GCode statements sequentially, not concurrently.
I see that makes sense then. What about from an electrical safety standpoint, is the voltage that the sensor outputs essentially safe for the MCU on the manta board in your opinion, considering the electrical specs in the datasheet?
There is no voltage output - according to the datasheet it is an open drain output. The endstop sensors of the Manta M8P have pull ups to 3.3V (and a supply voltage of 5V), so everything should be fine.
Perfect thanks for clarifying that. Will see how it goes with the DC motor then. Bummer that Klipper doesn’t let you execute G code commands simultaneously. It’s a bit odd though because don’t 3D printers in general have simultaneous extrude and axis movement? So surely the ‘extruder’ (in my case the constantly rotating roller) can move simultaneously to the platform with dual z???
GCodes are not meant to be executed concurrently - just sequentially. That doesn’t mean that multiple steppers aren’t executing as a result of a single GCode statement (X/Y movement, for example).
The issue is having to sequence multiple steppers, working independently. It’s not a trivial ask.
I see then. I will definitely try compiling and sending GCode commands that execute multi-axis movements would be interesting to see if I can pull it off.
You’re not getting what I am saying.
During an X/Y movement (let’s not worry about running the extruder or how accelerations are handled along with the basic movement for now), Klipper has to calculate and schedule step pulses for the two motors. If the movement is at a diagonal, the step pulses to the X and Y stepper motors happen at different rates, at different times, to make sure the toolhead moves correctly at the specified angle.
There is no provision for adding an independent stepper that has its own step requirements into the mix. This would complicate the step scheduling and make it more difficult for the primary function (ie executing the GCode commands of the model being printed) to run properly and give a good quality print.
Is it possible to modify the python code that is doing the scheduling to add a separate, independent stepper motor function that generates scheduling for the required step pulses without affecting the quality of the 3D printing operation?
Sure but it will be a one off and you’ll have to do the work. Don’t expect much help or support as this is a one off requirement and will involve changing the core functionality of Klipper.
Again, your best approach is to run a DC motor instead of a stepper and figure out a way to tune it to run at the desired speed (ie with a PWM driven by something like a 555 timer to see what is required).
If i am not mistaken @koconnor has added (at least experimentally) support for 5 and 6 axis coordinated moves.
This is not an extra axis that is a “coordinated move”.
It is running a motor when a sensor is tripped, independently to the execution of the GCode files.
That’s not how I read it.
I’d look at the code except I’d not understand 1% of it.
The request operation happens independently of the operation of the GCode file and the movements generated from them.
I’m sure somebody could add an independent stepper control to the code but, as I said above, it’s a one off and there is real danger that it will throw off the timing of the steppers involved in the actual printing.
I didn’t probe @AlSabra further because I’m not sure what happens if the motor stalls or even if that is part of the design. If the stepper stalls, that will cause (over)heating of the motor driver as well as the stepper driver being in an unknown state (ie if it’s a TMC2209). Going down and using a stepper just keeps opening cans of worms inside cans of worms.
The easier and safer option is to use a DC motor that’s turned on and off by the state of the sensor using the gcode_button statement.