COREXY Archim2 Movement Direction Issues

[ghost]

Bug Description

Replaced Rambo1.3L in a CoreXY printer with an Archim2 and started to prepare Marlin. Printer worked great before, but now the motion of the axes is wrong. The printer moves in positive Y direction and negative x direction only.

Attempting a positive y or positive x move: moves in the positive y direction.
Attempting a negative y or negative x move: moves in the negative x direction.
If I try to home X, it will home but once the endstop is triggered

All other features on the printer work great. Hot ends temperature and sensors, LCD displays properly and all selected features show up, Z axis moves and homes well, endstops are wired correctly and trigger appropriately using M119.

My Configurations

Marlin.zip

Steps to Reproduce

1. Download Marlin 2.0 bugfix.
2. Setup for Archim2, CoreXY, and TMC2130 drivers.
3. Flash to motherboard
4. Attempt to move printer with LCD menu, or Pronterface, or Arduino Serial Monitor

Expected behavior: Printer moves in x direction for x positive and negative moves, in y direction for positive and negative y moves.

Actual behavior: Printer moves in Y positive direction for x positive and y positive moves, in x negative direction for x negative and y negative moves.

Additional Information

• Printer was run on Marlin 1.1.9 with a Rambo 1.3L with the same configuration of nearly all settings and ran excellent. No motion issues under that setup.
• Belts are tight, with steppers off all axes move smoothly with no stuck points.

[BeatSlayer]

To me it really seems that you've just inverted your motors.

[ghost]

I've attempted to switch the connectors on all motors, and it just switches the two directions the printer will move. X+ and Y+ move in one direction, X- and Y- move in another.

[ghost]

Here is a video showing the weird behavior.

[BeatSlayer]

I mean inverted like at the configs like:

#define INVERT_X_DIR true
#define INVERT_Y_DIR true

[ghost]

I've attempted inverting X and Y in all combinations in the configuration, still the same behaviour, just in different directions. In Positive X and Positive Y, or Negative X and Positive Y, or Positive X and Negative Y.

[teemuatlut]

You need to find the right combination with COREXY or COREYX, switching the directions and switching the pins and plugs. It can get a bit tedious. I'm using an Archimajor board on a CoreXY build and it's working just fine.

[ghost]

Okay well that's great to hear that it can work. Thank you both for your help. You saw the video showing the weird behaviour right? Have you ever seen Marlin do that before?

With a Rambo 1.3L and Marlin 1.1.9 it all worked out just peachy keen, but this Archim2 board is giving me a whole lot more trouble.

[colinoflynn]

I've also run into this, I can confirm it appears to be a firmware bug. You can swap around the the pins in pins_ARCHIM2.h to use the E0/E1 driver chips, and same thing happens, it always moves in one direction only (no matter which driver chip I use).

More investigation has yielded the fact that the pin associated with Y_DIR is never actually set as an output in the low-level PIOC->OER register. That is, bit 11 (Y_DIR is PIOC11) appears never to be set by the init code. Setting PIOC->OER, bit 11 to 'high' immediately makes the Y direction work (i.e., moves in both directions as expected) without any other changes required.

Most likely: Y_DIR_PIN (along with E0_DIR_PIN and others I tried) is an 'extended' pin set, and isn't the standard Arduino pin number for the DUE. See https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/pins/sam/pins_ARCHIM2.h#L120 - note this is pin 92, which is beyond the normal pin number for the DUE. The other axis are in the 'standard' pin numbering, so they work as expected. There is a different definition of the g_APinDescription required is my understanding.

During build, I see a reference to this:
.pio\build\DUE_archim\libFrameworkArduinoVariant.a(variant.cpp.o):(.rodata.g_APinDescription+0x0):

Where is the g_APinDescription structure defined? It contains the pin output settings, I'm assuming that default (inputs) are being used by these, as the incorrect variant.cpp has been compiled for the ARCHIM2. I'm new to Marlin's build so haven't found the variant.cpp source as part of building that library. I suspect therein lies the answer...

[colinoflynn]

Ah - I understand now the Archim2 variant is at https://github.com/ultimachine/ArchimAddons/tree/master/variants/archim (which is included in an Arduino build I think), not sure how this gets pulled in with PlatformIO.

[ghost]

Hey Colin, thanks for looking into this! Great to hear that you found that temporary work around and the likely root cause of the problem.

I initially had problems uploading Marlin at all to the Archim2 using PlatformIO, and used the extra script line fix in the issue you linked to fix it, as well as setting the platform in platformio.ini to dueUSB. I've looked for Archim support in PlatformIO and there isn't any as of yet to my knowledge. If it's not setting the Y_DIR pin to the proper output that would make sense, as everything else on the board seems to work without issue.

