› ›

Z-Probe-Trigger has no effect on Motor Control

Delta_88Delta_88
in Motor Control
Good morning Repetier-World

I have build a Delta Printer and I'm using Repetier firmware. My Problem is the Z-Probing:

My Z_probe is Connected to the Z_min_Endstop. The Configuration of the Firmware seems to be ok: When I send the G31 G-Code, I got the Message back: Z-Probe state:L. By triggering the Probe by hand and resending G31 I get: Z-Probe state:H. Then I send the G28 -> My Delta homes all three axes, and stops properly at the top of the extrusion. Then I send the G30 G-Code -> The Effector begins to go down in direction of the build-plattform. But when I Trigger the Z-Probe it does NOT stop -> Emergency-Stop. -> Ufffff.

So my basic Question is: Why the Effector doesn't stop moving down, when I push the z-Probe trigger during a G30 Command when the G31 shows a working Z-Probe?

I'm looking now for two Weeks for a solution and I would be very happy if someone is smarter than me ;-).

Greethings from Switzerland

Comments

  • RepetierRepetier
    Which firmware version? You should use 0.92 for deltas.

    Make sure you have not zmin as well defined. Deltas should not have min endstops, so these are false. You can of course put the probe on the zmin endstop pins.
  • Delta_88Delta_88
    I'm using Version 92.3.

    My Z-Probe ist on the Z-Min Pin. I tried several Pins. It was always the Sampe. The G31 Command showed a working Probe, but the Motors didn't ract on the probe trigger during the G30 procedure. In the endstop Configuration all min's are false. In the Z-Probe Configuration the pullup and the inverting is true -> if not -> the G31 Command send a not correct working z_probe status.

    My Endstop Configuration (the actual one -> I tried several configurations - always the same picture):

    #define ENDSTOP_PULLUP_X_MIN false
    #define ENDSTOP_PULLUP_Y_MIN false
    #define ENDSTOP_PULLUP_Z_MIN false
    #define ENDSTOP_PULLUP_X_MAX true
    #define ENDSTOP_PULLUP_Y_MAX true
    #define ENDSTOP_PULLUP_Z_MAX true

    #define ENDSTOP_X_MIN_INVERTING false
    #define ENDSTOP_Y_MIN_INVERTING false
    #define ENDSTOP_Z_MIN_INVERTING false
    #define ENDSTOP_X_MAX_INVERTING true
    #define ENDSTOP_Y_MAX_INVERTING true
    #define ENDSTOP_Z_MAX_INVERTING true

    #define MIN_HARDWARE_ENDSTOP_X false
    #define MIN_HARDWARE_ENDSTOP_Y false
    #define MIN_HARDWARE_ENDSTOP_Z false
    #define MAX_HARDWARE_ENDSTOP_X true
    #define MAX_HARDWARE_ENDSTOP_Y true
    #define MAX_HARDWARE_ENDSTOP_Z true

    #define max_software_endstop_r true

    #define min_software_endstop_x false
    #define min_software_endstop_y false
    #define min_software_endstop_z false
    #define max_software_endstop_x false
    #define max_software_endstop_y false
    #define max_software_endstop_z false

    Z-Probe Configuration:
    #define FEATURE_Z_PROBE 1
    #define Z_PROBE_BED_DISTANCE 8
    #define Z_PROBE_PIN ORIG_Z_MIN_PIN
    #define Z_PROBE_PULLUP 1
    #define Z_PROBE_ON_HIGH 1
    #define Z_PROBE_X_OFFSET -8
    #define Z_PROBE_Y_OFFSET -17.3
    #define Z_PROBE_WAIT_BEFORE_TEST 0
    #define Z_PROBE_SPEED 20
    #define Z_PROBE_XY_SPEED 100
    #define Z_PROBE_SWITCHING_DISTANCE 3
    #define Z_PROBE_REPETITIONS 2
    #define Z_PROBE_HEIGHT 5
    #define Z_PROBE_START_SCRIPT ""
    #define Z_PROBE_FINISHED_SCRIPT ""
    #define FEATURE_AUTOLEVEL 1
    #define Z_PROBE_X1 -121.2
    #define Z_PROBE_Y1 -70
    #define Z_PROBE_X2 121.2
    #define Z_PROBE_Y2 -70
    #define Z_PROBE_X3 0
    #define Z_PROBE_Y3 140
    #define FEATURE_AXISCOMP 0
    #define AXISCOMP_TANXY 0
    #define AXISCOMP_TANYZ 0
    #define AXISCOMP_TANXZ 0
  • RepetierRepetier
    In your case it should be stopped here (motion.cpp)

    #if NONLINEAR_SYSTEM

    void DeltaSegment::checkEndstops(PrintLine *cur,bool checkall)
    {
        if(Printer::isZProbingActive())
        {
    #if FEATURE_Z_PROBE
            if(isZNegativeMove() && Endstops::zProbe())
            {
                cur->setXMoveFinished();
                cur->setYMoveFinished();
                cur->setZMoveFinished();
                dir = 0;
                Printer::stepsRemainingAtZHit = cur->stepsRemaining;
                cur->stepsRemaining = 0;
                return;
            }

    You could set 
    Com::printFLN(PSTR("zprobe hit")); 

    before cur->setXMoveFinished(); then you should see the message when it gets triggered during probing move.
    You could also send a message after #if FEATURE_Z_PROBE to see if the routine gets into zprobe test at all. But this will most likely crash firmware after some lines of output. But at least you then know it goes in there.

    Does your probe have a led to indicate triggering, so you can be sure it switches?

    our settings look ok so far I can see.

  • Delta_88Delta_88
    edited August 2015
    Ok, i wrote in motion.cpp before cur->setXMoveFinished(); the following:

    Com::printFLN(PSTR("zprobe hit"));

    -> new upload -> Connecting -> G31 -> L -> manual swithcing -> G31 -> H
    -> G28 -> wait until homed
    -> G30 -> Effector moves down
    -> manual Trigger -> nothing happens (The effector continous moving down with homing speed (not with probing speed (20mm/sec)
    -> no message on the Display or in the Host

    Nearby: when I set: Z_PROBE_WAIT_BEFORE_TEST 0 to true (1) the printer dows not wait for the trigger when i send G30. It start directly with moving down.

    Sending a Message (again "Com::printFLN(PSTR("zprobe hit"));") after #if FEATURE_Z_PROBE (after #endif in motion.ccp) chanches nothing on the Display or in the Host (no message).

    So when I understand you correctly the Procedure does not enter this Part of Motion.ccp -> how can I change that?


    AND: I've got news - I tried something new:
    When I send the Command G30 P2 the printer makes a Probe (it sinks with probing speed, trigger works -> Stops the Z-move). G30 P1, G30 P3, G30 does not work (old behaviour). G29 P1-3 dows not work either (continous moving after triggering the z-probe)
  • Delta_88Delta_88
    edited August 2015
    Now i don't understand the world:

    After the things I wrote in the last post, I played around with your Idea of Messages. Im motion.ccp I wrote the following:

    #if FEATURE_Z_PROBE
            if(isZNegativeMove() && Endstops::zProbe())
            {
                Com::printFLN(PSTR("zprobe hit1"));
                cur->setXMoveFinished();
                cur->setYMoveFinished();
                cur->setZMoveFinished();
                dir = 0;
                Printer::stepsRemainingAtZHit = cur->stepsRemaining;
                cur->stepsRemaining = 0;
                return;
            }
     {
      Com::printFLN(PSTR("zprobe hit2"));
     }
    #endif
    {
      Com::printFLN(PSTR("zprobe hit3"));
     }

    I send G30 -> The Effector began to sink with Probe speed and made a Probe and went back home (the FIRST TIME -> Juhuiiiiiiiiiiiii - Sorry for the Swiss Emotions :-) ).

    The Display showed during the hole Process nothing new. But the Host showed:
    11:37:25.685 : zprobe hit2
    11:37:25.685 : zprobe hit3
    11:37:25.685 : zprobe hit2
    11:37:25.685 : zprobe hit3
    ........ (a lot more)
    11:37:26.716 : zprobe hit2
    11:37:26.716 : zprobe hit3   -> here I triggered the Probe
    11:37:26.716 : zprobe hit1
    11:37:26.888 : zprobe hit1
    11:37:26.888 : Z-probe:105.56 X:-7.90 Y:-0.01

    And now the frustrating thing: It worked for only ONE TIME. The second try showed again the old behavior -> Fast Sinking of the effctor, no effect after triggering the z-probe. (Between these two tries I have not made another Firmware upload. Promised.)

    Again when I sent the G30 Command fast descending of the effector and no messages in Display nor in the Host Protocol.

    Can you understand that?

    Nearby: Thank you very much for your time and help...
  • RepetierRepetier
    That really does not look like a software problem directly.(knowing that it works for me). I think it might be the pin and some other thing we do not know. So maybe some other function uses the pin as well during moves preventing changes. You could try using x min pin instead and see if it makes a difference. Also you might perhaps twist the zprobe cable in case it is crosstalk related. 
  • Delta_88Delta_88
    edited August 2015
    Good Afternoon.
    Sorry for my late reaction, but it took a lot of work for the following post:

    - This Week I tried serveal Pins (X_min, y_min, 42, 44) and it was always the same picture.
    - then I chanched the Switch at the end of the Probe (4 Switches, 5 Pins, 2 ways of connecting the switch -> 40 Constellations)

    => always the same picture.

    So I doubted the possibility of the double use of the Pin I'm using. When I understood you correctly you still believed it is a hardware Problem. I have a second Printer also with a Ramps 1.4. So I changed the hole Ramps (and Arduino) Module, upload the same Firmware and had a look if it works.

    Result: You where right, the Probe works - So it was a hardware problem. It is a little bit frustrating for me, that I probably never will find the mistake. But my second Printer does not use a Probe so I have two working printers again.

    I say thank you very much for your time and help and send best regards

  • Delta_88Delta_88

    Good morning

    I got News from the Z-Probing front. I couldn't stay calm, I wanted to know where the Problem Comes from, and I found the solution. We thought that the Problem must be a Hardware Problem. But it was a Software Problem -> EEPROM!!!

    In all calibration and tries my Firmware stayed in the EEPROM Modus 1. I changed that value to 2 and reuploaded the Firmware (to the first Ramps/Arduino Module). And suddenly everything went perfect also with the old Ramps/Arduino Module.

    So my Theorie is, that something in the EEPROM was no compatible with the new Firmware and I didn't replace that with uploading a new Version by NOT CHANGING the EEPROM value.

    I write that, because someone could have the same Problem and it would be my advise to change the EEPROM value in the Configuration.h file.

    So i wish good calibration

  • RepetierRepetier
    Maybe I should make that the top 1 tipp for unexpected behaviour. Especially enabling features can start with uninitalized values as eeprom was initalized without these parameters beeing set.

    Good work for finding this one.
  • RokoRoko
    1st time I saw this, newbie here. 
    FWIW I always run the eeprom_clear in Arduino before I compile and upload to the board, It has saved me a lot of headaches.
Sign In or Register to comment.