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.
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.
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.
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.
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.
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.
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.
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:
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?
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?
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.
Comments
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()':
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?
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.
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
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.
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
have you find the time to solve the continued triggering problem when using a swith as a filament end sensor?
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;
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.