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.

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?








Comments

  • 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.
  • edited October 2020
    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.
  • 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.
  • edited October 2020
    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. 
  • edited October 2020




    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


  • 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 \
    2000 // Update frequency for new blocks. Must be higher then
    // PREPARE_FREQUENCY.
    #define BLOCK_FREQUENCY \
    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
  • 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.
  • edited October 2020
    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
  • edited October 2020
    second try: failed. The uploaded files are not shown. Email would be the easiest way.

  • 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.
  • 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.
  • 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.
  • 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.
  • Repetier said:
    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:





  • 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.
Sign In or Register to comment.