Posts made by adri84dj

@Phaedrux said in One of the three Z step motors stops from EMI?:

I also notice that you have some M569 commands commented out.

;M569 P2 S1			    	  	; Z Drive 2 goes forwards
M569 P3 S1			    	  	; E0 Drive 3 goes forwards
;M569 P4 S1			    	  	; E1 Drive 4 goes forwards

And in M566 you have a V axis?

M566 X600 Y600 U30 V30 Z30 W30 A30 ; Maximum jerk speeds mm/minute

And then again in your homez you have a V axis?

M584 X0 Y1 U3 V4 Z5 W6 A7 P7 ; separate z axis motors

I think part of your problem may lie in configuration rather than EMI.

The M569 annotated commands are drivers that i are not using.

U to V are extruders. I really only use an extruder, but I think if you didn't define them, the Z axis limit switches didn't work properly.

The problem I also have is that I can't get the extruder to work.

It is clear that there is something that I am not doing well.

How do you think you should configure it.

Thank you


@Phaedrux said in One of the three Z step motors stops:

You need to add an S1 to your second m208.

ok added S1

I have done 10 Z homing, and on 4 occasions the stepper motor associated with Drive 7 stops in the middle of the journey. This occurs with the thermomagnetic switch of the heated bed activated.

If I deactivate the switch it seems that this does not happen.

In the screenshot it is seen that drive 7 is in standstill, while drive 5 and 6 are in OK.

Sometimes when Z homing and activating the magnetothermic switch of the hot bed the stepper motor stops instantly. The same stepper motor always stops (Drive 7)

I have tried to connect it to drive 8, and 9 of the Duex5 but the same thing happens.

I have removed the connecting cables of the stepper motor from the electrical duct, to avoid contact with the cables of the hot bed circuit, but the same thing continues to happen.

I still think the problem is due to some kind of EMI, but I don't know the real reason.

@Phaedrux said in One of the three Z step motors stops:

This could definitely be part of it. Your m208 command is messed up.
Can you post your home all as well?

homez.g homey.g homex.g homeall.g

Good Morning,

Duet Ethernet + Duex5 2.05.1.

CoreXY with 3 Z-step motors.

650mm x 550mm bed with 1500w 230Vac thermal silicone.
Not surprisingly, I use a solid state relay to control the warm bed.

For more security, I use a temperature thermostat, which depending on a local temperature setpoint, the thermostat opens a contact and cuts off the power supply to the hot bed.

The hot bed supply circuit hangs from a thermomagnetic switch and is independent from the supply of the rest of the printer components.

It seems that when I do a homing with the circuit breaker on the bed turned off, the Z motors work correctly.

When I do Z homing and 5 seconds later I activate the magneto-thermal switch, when the thermostat enables its contact, almost always one motor stops, and the rest continue at Z max.

Does it look like it's EMIS?

I have changed the orientation of the motor cable to move it away from the hot bed wiring, but the same thing continues.

I have changed the driver connection to rule out problems, but the same thing happens.

The same stepper motor always stops.

The funny thing is that if at that time the engine stops, I do a reset, and I do a Z Homing again, the engine works again, but halfway most of the time it stops again.

Attached diagnostic capture one after the engine stops.

When sending the M98 Pconfig.g command I receive the following error, but I don't know if it is associated with the problem I have.

error: m208: A axis maximum must be greater than minimum

este es mi archivo config

config.g

thanks

@Phaedrux

bed.g

@droftarts

Hello,

These are my files

homez.g homeall.g config.g

Good Morning,

I have built a Corexy type printer with three motors on the Z axis to do automatic leveling.

I have also installed a limit switch for each Z axis, that is, three limit switches, one for each mortor, to establish a maximum height Z.

When doing G32 the system does the leveling correctly.

Is there any way of those correction values ​​that the G32 has generated to apply them after doing a homing Z?

The idea is that after homing Z, the correction values ​​are applied and thus avoid performing the bed leveling several times, or starting from a more correct leveling.

In the delta printer there is the command M666 to make the limit switch correction. What I did after leveling was to add the x, y, and z corrections to the M666 command in the config file, and so the next time I started the printer, after homing, the end of stroke correction was applied.

