Homing confusing
Hi,
I had some problems with homing, which were clearly wrong settings: https://forum.repetier.com/discussion/8066/homing-not-working-as-expected-does-not-stop#latest
Now I changed my board due to a broken E1-port. it is now Rumba32 1.1B from youprint3D. I connected everything in the same way. I downlaoded the latest firmware from github and replaced the confi-files with my old ones. After installing the firmware I uploaded a copy of the EEPROM using repetier host.
Now I changed my board due to a broken E1-port. it is now Rumba32 1.1B from youprint3D. I connected everything in the same way. I downlaoded the latest firmware from github and replaced the confi-files with my old ones. After installing the firmware I uploaded a copy of the EEPROM using repetier host.
Side comment: I noticed, that the value of "bed 1 decouple time" was not replaced by the stored value from the harddisk. The other values were correct.
I have set in my Configuration_io.h :
ENDSTOP_SWITCH_HW(endstopXMin, IOEndstopXMin, X_AXIS, false)
ENDSTOP_NONE(endstopXMax)
ENDSTOP_NONE(endstopYMin)
ENDSTOP_SWITCH_HW(endstopYMax, IOEndstopYMax, Y_AXIS, true)
ENDSTOP_SWITCH_HW(endstopZMax, IOEndstopZMax, Z_AXIS, true)
ENDSTOP_NONE(endstopZMin)
and in configuration.h
#define X_HOME_DIR -1
#define Y_HOME_DIR 1
#define Z_HOME_DIR 1
Home x to minimum
Home y to maximum
Home z to maximum
The priority is
#define X_HOME_PRIORITY 1
#define Y_HOME_PRIORITY 2
#define Z_HOME_PRIORITY 0
I am using Repetier server for testing. Bringing all motors to the endstop-position a M119 respnses:
endstops hit: x_min:H y_max:H z_max:H
And L to all, when I do not hit the endstops. I am sure, that the hardware endstops are connected to the right connectors (-x; +y;+z).
The following lines where done each with a restart of the boa by pressing the hardware reset:
endstops hit: x_min:H y_max:H z_max:H
And L to all, when I do not hit the endstops. I am sure, that the hardware endstops are connected to the right connectors (-x; +y;+z).
The following lines where done each with a restart of the boa by pressing the hardware reset:
When I press home z, it does what it should do.
When I press home y, it does what it should do.
When I press home x, it nearly does what it should do. It moves to far, although the speed is low enough. But it stops after maybe 250ms or 500ms (it is hard to guess).
The following lines where done each with a restart of the boa by pressing the hardware reset:
When I press home z, it does what it should do. When I press it a second time, it does what it should do.
When I press home y, it does what it should do. When I press it a second time, it does what it should do.When I press home x, it nearly does what it should do (see above). When I press it a second time, it always moves towards negative values as expected, but it does not stop, when it hits the endstop. It is moving for several seconds till homing stops without result.
I thought that maybe the connection to the end stop is not well, therefore renewed it. In addition I removed the capacitor which had reduced the noise for the older version. Because there is a noise-filter built in int the board, I think it made sense to remove that. That did not help.
I was not able to test the homing with all three axis before. So I CANNOT say that this happens just because of the change of the board.
I somehow have the feeling, that there might be something with the order of the homing. Is it possible, that after the homing with the highest value in the priority something is switched off?
Comments
I understand where I was misleading. I wanted to say it stops 250-500ms AFTER it reached the end stop.
But if it stops on it's own shortly afterwards it would mean it actually saw the end stop just delayed. But being hardware endstop it gets pushed in the microsecond it triggers. Or at least it should happen. SO first to check is if there is a delay in detecting the trigger. There is a debug mode for this (value 64) so send
M111 S70
and you should see in console every triggering of an end stop. Try manually and check if you see a delay when you trigger it by hand.
One reason for delayed signalling can also be an overloaded cpu. Also the rumba is quite fast, if you have stepper frequency too high that can prevent lower interrupts like end stop from being executed as long as stepper is busy. Especially when homing or probing it uses a more cpu intensive variant.
I placed the easy accessable z_min switch to the x-min connector: Using M119 it shows always low, even when triggered. Replacing it to its correct position works as expected: M119 shows low when not pressing the switch and high when pressing the switch.
1. What is wrong
The other question is what are your values for
which can cause cpu overload and block lower level interrupts for a while when selected too high. Higher values increase cpu usage until overload
IO_INPUT_INVERTED_PULLUP(IOEndstopXMin, ORIG_X_MAX_PIN)
with replacing the endstop to that connector homing works without any problem.
Looks like that x-Min connection is broken (or there is something wrong with the pin).
The last board had an electronical problem, too ( https://forum.repetier.com/discussion/comment/33889/#Comment_33889 ). I think I need to check my general electronics.
--> I do use two powersupplies for heated bed and motors. Although there is no voltage on the end stop switch, there might be some inteference. Therefore I made an electronical connection between the "-" of both power supplies to make them have the same ground potential.
I will add a connection to ground my metal parts of the printer, too.
@RAyWB Attached you can find the config-files. I needed to rename them to .txt due to the forum configuration. The file with XMIN in the filename is the config which did not work. _io.txt is the one with the change mentioned above.
Yes, it is solved. But still I Wonder If I am so unlucky to have two broken Boards in a row.
On the other side comparing with marlin pins definition they are also using PB12 for x min. And https://github.com/Aus3D/RUMBA32 has also a drawing with pin numbers where it is PB12.
Alternatively you are using PB12 for something else as well - double use often causes such unexpected errors.
https://drive.google.com/file/d/1oXZFSOLJ57OWnUZmu2HtmGsjs6yK2fQA/view?usp=sharing