New Edge firmware 1.18beta2
-
David,
I have an issue with this firmware version on my coreXY.When I move my axes (X, Z and Y) everything looks fine
When I execute homeall it seems that the endstop logic is reversed or something else, i'm not able to home. I revedted to beta1 and it's fine.
Thanks
-
@blood3D - I have no suggestions, sorry, but FWIW; I have a Cartesian Mendel90-style printer and my homeall.g and homez.g macros are working the same on 1.18beta2 as they were on 1.18beta1.
Here's mine:
; homeall.g G91 G1 Z5 F200 ; raise head 5mm to keep it clear of the bed G1 X240 Y-240 F3000 S1 ; coarse home X and Y G1 X-4 Y4 F200 ; move 4mm away from the homing switches G1 X10 Y-10 S1 ; fine home X and Y G90 G1 X66 Y85 F3000 ; IMPORTANT: move to a bed mesh grid point - to prevent chance of Z0 height-interpolation error. G30 ;G1 X0 Y0 Z0.05 F5000 G0 X100.0 Y5.0 Z0.05 F5000 ; move tool to midway along front of bed to position for initial prime/wipe move -
@bloood3d:
David,
I have an issue with this firmware version on my coreXY.When I move my axes (X, Z and Y) everything looks fine
When I execute homeall it seems that the endstop logic is reversed or something else, i'm not able to home. I revedted to beta1 and it's fine.
Thanks
Strange, there have been no intentional changes in that area. Please confirm that you have not changed your homeall.g file. You could also try running the commands in the homeall.g file one at a time to see what happens.
-
Unless it is something that I am missing, CoreXY homing is broken in this version.
If I try to home X, Y moves randomly. If I try to home Y, X moves randomly.
Works as expected on 1.17e.
homex.g
G91 ; relative mode G1 S1 X-300 F3000 ; course home X G1 X4 F600 ; move away from the endstops G1 S1 X-10 ; fine home X G90homey.g
G91 ; relative mode G1 S1 Y-300 F3000 ; course home Y G1 Y4 F600 ; move away from the endstops G1 S1 Y-10 ; fine home Y G90 -
OK, I can guess what happened. I made a change to not apply bed compensation during homing moves, and perhaps it also disabled CoreXY motor mapping. I'll look at it tomorrow morning. I'm sorry for the inconvenience.
-
Maybe I'm missing something, but I can't seem to get babystepping to work. Nothing seems to happen when I do a [c]M290 S0.05[/c], regardless of the value of S. No motor movement. If I query it with [c]M290[/c], I get bogus values:
M290
Baby stepping offset is 000
M290 S1.0
M290
Baby stepping offset is -1073741824
M290 S0.05
M290
Baby stepping offset is 1610612736Everything else seems to work fine. I'm using my Kossel XL-style printer.
-
M290 does not cause movement itself, but it modifies future movement. It has a limit of 1mm at a time. I'll check out the behaviour of M290 with no parameters.
-
M290 does not cause movement itself, but it modifies future movement. It has a limit of 1mm at a time. I'll check out the behaviour of M290 with no parameters.
Oh, I see. Yeah, looking at the source code, I'm guessing it should be [c]%.3f[/c] instead of [c]%.3d[/c] for the printf.
rr_status reports the correct babysteps.Perhaps I'm still not getting how this works. If I do a couple of dozen [c]M290 S1.0[/c], there should be a very noticeable jump in Z next time I move X/Y, right? Z doesn't seem to move at all.
-
Thank you guys.. I report that I've the same behavior for m290. I guess tomasf explaination make sense
-
Perhaps I'm still not getting how this works. If I do a couple of dozen [c]M290 S1.0[/c], there should be a very noticeable jump in Z next time I move X/Y, right? Z doesn't seem to move at all.
The amount of babystepping that is applied to each XY move is limited so that the change in Z speed needed is somewhat less than the Z jerk speed. So if you apply abnormally large amounts of babystepping, it may take a lot of XY moves to catch up. Babystepping is intended for use with small adjustments, typically less than 0.1mm.
-
Those of you having issues with 1.18beta 2, please try 1.18beta3 and continue the discussion in the thread about that release.