To go about fixing this issue how can I help? I've flashed marlin a number of times but have done very little in the realm of changing code other than configuration.h, configuration_adv.h, and various pins files.

[ghost]

After some quick searching, editing the variant.cpp in the platformIO environment files, and defining pin 92, I can confirm that Colin's fix is in fact the solution.

Looks like not a Marlin bug, but the use of the due environment instead of an actual Archim environment that caused the problem. The problem is that Arduino won't compile

Adding a pin definition for pin 92, that is PIOC11, into variant.cpp immediately fixed my problem. Both directions on x and y work as expected.

[colinoflynn]

Thanks for checking - I didn't actually do the build with the changes in the files. Where is the variant.cpp actually in your environment (I didn't find it in my build)? Unfortunately I'm in the same boat as you w.r.t. knowledge about how to get a non-hacky fix, so I can't give a nice PR with a clean solution to close this off either.

[ghost]

The variant wasn't in the anywhere in the Marlin folder, but in the .platformio folder in the root of the user home folder. I think the exact path is ~/.platformio/penv/due. I'm not at my work PC anymore but it's somewhere around there.

[colinoflynn]

OK thanks - that lead me to the files too (for ref, building on Windows, C:\Users\<username>\.platformio\packages\framework-arduino-sam\variants\arduino_due_x is the magic).

[colinoflynn]

The more correct fix:

In the platformio.ini file, add the board_build.variant = archim to common_DUE_archim:

[common_DUE_archim]
platform      = atmelsam
extends       = env:DUE
build_flags   = ${common.build_flags}
  -DARDUINO_SAM_ARCHIM -DARDUINO_ARCH_SAM -D__SAM3X8E__ -DUSBCON
extra_scripts = ${common.extra_scripts}
  Marlin/src/HAL/DUE/upload_extra_script.py
board_build.variant  = archim

If you do this & build you should get errors (this is good - it's now expecting a variant that isn't there). Then you need to:

1. Download the archim-1.6.9 BSP.
2. From that size, extract the folder archim\variants\archim to C:\Users\<username>\.platformio\packages\framework-arduino-sam\variants\ (nb - don't dump the root archim folder there, you should have the internal archim folder as a variant now).
3. Re-run build and check it passes.

I can submit a PR for the platformio.ini file, but I think this will cause automated build checkers to fail. I assume there is a way to tell platformio about the variant?

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[colinoflynn]

Bump - keeping issue alive as it's been validated & has known fix. I'm still unclear on how platform.io/marlin2 build integration works such that the fix can be "correctly" included.

[ghost]

Yep, the fix works and leads to successful compiles and flashes. As Colin said, not sure how to get this to be a proper fix and not a workaround.

[ellensp]

This looks like it already been done. Its in current release marlin 2.0.7.2, Its been there since 2.0.7.1

[common_DUE_archim]
platform      = atmelsam
extends       = env:DUE
board         = archim
build_flags   = ${common.build_flags}
  -DARDUINO_SAM_ARCHIM -DARDUINO_ARCH_SAM -D__SAM3X8E__ -DUSBCON
board_build.variants_dir = buildroot/share/PlatformIO/variants/
extra_scripts = ${common.extra_scripts}
  Marlin/src/HAL/DUE/upload_extra_script.py

The line board_build.variants_dir = buildroot/share/PlatformIO/variants/ points to a copy of the variant files within marlin directory structure

[colinoflynn]

Looks like PR #19596 included the fixes -- that pr includes the build system changes, not sure if the timing change mattered for that. Nice catch on it being fixed elsewhere!

EDIT - ok to close, but probably should recompile from scratch and confirm first it fixed archim2 fully from release. Will be a bit before I can do that as don't have HW with me, at worst can check next week. As it would compile successfully before, needs a hardware test to 100% confirm IMHO. If someone else confirms please let us know.

[thisiskeithb]

EDIT - ok to close, but probably should recompile from scratch and confirm first it fixed archim2 fully from release

@matthewbrydges: Can you try the latest bugfix-2.0.x and confirm that #19596 resolves this issue?

[sjasonsmith]

I’m closing that as presumed fix, since we haven’t heard testing results.

Please reply if the fix did not work as expected.

[colinoflynn]

I was delayed getting my hardware setup again (testing a new board build, so debugging hardware problems before I could confirm firmware).

Just confirmed yesterday this work greats. Thanks to pr #19596 that I think unknowingly made our lives all easier :)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.