How can this be applied to a Corexy with three limit switches, one for each Z axis motor?

I don't know if I explained myself correctly since I'm using the translator.

Duet 2 ethernet + Duex5
firmware 2.05.1

A greeting.

@deckingman said in Multi-axis homed Z error:

@adri84dj You can still have Z connected to driver 5 - see my post above.

hello, and this is how I have it now, but the end of the race I have to connect to duet 2 to port Z

@dc42

Since all three motors (W, A, B) are connected in drivers 5, 6, 7 of the duex5, I would like the limit switches to be connected in the duex5 as well.

If I make the configuration that you suggest, (Z, W, A), the end of the road associated with Z should be connected to the Z port of Duet 2.

Is there any way I can connect the three race finals on duex5, without having to switch to RRF3?

Regards.

When uniting the Z axis in W, A, and B, the homing is correct, but when joining W, A, and B on a single Z axis, it is when I get the homing error message

Good afternoon,

I am building a coreXY with three Z axes, and with independent limit switches in Z max.

The three Z motors and limit switches are connected in Duex5.

The problem comes when doing the homing of Z, at the end of the code, I put the three axes back together in Z, but at the end of the homing Z, DWC gives an error message that the homing Z failed.

It does all the homing Z process, but at the end it gives the homing Z error message, and the "homing Z" button does not turn blue.

This is my homez.g file configuration

; Home 3 Independent Z-Axis Drives
M400 ; Wait for movement to stop
G91 ; relative positioning

M584 X0 Y1 Z2 U3 V4 W5 A6 B7 P8
G1 W500 A500 B500 F600 S1 ; lower all z motors until each corresponding z-stop reached
M400 ; Wait for movement to stop

G1 B-4 F300 S2 ; raise Z3 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 B10 F300 S1 ; lower Z3 motor slowly until its endstop reached
G1 B-4 F300 S2 ; raise Z3 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

G1 A-4 F300 S2 ; raise Z2 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 A10 F300 S1 ; lower Z2 motor slowly until its endstop reached
G1 A-4 F300 S2 ; raise Z2 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

G1 W-4 F300 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)
G1 W10 F300 S1 ; lower Z1 motor slowly until its endstop reached
G1 W-4 F300 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)
M400 ; Wait for movement to stop

; This test move before combining axis works
;G1 W-50 A-50 B-50 F360 S2 ; raise Z1 axis slowly (S2 Ignore endstops and ignore axis not homed)

M584 Z5:6:7 P3 ; combine z axis motors

;G1 Z-200 F600 S1 ; test raise all axis slowly

G90 ; absolute positioning

@dc42 said in Firmware 2.03beta2 available:

Beta 3 is available now.

Hello,

It is already tested and in beta 3 it works correctly again.

Thanks and best regards

@dc42 said in Firmware 2.03beta2 available:

Beta 3 is available now.

In agreement. I'll try it this weekend.
Thank you

@dc42 said in Firmware 2.03beta2 available:

I've found a bug which might explain the problem, if you don't home the printer between auto calibration and printing. So please try 2.03beta3 when i release it. Meanwhile, homing between auto calibration and printing should work around the bug, assuming that your homing switches have reproducible trigger heights.

In agreement. When beta 3 is available, I try it. Thank you.

@dc42 said in Firmware 2.03beta2 available:

There has been no intentional change in this area. There might have been an unintentional change because the code that handles endstop corrections has changed. Can you revert to 2.02 and check whether the new firmware really is to blame?

Hello,

With the 2.02 final it works correctly again, as in 2.02 RC3.

At least in my case there is something weird about 2.03 Beta 2.

@dc42

Okay. I go back to 2.02 and try it later.

Thank you

Hi. So far, I've been with firmware 2.02 RC3 in my Kossel.

When I calibrated the bed with G32 with calibration factor 8, after two passes, I had some 0.05mm measurements, the difference between each measured point, and the first layer was very good

I have updated to the latest version, 2.03 beta 2, and when doing the G32 calibration several times, I get disparate measurements between the measured points of up to 0.2mm. Now the first layers are uneven in different parts of the bed.

Have I missed something? Has anything changed in this latest firmware?

Thanks and best regards