Unpark when using Z_SAFE_HOMING with Dual X

[thinkyhead]

Addressing #5162

Since the first carriage moves with Z_SAFE_HOMING it shouldn't be considered parked afterward, otherwise the next move will try to "unpark" the nozzle and produce a very slow movement back to home position.

Addressing #4694

• Only move the carriage on tool change in auto-park mode.
• Don't presume that X is at home on tool change.

Addressing #4695

• Don't exceed Z max in Dual X tool_change

[dp90pusika]

hy, @thinkyhead I can test this PR for you frequently for you,if that is of any use for you.

[thinkyhead]

@dp90pusika That would be of great help. Let's coordinate. I'm not sure of the full status of the related issues linked in the OP.

[dp90pusika]

Yes, sorry.
I am testing @esenapaj's Marlin Duo on a RADDS board with Arduino Due.

But I hooked up a test bench to test the original 8 bit firmware.

I have a dual X carriage machine and I'm also using dual Z steppers and dual Z endstops.

The problem is with the DXC_AUTO_PARK_MODE and the DXC_DUPLICATION_MODE. The tool heads are behaving insanely, trying to park in the wrong direction, and traveling with speeds faster than the max feedrate.

I have a somewhat more detailed description, and a video of the behavior in this issue: https://github.com/esenapaj/Marlin/issues/156

I'm not much use as a coder, but I really want to help out if I can.

Right now I'm using this firmware: https://github.com/Wurstnase/Marlin4Due

It seems to get the dual x carriage tool-changes and movements perfect, the only issue with it is, in duplication mode, the second extruder motor is disabled.

A lot of definitions are really different from the current firmware, but maybe it can shine light on the problem.

[thinkyhead]

The problem is with the DXC_AUTO_PARK_MODE and the DXC_DUPLICATION_MODE

No kidding…

It seems to get the dual x carriage tool-changes and movements perfect

Wurstnase's branch diverged from Marlin around version 1.0.1. New issues have been introduced as we changed a lot of stuff in Marlin without enough testers checking every configuration. Dual X setups are rare enough that these things were missed. We could compare current Marlin to older Marlin, as well, where these issues also did not exist. But in some sense it is easier to go forward.

One thing that can help is to comment the code in detail and make sure we understand why every line is there and what is should accomplish.

[thinkyhead]

I hooked up a test bench to test the original 8 bit firmware.

