DerAndere1 / contact_DerAndere1

Create an issue to communicate with DerAndere1 (DerAndere)
0 stars 0 forks source link

bugfix bf2_E_Homing_branch #2

Closed rnj1 closed 4 years ago

rnj1 commented 4 years ago

Hi DerAndere1,

I compiled your latest bf2_E_Homing Branch and fixed all the (like 20) typos preventing me from doing so.

I didn't test it yet, but in case you're interested I send you my files...

Best Regards

RNJ1

rnj1 commented 4 years ago

Here the ZIP file https://drive.switch.ch/index.php/s/Zabmjw3SLamTM09

rnj1 commented 4 years ago

The only thing I didn't bother fixing and commented was this (in src/Gcode/geomtry/M206_M428.cpp): void GcodeSuite::M428() { //if (axis_unhomed_error()) return; ---------->caused an error due to incorrect call

float diff[LINEAR_AXES];

if ENABLED(E_AXIS_HOMING)

LOOP_XYZE(i) {

else

    LOOP_XYZ(i) {

endif

rnj1 commented 4 years ago

Hi, I had to disable "PREVENT_LENGTHLY_EXTRUDES" and then it actually worked. Also I made a minor change to enable individual axis homing (e.g. G28 E). Btw. I can also confirm that this branch is working with DUAL Z Drivers and Dual Z Endstop Homing. Here the updated link (I deleted the old one): https://drive.switch.ch/index.php/s/11ZzDU2zL6mJdGj

DerAndere1 commented 4 years ago

Hi @rnj1, sorry I missed your comments. I am happy that you made it work for your machine. Thanks for sharing. In fact I have many E homing branches and right now I do not have the time to test which one works. Also I am sorry to say that I can currently not test in hardware (rarely at home, no suitable test hardware). I once openend a PR in upstream MarlinFirmware with a working E_homing branch but it was not merged (not the optimal solution to the problem and not nice to maintain upstream). The only E_HOMING branch I still use is Marlin2ForPipetBot. We are currrently working on support for up to 6 axes plus extruders (XYZIJK+ E). There is currently a working version based on Marlin-bugfix2.0.x (forked 8 months before the release of 2.0.0). You can read about the status in the last comment of https://github.com/DerAndere1/Marlin/issues/1. You are invited to test/add support dual-z drives and give feedback. I will upload a slightly polished version in some days and inform you.

DerAndere1 commented 4 years ago

My new branch https://github.com/DerAndere1/Marlin/tree/bf2_6axis_dev11 Compiles with default config, should add support for axes X,Y,Z,I,J,K which can be auto-homed with G28 plus optional regular extruders.

rnj1 commented 4 years ago

Thanks for your response! I had a look into your 6axis branch before too, but droped it as it didn't compile with dualZ drivers & endstops (maybe I should have fixed this instead). In the bf2_E_Homing_branch version there was also an issue about not saving the E-position of the inactive tool (which probably still exists in the official marlin 2.0 branch). I quickly fixed that too as well as report positions (M114) with X: Y: Z: E0: E1: ... E5:. If you want I can provide this too. One bug I found was if you make a XYZE motion e.g. "G1 X Y Z E" when the XYZ position stays the E-Axis starts stalling sometimes (wrong speed or acceleration). In that case I just send G1 E.. Also E1 cannot move when the endstop for E0 is triggered.. (I just make a small move away from the endstop to avoid it). While your branch, with minor modifications does what I need, it probably makes more sense to have a look into the Reprap Firmware (which we use a lot for the Duet2, and there is also Sourcecode and binaries for Arduino Due (with RADDS) ) or the new Repetier 2.0 (beta) Firmware (which already works with most boards and does support six axis and additional extruders (XYZABCE)...). Best Regards RNJ1

DerAndere1 commented 4 years ago

Yes, please provide your recent results. Fixing 6axis support would have cost you 6 times the time it took you to fix E-homing, so you effectively did everything right. https://github.com/DerAndere1/Marlin/tree/bf2_6axis_dev (which became the new basis of https://github.com/DerAndere1/Marlin/tree/Marlin2ForPipetBot) works for me, but only with minimum features, no dualZ drive.

rnj1 commented 4 years ago

Here with my Addition (store/Restore ExtruderPositions on Toolchange; Report true Positions for all Extruders). It's a .7z (you'll need 7zip) : https://drive.switch.ch/index.php/s/3xEtt1XQjJ1h9Vj

rnj1 commented 4 years ago

Btw. It's a bug that can be fixed very easily. The changes are in motion.c and in toolchange.c (plus headers). With Winmerge you should find them ultra easy... Also it seems that steppers.report_position (normally active with "M114 D" for Detail) does take the float value in mm to calculate steps --> nonsense

DerAndere1 commented 4 years ago

Thanks. I got a copy of your code and may update my code when I find the time. If you have extra time during the COVID-19 crisis, I recommend learning about the use of forks with the "github desktop" app.

rnj1 commented 4 years ago

the old Marlin bugfix_E-Homing had some serious bugs (like every now and then it does move to an undefined position when moving four axis simulteneously. I already adapted the most recent Marlin 2.0.5.2 to an E-Homing Version. It's tested and works with DualZ Motors & Endstops. I didn't get the endstop interrupts feature working (which does work in the previous version I provided), but since it works with the (default) endstops polling and I don't have time to work on this, I didn't further investigate.I also made a small modification to have the homing speeds on quick_home the same for X and Y (normally homing speeds are related to the difference in axis stroke). Here is my current version: https://drive.switch.ch/index.php/s/5EMV7gTKXcXatVl

I also made a small modification to have the homing speeds on quick_home the same for X and Y (normally homing speeds are related to the difference in axis stroke). If I had to do this again, I would rather go for a simple hack to just independently define pins, limits and homing directions for all E-Axes in new variables, add the E-Axis endstop pins to endstops event handler (just with polling would be fine) and modify the G28.cpp with a function to home any extruder individually, one at a time. This would probably take about 4-6 hours of work to implement (about the same time I spent with applying your modification)... Also thanks for the suggestion with github desktop forks. Right now I'm like suuuper busy and will not take the time to make my own fork, but maybe in the future.

DerAndere1 commented 4 years ago

Since there is ongoing interest in the E_AXIS_HOMING feature, I took your code as a reference to create the new 2.0.x_E_homing branch. Here are some fixes to your code: https://github.com/DerAndere1/Marlin/commit/33a7d78f4de5cc628ba96e2471ac9de8770afb45 and https://github.com/DerAndere1/Marlin/commit/b93d3223e5b0c606f05d5df7d384c0d0741d46e3.