G28 E with extuder endstop enabled

For syringe extruders it would be great to have an endstop and a G28 E command for filling precision syringes during printing

Comments

  • That is now included as experimental feature in jam control. Set
    #define JAM_METHOD 2 or 3
    2 and 3 differ only in the signal open/closed to say end of filament. Could also be end of syringe I guess.

    It should start the jam/out of filament wizard or whatever solution you have selected there.

    It is experimental because I have no test printer with such a setup and the tester hasn't confirmed it is working. Works with latest 0.92.5.
  • Hi,
    I have modyfied the #define JAM_METHOD to 2 and 3 but i get an error during compiling

    Extruder.cpp: In static member function 'static void Extruder::step()':
    Extruder.cpp:1030:1: error: a function-definition is not allowed here before '{' token
     {
     ^
    Extruder.cpp:2249:2: error: expected '}' at end of input
     };
      ^


  • Hi,
    after update to version 0.92.6 and changing #define JAM_METHOD to 2 or 3 i'm still getting the same error.

    Extruder.cpp: In static member function 'static void Extruder::step()':
    Extruder.cpp:1030:1: error: a function-definition is not allowed here before '{' token
     {
     ^
    Extruder.cpp:2249:2: error: expected '}' at end of input
     };

    Here is my configuration file.
    https://dl.dropboxusercontent.com/u/16734804/Repetier-Firmware-2015-11-15.zip
    Can you please check it and let me know what am I doing wrong?
  • Here is my latest configuration file.

  • Ok, found the compilation problem. Please retry and report how it works.
  • Hi,
    after your correction I had no compilation error and I could load the firmware to my printer.
    I test the option #define JAM_METHOD 2 (sensor closed when filament inside) and it does work but not 100% the way it should.
    1. don't strart the change filament option right away. Sometimes I need to wait  5 minutes after I pull the fillament out.
    2. when it starts the change filament option the table goes down about 5 cm. (and after the filament change it does not go up right away, it goes up after printing the whole line)
    3. sometimes the extruder temp. sensor goes to decoupled status
    4. few times printer stopped printing and turned off and on again (restarted the printer).
    In the link below I send you a short film showing you the problem I've described above.



    I use a cartesian printer with Rumpa and i have EEPROM option disabled. The sensor is connected to X max slot.
  • 3 and 4 are not jam related and maybe the same. I have updated firmware this weekend to return always a message if debug level was changed, 4. may be a switch to dry run cause of a extruder problem. It seems this happens to some users and there is a error that did not come with a message. If it happens again, please check the log (with new firmware) for messages and if you are in dry run mode (on lcd).

    1. Detection is only tested on extruder moves. Manually removing filament is not detected. With mechanical endstops make sure to have pullup enabled.

    2. I guess you have said to go down 5cm in config? So question is why it needs a move to correct. Hope to get the jam detecting printer soon, so I can see this.
  • Hi,

    1. I had no pullup enabled (I chenge it and check tomorrow)
    2. 5 cm is to much (just normal value as it is on filament option in lcd menu is enough)
    3 and 4 I will test once again tomorow :)


  • HI again,
    So... I finally got time to test the sensor.
    When I enable the pullup resistor, the change fillament comand is trigered right away after the filament runs out.
    But there is still a problem with the table. It goes down 5 cm (and it is too much).
    After the table stops the printer is rebooting (it hapens every time).
    I give link below so you can see how it works.
       

  • HI,
    i just updated the firmware of my printer to 0.92.7 version ant tested it.
    So it still makes the same thing as id did before.
    Here you have the log file from repetier host
    https://dl.dropboxusercontent.com/u/16734804/log repetier 1.txt
    https://dl.dropboxusercontent.com/u/16734804/log repetier 2.txt


  • The rotating sensor needed some way to retrigger, a simple switch does signal all the time. We need a way so solve this continued triggering.
  • On the original of this request (G28 E for homing syringe extruders):
    • changed #define EXT0_JAM_PIN -1 to 42 in configuration.h
    • added #define JAM_METHOD 2 in the manual part of configuration.h
    • connected an opto endstop, signal to pin 42
    As long as the signal is high, the PRINTER_INTERRUPT_EVENT_JAM_DETECTED gets raised. So I added a flag in  and Printer.cpp to prevent repeated execution of myJam_action:
    •  static bool JamActing; (Printer.h, Class Printer)
    • bool Printer::JamActing = false; (Printer.cpp )
    For testing I added the next for JAM_ACTION == 10 in Printer::handleInterruptEvent (I'll move this to a custom events part in the final version)and changed #define JAM_ACTION from 0 to 10 in configuration.h. 
    #elif JAM_ACTION == 10
            if (!Printer::JamActing) {
              Printer::JamActing = true;
              Extruder::pauseExtruders();
              Extruder::markAllUnjammed();
              Extruder::unpauseExtruders();
              PrintLine::moveRelativeDistanceInSteps(0, 0, 0, 2 * Printer::axisStepsPerMM[E_AXIS], Printer::maxFeedrate[E_AXIS] / 8, false, false);  // Move back  a bit to unstop the endstop
              Commands::waitUntilEndOfAllMoves();
              Printer::currentPositionSteps[E_AXIS] = 0;  //Set extruder start position
              Printer::JamActing = false;
            }

    In the Gcode I start all prints with setting my syringe valve to stock inlet and then move the extruder (syringe piston motor) towards the endstop (out). 

    Test look good. The extruder stops at once. Then the printer waits some 30 seconds (don't know why ? adding Com::printFLN(PSTR("some comments") increases the delay), moves the extruder back a bit (piston in) and starts printing.


  • Good idea to catch it where raised, but maybe that is the source of the delay as well depending on the extra code executed. After all it is executed every step while moving extruder. So maybe catch the flag already in the detection macro instead. I have bookmarked it so when I get some more time I can try this. I have now a switch for testing also only for a virtual printer but better then nothing:-)
  • There is very little delay when I use the retract button on the host manual control tab, or enter G1 E-50 in the G-code field on the same tab. I added comment lines between the lines in my JAM_ACTION == 10 , the log then shows that the delay is caused by the "Commands::waitUntilEndOfAllMoves(); "statement. I'll try to do some more detailed logging.
  • waitUntilEndOfAllMoves wait for the retraction to finish, so yes it has a delay. I guess you can omit it.
  • If I omit it it will not wait for the endstop to be released, resulting in another jam event, causing the extruder to stop again. If I find some time I'll write my own G28 E using the EVENT_UNHANDLED_G_CODE. Thanks.
  • Hi,
    have you find the time to solve the continued triggering problem when using a swith as a filament end sensor?
  • Sorry, but had no time to build a fake trigger and do the writing so far, sill on todo.
  • On the original of this request (G28 E for homing syringe extruders):
    • changed #define EXT0_JAM_PIN -1 to 42 in configuration.h
    • added #define JAM_METHOD 2 in the manual part of configuration.h
    • connected an opto endstop, signal to pin 42
    As long as the signal is high, the PRINTER_INTERRUPT_EVENT_JAM_DETECTED gets raised. So I added a flag in  and Printer.cpp to prevent repeated execution of myJam_action:
    •  static bool JamActing; (Printer.h, Class Printer)
    • bool Printer::JamActing = false; (Printer.cpp )
    For testing I added the next for JAM_ACTION == 10 in Printer::handleInterruptEvent (I'll move this to a custom events part in the final version)and changed #define JAM_ACTION from 0 to 10 in configuration.h. 
    #elif JAM_ACTION == 10
            if (!Printer::JamActing) {
              Printer::JamActing = true;
              Extruder::pauseExtruders();
              Extruder::markAllUnjammed();
              Extruder::unpauseExtruders();
              PrintLine::moveRelativeDistanceInSteps(0, 0, 0, 2 * Printer::axisStepsPerMM[E_AXIS], Printer::maxFeedrate[E_AXIS] / 8, false, false);  // Move back  a bit to unstop the endstop
              Commands::waitUntilEndOfAllMoves();
              Printer::currentPositionSteps[E_AXIS] = 0;  //Set extruder start position
              Printer::JamActing = false;
            }

    In the Gcode I start all prints with setting my syringe valve to stock inlet and then move the extruder (syringe piston motor) towards the endstop (out). 

    Test look good. The extruder stops at once. Then the printer waits some 30 seconds (don't know why ? adding Com::printFLN(PSTR("some comments") increases the delay), moves the extruder back a bit (piston in) and starts printing.


    i need to have an endstop for syringe extruders. please tell me how make it working? thank you so much.
  • The new dev version should work now. Select as jam method signal gets high/low depending on switch and set pin id for it. Should pause when syringe triggers switch then you can refill and unpause.
  • where i should add 
    • static bool JamActing; (Printer.h, Class Printer)
    • bool Printer::JamActing = false; (Printer.cpp )
  • There should not be a need to modify any code. Dev version is hopefully working correctly in that aspect.
  • Hi,
    I've read this feature request and believe I'm trying to do the same thing, for both syringe extrusion and as an out-of-filament sensor, using a standard makerbot version limit switch (3-pin).
    I'm running repetier firmware 0.92.9 and have modified the following:

    configuration.h
    #define EXT0_JAM_PIN 2  // was -1
    #define EXT0_JAM_PULLUP 1 //was 0

    Somewhere in the tabs it finds this line:
    #define JAM_METHOD 2  //was 1

    Behavior:
    The printer prints properly when the switch is closed and stops when the filament runs out.  Unfortunately it seems to repeatedly trigger, which either locks up the printer not allowing the button to be read to reheat the extruder or keeps jogging up and up.

    Any idea what I'm doing wrong?  I'm using the Xmax endstop pin for the out of filament on a RAMPS1.4.  Do I need to ensure that pin is not assigned for something else maybe?

    The help is greatly appreciated!
    Jared

  • Doh,
    I updated to the V1.0 Dev version and everything works great!  Sorry, and thanks!
    Jared
  • edited March 2018
    I read this thread because i had the same problem.

    I modificated the JAM_Action in this way, that the printer stops when a switch (I use Jam_method 2) was triggered, the printhead moves to an "refill-position", a valve opens and the extruder(syringe) drives back for 50mm, the valve closes, than the printhead goes back to his last position before interrupting the printing process.


    I works rudimentary but not quite very well. I used the command movetoreal at printer.cpp to move the printhead to the refill-position, is this the right way?

    Is it possible to change the order the printer resume to his lastposition before the stop? The order should be ZXY.The printhead shouldn't move in all directions simultaniosly. Can I modificate the behavior at Printer.cpp:

    void Printer::GoToMemoryPosition(bool x, bool y, bool z, ......


    Further i want to implement an backlash-compensation for the E-Axis. Is this possible or is it not allowed from firmware-side.

    Is it wrong to use "delay(xxxx);", can i get problems with the timing?

    I'm a beginner in programming ;)

    Here is the code snippet:



    #if JAM_ACTION == 1 // start dialog
            Printer::setUIErrorMessage(false);
    #if UI_DISPLAY_TYPE != NO_DISPLAY
            uid.executeAction(UI_ACTION_WIZARD_JAM_EOF, true);
    #endif



    #elif JAM_ACTION == 2 // pause host/print
    #if SDSUPPORT
            if(sd.sdmode == 2) {
                sd.pausePrint(true);
                break;
            }
           
    #endif // SDSUPPORT


    //GCodeSource::printAllFLN(PSTR("RequestPause:Extruder Jam Detected!"));

         

    #endif // JAM_ACTION


    Commands::waitUntilEndOfAllMoves();


    SET_OUTPUT(LEDVALVE); // LED an PIN27 simuliert Ventile zum Vorratsbehälter


    delay(2000);

    Printer::moveToReal(Printer::xMin, Printer::yMin, IGNORE_COORDINATE, IGNORE_COORDINATE, Printer::maxFeedrate[X_AXIS]);
    Commands::waitUntilEndOfAllMoves();

    delay(1000);

    Printer::moveToReal( 50, 50, Printer::zMin, IGNORE_COORDINATE, IGNORE_COORDINATE, Printer::maxFeedrate[Z_AXIS]/2);

    delay(1000);

    digitalWrite(LEDVALVE, HIGH);

    delay(1000);


    PrintLine::moveRelativeDistanceInSteps(0, 0, 0, -150 * Printer::axisStepsPerMM[E_AXIS], Printer::maxFeedrate[E_AXIS] * 1, false, false);

    Commands::waitUntilEndOfAllMoves();

    delay(1500);

    digitalWrite(27, LOW);

    delay(1500);

    PrintLine::moveRelativeDistanceInSteps(0, 0, 0, 20 * Printer::axisStepsPerMM[E_AXIS], Printer::maxFeedrate[E_AXIS] / 1, false, false);

    Commands::waitUntilEndOfAllMoves();

    delay(1000);


    EVENT_JAM_DETECTED_END;








  • GoToMemoryPosition is what is used to resume position after pause if it was added by firmware.

    Long delays can be a problem if move buffer runs out. In your case this seems to be intended so no problem here.  Also they prevent firmware from answering, so hosts might get a timeout. Inside jam function the host is told to not communicate for a while so that will not happen at least with our host/server.

    movetoreal or not makes for extruder no difference. Only thing is position 0 is only true if flow multiplyer stays 100% or the distance will vary.
Sign In or Register to comment.