Homing confusing

karl_ranseier

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<br/><br/>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

to make the homing in the following:

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:

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?

Repetier

First parts shown are ok I would say. When homing starts early there are 2 reasons - x length is not high enough or x endstop triggered. Please check how you define IOEndstopXMin - if it is a mechanical endstop it must have a pullup or signal is floating and can be anything when not triggered.

karl_ranseier

It's not stopping early, it is not stopping anyway or late.
I understand where I was misleading. I wanted to say it stops 250-500ms AFTER it reached the end stop.

IO_INPUT_INVERTED_PULLUP(IOEndstopXMin, ORIG_X_MIN_PIN)// IO_INPUT_INVERTED(IOEndstopXMin, ORIG_X_MIN_PIN)IO_INPUT_INVERTED_PULLUP(IOEndstopYMax, ORIG_Y_MAX_PIN)IO_INPUT_INVERTED_PULLUP(IOEndstopZMax, ORIG_Z_MAX_PIN)

Yes, they are mechanical switches.

Repetier

Yes the 250ms was for me a move stopped after a short while:-)

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.

karl_ranseier

Sorry, I did not get what M111 S70 should behave like.

I have send the command.

Send:23:41:25.820: N24 M111 S70

Recv:23:41:25.820: DebugLevel:70

Recv:23:41:25.820: debug:Echo:Off

Recv:23:41:25.820: debug:Info:On

Recv:23:41:25.820: debug:Errors:On

Recv:23:41:25.820: debug:DryRun:Off

Recv:23:41:25.820: debug:Communication:Off

Recv:23:41:25.820: debug:NoMoves:Off

Recv:23:41:25.820: debug:Endstops:On

(by the way, it is hard for me to get the code into the code-format of the forum. It always removes the code layout.

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.

Maybe the pins are not assigned correctly? Did that change from 1.0X to 1.1b?

Here I do find the actual pinout ( https://github.com/Aus3D/RUMBA32 ), but not the older one. So I cannopt compare them, sorry.

In rumba32.h I can find:

#define ORIG_X_MIN_PIN PB12

which fits to the scetch in the link.

Open questions:
1. What is wrong

2. why did it sometimes stop. I checked if there is any triggering, when other endstops were hit, but that was not the case.

RAyWB

https://github.com/Aus3D/RUMBA32/blob/v1.1/Source/Outputs/RUMBA32_v1_1A_PinoutDrawing.PDF</div><div><br/></div><div><br/></div><div>https://github.com/Aus3D/RUMBA32/blob/v1.1B/Source/Outputs/RUMBA32_v1_1B_PinoutDrawing.PDF</div><div><br/></div><div><br/></div><div>as far as i can see there are no changes on the endstop inputs.

I have both versions here, hope i find the time to check this weekend.

can you share your config files ? so i´ll try to reproduce your problems

Repetier

Ok M111 S70 enables debug mode for end stops. That pushes endstop status any time firmware sees a change. So output is same as M119 just you don't need to send M119 any more. You get a new line any time an end stop changes. That way you should be able to see if triggering a end stop immediately results in a message (which should be the case) or if there is a 250-500ms as with G28 homing.

The other question is what are your values for

#define STEPPER_FREQUENCY 120000 // Maximum stepper frequency.

#define PREPARE_FREQUENCY </div>

2000 // Update frequency for new blocks. Must be higher then

// PREPARE_FREQUENCY.

#define BLOCK_FREQUENCY </div>

1000 // Number of blocks with constant stepper rate per second.

which can cause cpu overload and block lower level interrupts for a while when selected too high. Higher values increase cpu usage until overload

karl_ranseier

In configuration_io.h I changed

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.

RAyWB

nothing attached... you have to upload the files to something like pastebin, googledrive ,etc.

if youre afraid to do so i´ll send you my e-mail by pm

karl_ranseier

second try: failed. The uploaded files are not shown. Email would be the easiest way.

Repetier

Where do you see a upload function? Because we have none and in my interface I also see none. Easiest solution is dropbox or google drive and share a file. But I thought your problem is solved using x max pin instead.

karl_ranseier

You can simply drag & drop a file to the Editor. At least in Firefox.

Yes, it is solved. But still I Wonder If I am so unlucky to have two broken Boards in a row.

Repetier

If both are RUMBA32 it might also be a wrong pin id in board description. My test printer is a delta so all end stops are max end stops and z min for z probe.

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.

karl_ranseier

Both were Rumba32, but different pins were broken. I think we should not waste time on that. I have a working solution. I will contact the company which produced the board.

karl_ranseier

Repetier wrote
Where do you see a upload function? Because we have none and in my interface I also see none. Easiest solution is dropbox or google drive and share a file. But I thought your problem is solved using x max pin instead.

Here are three screenshots about the file-upload:
https://drive.google.com/file/d/1T0mxbiOQs0eOS3FkE21Rrtc8jPUd1L7Q/view?usp=sharing<br/>https://drive.google.com/file/d/1oXZFSOLJ57OWnUZmu2HtmGsjs6yK2fQA/view?usp=sharing</div><div>https://drive.google.com/file/d/1WULyJz-2dL-mq1hyK5bHNxFjgnE52kb4/view?usp=sharing</div><br/><br/><br/><br/><br/>

Repetier

Ok, never tried that. We have actively disabled uploads and removed the button. Never thought the editor is also registered as drag target. Forum software is not that perfect as I wished, but too late to switch.