Software stops working on Homing Axe E

[cyberjunkiefr]

Hello,
I'm building a 4 axis Hotwire cutter, using a BBBW with replicape.
I'm using UmiKaze 2.2.1 on the beaglebone:
I've got evrything working except for the homing on driver E.
The Hotwire cutter has 4 independant axes. XY on one side and ZE on the other side each axe has 1 endswitch,:
end_stop_X1_stops =x_neg
end_stop_Y1_stops =y_neg
end_stop_Z1_stops =z_neg
end_stop_X2_stops =e_neg
end_stop_Y2_stops =
end_stop_Z2_stops =

All the 4 axes move in the right direction and at the right speed and the endswitch will stop the axes when activated in negatif direction.
The homing of axes XYZ works perfect, but when I launch the gcode: "G28 E0" then then software wil crash withan error message.

I've tried to figure out what could be wrong I even replaced the E axeis by the H axis but same result.
It looks like the homing of another axe then XYZ will crash the software.

Hereby I'm also sending the octoprint.log files and my redeem configuration.

I'm hoping somebody can help here, finding this bug.
Thanks in advance.

octoprint.log

FoamCutter.txt

Roeland Jaspers

[cyberjunkiefr]

Hello again,
I forgot to mention that after the software crash, I can still acces the BBBW by ssh. but I can't reboot.
I have to power off/on to get to a working state.

Roel Jaspers

[Wackerbarth]

In the "FoamCutter.txt" file, at line 66, there is i# Invert =. But, that may just be an artifact introduced during your transmittal of the information to us.

In any case, we should look at the messages that Redeem logged in the system journal.

journalctl -b -u redeem will provide insight as to why Redeem is dying.

[cyberjunkiefr]

Hi Wackerbarth,
Thanks for your answer.
There is that " i# Invert =" in the config file, I've corrected that.
I don't think that might be the issue because only E and H axes are impacted by the issue.
I'm trying to understand the bug but I'm just starting to take a look into the software, and I've tried to follow he G28 code to see where the hangup could be.
I'll try the correction tomorrow, and let you know what happens I'll also fetch the system journal.
What I was thinking about is that usually (for printers ) only the XY and Z axes are used., even the endstops are called X1,Y1,Z1,X2,Y2 and Z2. You can program any axe on these endstops but still the naming shows the 3 axes principally used.
So it could be that, while the XYZ is properly tested, maybe using 4 axis (or 5) might bug and this would be a bug that will rarely come to the surface due to the fact that the replicape is most used (only?) for printers with no homing on the E and H axes.
To me the replicape is the best hardware I've seen so far, and I would really like to use it for my 4 axis foamcutter and I'm thinking about a 5 axis cnc mill.

Anyway thanks for the help, I'll send you the system journal tomorrow.

Roel Jaspers

PS: it would be interesting to see what happens on a different installation to see what happens if you launch a G28 E0.

[Wackerbarth]

If the printer is doing any motion, then the error in that line very well may not be the issue. But the log is what need. You might even try setting the logging level to debug.

[System]
# DEBUG=10
loglevel =  10

This is more likely the problem ---

[Endstops]
# Which axis should be homed.
has_x = True
has_y = True
has_z = True
has_e = False
has_h = True

Thus E is not an axis which you can home.
You might try G28 H instead.
And we may have an issue when we get a bogus request.

[cyberjunkiefr]

Yesterday I finally had some time to test and take a look at the system log.
I run the homing on XY and Z (no problem) and then run the Homing on E.
As soon as the software crashed I read the system log file to a file to see what happend.

After the Center: ('E': 1000) the file stops and the software is crashed.
I've tried to figure out where the 1000 comes from and why the XYZ had 0.5.

I found this in the default.cfg:

soft_end_stop_min_x = -0.5
soft_end_stop_min_y = -0.5
soft_end_stop_min_z = -0.5
soft_end_stop_min_e = -1000.0
soft_end_stop_min_h = -1000.0
soft_end_stop_min_a = -1000.0
soft_end_stop_min_b = -1000.0
soft_end_stop_min_c = -1000.0

soft_end_stop_max_x = 0.5
soft_end_stop_max_y = 0.5
soft_end_stop_max_z = 0.5
soft_end_stop_max_e = 1000.0
soft_end_stop_max_h = 1000.0
soft_end_stop_max_a = 1000.0
soft_end_stop_max_b = 1000.0
soft_end_stop_max_c = 1000.0

I've adde this to my Local.cfg:

soft_end_stop_min_x = -0.5
soft_end_stop_min_y = -0.5
soft_end_stop_min_z = -0.5
soft_end_stop_min_e = -0.5
soft_end_stop_min_h = -0.5

soft_end_stop_max_x = 0.5
soft_end_stop_max_y = 0.5
soft_end_stop_max_z = 0.5
soft_end_stop_max_e = 0.5
soft_end_stop_max_h = 0.5

This solved the problem and the E and H axis can now be homed.

I still think there's a bug because this configuration crashes the whole system.

Thanks Wackerbarth for your help, you've put me on the right track to figure it out by my self

Roel

Ps: I still don't understand why these soft end stops are like that.
In my case the X and Z axes go from 0 to 1100 mm, so I would set min to - 0.5 and max to 1080mm.
But when I do that the software crashes.

[goeland86]

That's an interesting problem... Can you clarify what you mean when you say that E and H can be homed but the configuration crashes the whole system? I'm a little bit confused by that aspect.

[Wackerbarth]

What are the units of "soft_end_stop_max_x"? I suspect that, although most users expect mm, they are in meters. Thus "0.5" is still larger than most printers and "1000" would be a kilometer.

If that is the case, then I'm not surprised that things crash, or at least appear to do so.

In any case, we need to detect motion that would take an impossibly long time.

[cyberjunkiefr]

Hello,
Actually in the default.cfg the min/max soft end stops are set to -1000/1000 ( I found out that those where in meters).
In my local.cfg I've changed that configured the E axis to " must be homed" and I've also connected a physical endstop to e_neg.
Then will homing the software crashes and the last line in the log is: " Center: {'E': 1000}".
When I say crash I mean CRASH, no restart or reboot from octoprint possible (communication error) and from SSH I can still communicate, read files etc buto a sudo reboot doesn't work and gets stuck.
I'm not home this week but I you want next week I can go back to the faulty configuration and get you the systemd log.
By the way when I do G28 Enter the software is blocked right away there's no movement I can only hear the stepper being enabled.

Roel