A good start, I think, would be to compare all Dual X options using RC6, then RC7, then RCBugFix, and then this branch (https://github.com/thinkyhead/Marlin/tree/rc_dualx_homing). Take notes on what works, what doesn't and so on. Do things in a few different orders to see if action A affects action B, etc.

Thank you for taking action on this!

@AndrewDiehl should join in on this effort as well.

[dp90pusika]

compare all Dual X options using RC6, then RC7, then RCBugFix, and then this branch (https://github.com/thinkyhead/Marlin/tree/rc_dualx_homing).

On it, I will do a detailed report in a day or so.

[dp90pusika]

(the jerking moves I mention is probably due to the 400step/revolution I use, the mega has its limitations I guess)

RC6

READ: x_min: open
READ: x_max: open
READ: y_min: open
READ: y_max: open
READ: z_min: open
READ: z2_max: open

• Z2 endstop not working, z homing only watches z1 endstop
• homing is normal for other axes.
• Auto head change works as it should, duplication mode works as expected
• X1 X2 and Y axes do some jerky movement probably in their accelerated moves.
• jerking starts at 150 mm/s, than at 165mm/s i's suddenly so bad that the axes are barely moving. Then up until 325mm/s it gets better where it starts to move really slow again.

RC7

READ: x_min: open
READ: x_max: open
READ: y_min: open
READ: y_max: open
READ: z_min: open
READ: z2_max: open

• Z homing is busted, Z1 and Z2 stepper goes away from home direction like it is a home bump move.
• Auto park and duplication mode works fine. but the z axes thinks that the home switches are triggered, and starts wherever it is sitting.
• The jerking movement persists exactly like in RC6.

RCBugFix

READ: x_min: open
READ: x_max: open
READ: y_min: open
READ: z_min: open
READ: z2_min: open

• All axes homing works fine, dual z endstop homing is correct.
• When started a print, the Z axes started to move away slowly from home position and Y axes did the same thing, seemingly to an arbitrary point, then they quickly jumped back to the starting position of the print. After this the dual X autopark routine was fine. Duplication mode works fine.
• The jerking movement persists exactly like in RC7.

Marlin-rc_dualx_homing

READ: x_min: open
READ: x_max: open
READ: y_min: open
READ: z_min: open
READ: z2_min: open

• All axes homing works fine, dual z endstop homing is correct.
• Jerking persists
• Auto park function has issues.
  • Printing starts normally, all axes home, then X1 and Y moves to position, then Z goes away from home position to an insane amount then back rapidly. After some normal print moves follow then the X1 carriage moves to parking position, and X2 moves in to start print moves, But the Z axes go for a trip again, and this repeats at every tool change.
• Duplication mode works fine.

[thinkyhead]

As for the jerking… What are you using for your micro-steps? You probably are hitting limits if using 0.9° steppers with 16x or 32x micro-stepping. I've seen this also. The number of steps-per-second just goes too high for the 16MHz CPU to keep up. You will have to set your max speeds to something below where jerking begins to occur.

If you want to use faster movement, you will have to reduce the number of micro-steps by moving the micro-stepping jumpers on your board. The steppers will resonate more, but you will be able to reach your desired speed.

[thinkyhead]

So, it sounds like everything works with this PR, except on tool-change (in auto-park mode) you see weird Z movements. I can work with that.

[thinkyhead]

@dp90pusika Hmm… I wonder if this could be the problem. 😜 I seem to have a typo here!

i == 2 ? current_position[Y_AXIS] : raised_parked_position[Z_AXIS],

…should be…

i == 2 ? current_position[Z_AXIS] : raised_parked_position[Z_AXIS],

[thinkyhead]

@dp90pusika OK! I patched the bug that was probably causing the Z axes to go nuts. Give my branch another test and (fingers crossed) it should be better than before.

I'm especially glad to hear that duplication mode is fixed by this PR.

[AndrewDiehl]

With the latest RCBugFix
Duplication Mode Works (as far as I can tell tonight)

Auto Park Kind of Works!

• T0 will always move to the X2 min position if I try to move to any value less than that position.
• Z still crashes with the toolchange lift if the printer is already at max z height)

Full Control Works!

• However, T0 or T1 command should never move the heads, issuing the T0, T1 should function as the T1 S1 and T0 S1 currently do for this mode. As it stands now, issuing a T0 or T1 will always crash the head)

[thinkyhead]

@AndrewDiehl How about the branch https://github.com/thinkyhead/Marlin/tree/rc_dualx_homing ?

(I haven't merged this PR into RCBugFix yet.)

[AndrewDiehl]

@thinkyhead for the rc_dualx_homing:

Full control seems to be 100% working as desired.

Autopark correctly respects Z max settings now, but otherwise has issues.

• X still moves past the X2_min distance,
• When changing from T0 to T1, the T1 head attempts to move the X2_min distance past the Max_X2, crashing the head. When a M114 is issued after the crash, it indicates X=X2_min distance, and cannot be jogged in the correct direction (-X)

Copy mode appears to work perfectly.

[thinkyhead]

X still moves past the X2_min distance

Under what circumstances?

[thinkyhead]

When changing from T0 to T1, the T1 head attempts…

So, for example, if T0 is sitting near the left side before it parks, when T1 tries to move to where T0 used to be, it runs into the T0 carriage?

[thinkyhead]

…attempts to move the X2_min distance past the Max_X2, crashing the head…

Or… It tries to move in the wrong direction, to the right, and past the right endstop?

[AndrewDiehl]

@thinkyhead Whenever any move is issued. If my X2_min is 50, and I issue a T0, G1 X3 (or any command less than 50) The T0 head will move to 50. Once at 50, issuing any G1 X command less than 50 has no effect.

[thinkyhead]

If my my X2_min is 50, and I issue a T0

Do you mean, if you issue a T0 before ever issuing a T1, or doing anything else?

[AndrewDiehl]

Or… It tries to move in the wrong direction, to the right, and past the right endstop?

It tries to move in the wrong direction past the right endstop.

[thinkyhead]

@dp90pusika indicated that the tool change in AUTO_PARK mode was working properly for the most part in both RC6 and RC7. I'll use those as a basis for comparison to make sure the code is following the same logic. Hopefully I will spot the difference and have a patch today.

[AndrewDiehl]

Correct, just using T0 commands.

[thinkyhead]

Merged because it's better than it was!

If further changes are needed let me know and I will get them in as fast as I can.

[dp90pusika]

Are you saying here that when the new toolhead moves into position, it is not matching up to the X location of the previous toolhead?

Everything is fine with S1 and S0, the coordinates match up. When using S0, after a toolchange the x positions are lining up.
What I'm saying that from a practical stand the S1 makes more sense. When a toolchange is issued the old toolhead moves to the parking position. and the new tool only moves when it gets the next G1. That makes sense because if example I'm using two colors I don't want the new head to atomaticali move to the cordinates where the old toolhead was. That would mean some unvanted cross smearing.

So if a tool change is issued the old tool head parks, and the new tool head only moves when it gets it's G1 X Y cordinates and moves to that position and starts printing. this is the correct way and this is what S1 is dooing, so it's perfectly fine okey.

For S0 ther is probably some practical use, it is good to have an option in there.

If further changes are needed

• just now I had an issue:
  after a successful duplication print I homed all axes, and sent G1 Z10.000 F600 to lower the bed. The T1 toolhead moved towards the build area (-x) and the controller froze, not responding to the M105 and anithing else. Had to do a reconnect.

• toolheads can move toward their end stops after homing despite the soft endstops enabled, this goes also for Y, so this problem lies maybe somewhere else.

• after several tool change command from the control panel in s0 mode, (the X coordinate was about X340) the controller froze. I changed tool heads at least 10 times when the firmware got unresponsive in the middle of a long move with the new toolhead.

• After a restart if I don't home all axes, just the X axis, then the toolhead change starts in the S1 mode. And doesn't change if I issue a T0 S0 or T1 S0.

• after a restart and hemeing all axes, but not taking any moves with X0 or X1 just issuing a tool change makes the new toolhead crash into the other parking toolhead. (this only happens in S0 then not using S command after T command, if sending T0-1 S1 this doesn't happen)

None of these issues are deal breakers, the 2-3 test prints I made in autopark and duplication mode went through normally. These scenarios doesn't really come up in a normal g-code

[thinkyhead]

We'll have to continue to refine. There are a lot of "states" that Dual X depends on, and they are hard to keep track of. Your detailed notes are very helpful.

[dp90pusika]

Thank you but I feel like I could do better.

You wont be happy about this, but
right now I'm trying to implement an X mirroring mode, like in the Leapfrog Bolt.

As I understand, after the X2 went to the right position, it needs to invert X2_DIR_WRITE and it should be good. But this is a bit complex for me, I run into compiling problems with every try.

[ghost]

mirroring mode... It might be useful.
If object is symmetrical, If you use two carriages to print half at a time,
printing can be completed in half the time compared with printing one object with one carriage.
(However it's necessary to paste two printed materials together)

Oh, I've wanted a dual carriage machine very much for the first time.

[dp90pusika]

A startup contacted me asking if I could make them a machine, they want to print custom orthopedic shoe insoles. So with a mirroring mode they could print a pair in one go. So the idea comes from this.

[ghost]

I see, mirror mode is indeed practical.
By the way, this fork of Marlin seems to has mirror mode (but it looks like that it's a old fork).
https://github.com/dob71/MarlinX2

[JohnOCFII]

With the developers fighting to save memory and performance in Marlin firmware, wouldn't mirror mode be a better feature for a slicer? I know Simplify3D has a mirror mode.

[AndrewDiehl]

You can't do a mirror mode in a slicer, as slicers have no way to simultaneously control 2 separate heads. Must be done in firmware. Also I second its usefulness.

[dp90pusika]

I use simplify3d and know about the mirror function, but that is quite different from what we are talking about.
If you mirr a model in the slicer and configure the settings to make on with T0 and the other one with T1 then the printer can only print one at a time than a toolchange and the other one. The slicer has no functionality to handle the coordinate calculation for the mirrored object, and also the buffer probably doesn't like the idea of changing toolhead after every G1 command.

[JohnOCFII]

I use simplify3d and know about the mirror function, but that is quite different from what we are talking about.

Thank you for explaining the difference.

[thinkyhead]

As I understand, after the X2 went to the right position, it needs to invert X2_DIR_WRITE and it should be good.

That approach will work, once the X2 is positioned appropriately. But I think it would also make sense to do this at a higher level, like duplication mode. That way it's easier to keep track of the carriage positions.

Anyway, to do it at the stepper level — in stepper_indirection.h…

NEVERMIND — WRONG CODE

I presume it's a sub-option of DUAL_NOZZLE_DUPLICATION_MODE.

(You could also use extruder_mirror_mode ^ (!INVERT_E1_DIR) in place of extruder_mirror_mode ? INVERT_E1_DIR : !INVERT_E1_DIR.)

[dp90pusika]

I will try it out, thanks.
I was experimenting just now, trying to copy all the duplication_mode lines and renaming them to DXC_MIRROR_MODE and so on.
Also setting up new duplication_x_offset, and things like this, but realized that all of this is unnecessary, because of the two toolheads are both moving toward each other, just need to invert the T1 dir and limit the T0 to a max position in the middle of the build volume. this way the the two toolheads can mirrore every movement, no need to set up them in the rigt position like in the duplication mode.

The only problem is that The finals are here and I really should study, but this is more interesting than my exams. :D

[Blue-Marlin]

want to print custom orthopedic shoe insoles. So with a mirroring mode they could print a pair in one go.

Stay away from them. If they want to make orthopaedic soles and don't know about right and left foot are different - they will probably not have much success.

[thinkyhead]

a max position in the middle of the build volume

They can't go all the way to the center or they'll collide. So I think we should add a new define — the minimum distance that must be maintained between the two tool-heads — then we can limit just how close to one another, and to the middle, they can go without colliding. Something like…

#define DUAL_X_MIN_SAFE_DISTANCE 20

[dp90pusika]

@Blue-Marlin
It was the first thing that came to mind for me also.
The've probably never used a 3d printer.
Anyway, probably it's very rare that this mirroring mode will be useful, but if the machine is mechanically capable of doing it, than it is good to have an option for it.

[dp90pusika]

I managed to squeeze out a mirroring run of my machine, but clearly I have no idea what I'm doing:

https://youtu.be/s7T6y_XfM3U

It started fine but went wrong somewhere halfway, not sure if an unexpected g-code line or a communication error, or a power drop. (Those things happen here :/ )
Need to test it again.
This was in Duplicate mode, and the only changes to the script were the following:
in stepper.cpp

#if ENABLED(X_DUAL_STEPPER_DRIVERS)
  #define X_APPLY_DIR(v,Q) do{ X_DIR_WRITE(v); X2_DIR_WRITE((v) != INVERT_X2_VS_X_DIR); }while(0)
  #define X_APPLY_DIR(v,Q) do{ X_DIR_WRITE(v); X2_DIR_WRITE((v) != !INVERT_X2_VS_X_DIR); }while(0)
    #define X_APPLY_STEP(v,Q) do{ X_STEP_WRITE(v); X2_STEP_WRITE(v); }while(0)
#elif ENABLED(DUAL_X_CARRIAGE)
  #define X_APPLY_DIR(v,ALWAYS) \
    if (extruder_duplication_enabled ) { \
      X_DIR_WRITE(v); \
      X2_DIR_WRITE(!v); \
    } \

and I set the #define DEFAULT_DUPLICATION_X_OFFSET to X2_MAX_POS

I started the print in duplication mode and you can see on the video how it worked.

In the stepper.cpp I can't get a choosing script implemented, to switch between duplication and mirror mode. Everything I try makes a compiler error, clearly I'm a noob.

Can one of you guys help me please?

[ghost]

Perhaps like this? (probably wrong)
https://github.com/esenapaj/Marlin/commit/6a5bcfd631d9f6543fff740c0fab4377ab826e16
https://github.com/esenapaj/Marlin/commit/21839a7d0f70a810d32f8821da807b6a1cd287f9
https://github.com/esenapaj/Marlin/tree/Duo-mirroring-test

[dp90pusika]

@esenapaj almost okay I think
what it needs is something like this, but this script won't compile

#if ENABLED(X_DUAL_STEPPER_DRIVERS)
  #if ENABLED(DUAL_NOZZLE_MIRROR_MODE)
    #define X_APPLY_DIR(v,Q) do{ X_DIR_WRITE(v); X2_DIR_WRITE((v) != !INVERT_X2_VS_X_DIR); }while(0)
  #else
    #define X_APPLY_DIR(v,Q) do{ X_DIR_WRITE(v); X2_DIR_WRITE((v) != INVERT_X2_VS_X_DIR); }while(0)
  #endif
  #define X_APPLY_STEP(v,Q) do{ X_STEP_WRITE(v); X2_STEP_WRITE(v); }while(0)
#elif ENABLED(DUAL_NOZZLE_MIRROR_MODE)
 #define X_APPLY_DIR(v,ALWAYS) \
    if (extruder_mirror_enabled || ALWAYS) { \
      X_DIR_WRITE(v); \
      X2_DIR_WRITE(!v); \
    } \
#elif ENABLED(DUAL_X_CARRIAGE)
  #define X_APPLY_DIR(v,ALWAYS) \
    if (extruder_duplication_enabled || ALWAYS) { \
      X_DIR_WRITE(v); \
      X2_DIR_WRITE(v); \
    } \
    else { \
      if (current_block->active_extruder) X2_DIR_WRITE(v); else X_DIR_WRITE(v); \
    }

[ghost]

Like this?
https://github.com/esenapaj/Marlin/commit/926274a88747cd9df2827f7ff0d4a244ee0c10c9
https://github.com/esenapaj/Marlin/tree/Duo-mirroring-test

And about your code,

#elif ENABLED(DUAL_NOZZLE_MIRROR_MODE)
 #define X_APPLY_DIR(v,ALWAYS) \
    if (extruder_mirror_enabled || ALWAYS) { \ // <--------- "extruder_mirror_enabled" doesn't exists, maybe it means "extruder_mirror_mode"?
      X_DIR_WRITE(v); \
      X2_DIR_WRITE(!v); \
    } \ // <--------- At end of macro, "\" needs to be removed
#elif ENABLED(DUAL_X_CARRIAGE)

[dp90pusika]

This looks promising, successfully compiled this way.

if (extruder_mirror_enabled || ALWAYS) { \ // <--------- "extruder_mirror_enabled" doesn't exists, maybe it means "extruder_mirror_mode"?

you are right, that was a mistake from me.
Now I need some time to test it because I started a longer print.

(had a warning in SanityCheck.h:
// #elif ENABLED(DUAL_X_CARRIAGE)
// #error "DUAL_NOZZLE_DUPLICATION_MODE is incompatible with DUAL_X_CARRIAGE."
I commented it out for now to suppress it.
Dual_nozzle_duplication_mode is not defined but this came up)

[ghost]

Well, mirroring mode has compatibility with DUAL_X_CARRIAGE?
I'm not sure what is compatibility and necessary condition of mirroring mode (with DUAL_X_CARRIAGE, DUAL_NOZZLE_DUPLICATION_MODE, X_DUAL_STEPPER_DRIVERS, and etc?).

[dp90pusika]

basically when I forced the printer to do the mirroring, I used DUAL_X_CARRIAGE in DXC_DUPLICATION_MODE
so it works as if it is in duplication mode, but the second head moves in reverse on the x axes

DUAL_NOZZLE_DUPLICATION_MODE disabled <-- this is for conventional dual extruder machines, not used on a dualx carriage machine.
X_DUAL_STEPPER_DRIVERS disabled <--this is for having two motors moving the same x carriage, I guess for more torque

[ghost]

Ah... maybe...
X_DUAL_STEPPER_DRIVERS ... independently controlled (but always consistent) dual motor for x axis
DUAL_X_CARRIAGE ... dual carriage
DXC_DUPLICATION_MODE ... duplication mode with dual carriage
DUAL_NOZZLE_DUPLICATION_MODE ... duplication mode with single carriage, dual nozzle

If so,
DUAL_NOZZLE_MIRROR_MODE should be defined as a mirroring mode with single carriage, dual nozzle (but it is absolutely impossible).
Then, mirroring mode with dual carriage should be defined as a DXC_MIRROR_MODE , as you said...

[ghost]

I've rewritten.
DUAL_NOZZLE_MIRROR_MODE has been removed, and DXC_MIRROR_MODE can be used.
https://github.com/esenapaj/Marlin/commit/83687632557cf3badca6113d6e8fdb9bb619f970
https://github.com/esenapaj/Marlin/tree/Duo-mirroring-test
Sorry it's completely broken currently.

But I've begun to care, is

  #if ENABLED(DUAL_X_CARRIAGE) || ENABLED(DUAL_NOZZLE_DUPLICATION_MODE)
    #define E_STEP_WRITE(v) { if (extruder_duplication_enabled) { E0_STEP_WRITE(v); E1_STEP_WRITE(v); } else if (current_block->active_extruder == 0) { E0_STEP_WRITE(v); } else { E1_STEP_WRITE(v); } }
    #if ENABLED(DXC_MIRROR_MODE)
      #define NORM_E_DIR() { if (extruder_duplication_enabled) { E0_DIR_WRITE(!INVERT_E0_DIR); E1_DIR_WRITE(INVERT_E1_DIR); } else if (current_block->active_extruder == 0) { E0_DIR_WRITE(!INVERT_E0_DIR); } else { E1_DIR_WRITE(!INVERT_E1_DIR); } }
      #define REV_E_DIR() { if (extruder_duplication_enabled) { E0_DIR_WRITE(INVERT_E0_DIR); E1_DIR_WRITE(!INVERT_E1_DIR); } else if (current_block->active_extruder == 0) { E0_DIR_WRITE(INVERT_E0_DIR); } else { E1_DIR_WRITE(INVERT_E1_DIR); } }
    #else
      #define NORM_E_DIR() { if (extruder_duplication_enabled) { E0_DIR_WRITE(!INVERT_E0_DIR); E1_DIR_WRITE(!INVERT_E1_DIR); } else if (current_block->active_extruder == 0) { E0_DIR_WRITE(!INVERT_E0_DIR); } else { E1_DIR_WRITE(!INVERT_E1_DIR); } }
      #define REV_E_DIR() { if (extruder_duplication_enabled) { E0_DIR_WRITE(INVERT_E0_DIR); E1_DIR_WRITE(INVERT_E1_DIR); } else if (current_block->active_extruder == 0) { E0_DIR_WRITE(INVERT_E0_DIR); } else { E1_DIR_WRITE(INVERT_E1_DIR); } }
    #endif
  #else

needed?
Because it seems unrelated to mirroring mode whether to invert E direction.

[dp90pusika]

@esenapaj Good point,
the extruders should go in the usual direction, there is no need for inverting it. If in mirror mode the E direction is inverted, that would mean that one of the extruders are retracting while the other one is extrudeing.

[ghost]

I've rewritten and cleanup again.
This time it's okay. ...maybe.
DUAL_NOZZLE_MIRROR_MODE has been removed, and #define DEFAULT_DUAL_X_CARRIAGE_MODE DXC_MIRROR_MODE can be used.
https://github.com/esenapaj/Marlin/commit/ead4b2ac083c2759afa8c2607568fdb574ca33a1
https://github.com/esenapaj/Marlin/commit/6c0d6fbb724001730e6d221c6a2a59f758d5fdc8
https://github.com/esenapaj/Marlin/tree/Duo-mirroring-test

[thinkyhead]

Because it seems unrelated to mirroring mode whether to invert E direction.

Sorry, meant to apply it to X2 direction, obviously. It was very late.

[ghost]

@dp90pusika @thinkyhead

The heads, don't respect the max positions, and also can move to negative positions and crash into the endstops, on homing the heads crash into their endstops.

In addition to doing more testing with DEBUG_LEVELING_FEATURE enabled (M111 S247), please use M211 to get a report of the positions of software endstops after switching tools.

I tested the code and got these results:
soft endstops are enabled:

#define min_software_endstops true // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true  // If true, axis won't move to coordinates greater than the defined lengths below.

and I got these after sending M211:

• after startup:
  Soft endstops: Off Min: X0.00 Y0.00 Z0.00 Max: X500.00 Y500.00 Z500.00
• after restart issuing G1 to X1 whitout homing:
  Soft endstops: Off Min: X0.00 Y0.00 Z0.00 Max: X500.00 Y500.00 Z500.00
• after restart homing X axes:
  Soft endstops: Off Min: X80.00 Y0.00 Z0.00 Max: X433.00 Y500.00 Z500.00
• after restart first command is T1, nothing els:
  Soft endstops: Off Min: X80.00 Y0.00 Z0.00 Max: X433.00 Y500.00 Z500.00

says the software endstops are disabled, but they are clearly enabled in the config.

Sorry about that, It wasn't related to part of the official Marlin.
Software endstop didn't work with my fork even if it was enabled. It was disabled automatically at all times.
Because in case of arduino Due, true and false are defined as follows in wiring_constants.h.

#define true 0x1
#define false 0x0

And, ENABLED() and DISABLED of Marlin are defined as follows in macros.h.

// Macros to support option testing
#define _CAT(a, ...) a ## __VA_ARGS__
#define SWITCH_ENABLED_false 0
#define SWITCH_ENABLED_true  1
#define SWITCH_ENABLED_0     0
#define SWITCH_ENABLED_1     1
#define SWITCH_ENABLED_      1
#define ENABLED(b) _CAT(SWITCH_ENABLED_, b)
#define DISABLED(b) (!_CAT(SWITCH_ENABLED_, b))

Then , ENABLED(min_software_endstops) macro was expanded to SWITCH_ENABLED_0x1 or SWITCH_ENABLED_0x0.
Those weren't defined but compiler didn't caused error.
As a result, however, these undefined macros seemed to function as false.
Of course, many other macros were also forced to false.

List:

Z_MIN_PROBE_ENDSTOP_INVERTING
DISABLE_X
DISABLE_Y
DISABLE_Z
DISABLE_E
DISABLE_INACTIVE_EXTRUDER
DISABLE_INACTIVE_X
DISABLE_INACTIVE_Y
DISABLE_INACTIVE_Z
DISABLE_INACTIVE_E

But now it has been fixed.