Use an Opto stop to pause print when filament runs out?

Does anyone know if someone has use an optostop endstop to send a pause signal to marlin? I am currently only using 3 of the 6 endstop locations on my ramps shield and was hoping one of the remaining three could be configured and coded to trigger a pause command when filament is not present (place the filament going through the endstop right before the extruder). Any suggestion or advice?

This would make finishing partial rolls of filament easier and avoid ruining a large print due to running out of filament.

Edited 2 time(s). Last edit at 01/19/2014 04:03PM by cfeniak.

Quote
cfeniak
Does anyone know if someone has use an optostop endstop to send a pause signal to marlin? I am currently only using 3 of the 6 endstop locations on my ramps shield and was hoping one of the remaining three could be configured and coded to trigger a pause command when filament is not present (place the filament going through the endstop right before the extruder). Any suggestion or advice?

This would make finishing partial rolls of filament easier and avoid running a large print due to running out of filament.

It happened to me last night, 6 hour print nearly finished but not enough filament, hence it is now in the bin and start again.

---

[regpye.com.au]
"Experience is the mother of all knowledge." --Leonardo da Vinci

It could be done with a mechanical endstop as well, but I think an opto endstop would be more elegant. I have a reprap discount LCD to control my printer and have used the pause function to switch rolls. Hopefully this appeals to someone more familiar with the coding in Marlin, so that the right code and pins could be utilized to send a gcode pause on endstop open.

M25: Pause SD print

It should be easy enough to do. The functionally needed is very similar to the kill pin functionality. Copying renaming and tweaking that function and it's setup should be easy.

Also the more I think about it. M600 (change filament) would be better than M25.

in pins.h under the board your using add

#define PAUSE_PIN 42

i used pin 42 just for testing but you can use any you have free.


in Marlin.h find void kill(); and add after it

void pause();

in Marlin_main.cpp find void setup() and after setup_killpin(); add

setup_pausepin();

then find void manage_inactivity() then find

#if defined(KILL_PIN) && KILL_PIN > -1
if( 0 == READ(KILL_PIN) )
kill();
#endif

and after it add

#if defined(PAUSE_PIN) && PAUSE_PIN > -1
if( 0 == READ(PAUSE_PIN) )
pause();
#endif

finally at the end of the file add the following

void setup_pausepin()
{
#if defined(PAUSE_PIN) && PAUSE_PIN > -1
pinMode(PAUSE_PIN,INPUT);
WRITE(PAUSE_PIN,HIGH);
#endif
}

void pause()
{
enquecommand("M600");
enquecommand("G4 P0");
enquecommand("G4 P0");
enquecommand("G4 P0");
}


This works but you could change the M600 to what ever you want. The G4 P0 does nothing but is there just to fill the buffer otherwise you get the M600 added 4 times in the buffer.

Im sure there is a better way but give it a go

Thanks, I'll try this out today after my current print finishes. Let you know how it goes.

Initial tests... awesome.
So I used the Z axis max endstop location since I don't use it.
Changed pin.h like so (I have Ramps 1.4):

#define Z_STEP_PIN 46
#define Z_DIR_PIN 48
#define Z_ENABLE_PIN 62
#define Z_MIN_PIN 18
#define Z_MAX_PIN 19
#define PAUSE_PIN 19

And followed LAZYMONK's advice above with two changes. The first one was that the
void setup_pausepin()
etc...
statement has to go at the top, not the bottom (gives a compile error in definition).

The second was I still choose to use M25 over M600, because with M25 the print is resumed by clicking resume through the turn and click controller, which allows you to get everything in order before it starts again. With M600, the print "sleeps" and starts as soon as the optostop senses filament again. This won't give me enough time to get the filament down to the bottom of the nozzle.

Next?
I tested this with a razor blade in the sensor. The sensor is very sensitive to the location of the filament so I will have to design and print a holder and guide assembly as I don't want the print to pause for no reason (a down side of M25 versus M600). Perhaps I should use M600, then manually pause before changing filament? That sounds like a good compromise if the optistop signal isn't reliable enough. Future testing to determine!

Thanks LAZYMONK!

Aside:
Optistop wiring to ramps 1.4:
RAMPS End
SIG (S) White
GND (-) Black
VCC (+) Red

Endstop End
VCC (+) Red
SIG (S) White
GND (-) Black

Great! I'm glad it worked for you.

I did expect a compiler error with setup being at the bottom but didn't get one my self.

Maybe you could experiment with M43 and see if it's closer to what you need.

I'm not really a fan of opto end stops so I think I would go with a mechanical switch.

Another option maybe worth thinking about is rather than using the filament in the opto is to put a flag on the idler which will move when there is no more filament in it. Downside of that is you can't then retract is but shouldn't need to in a way.

Sorry if I've rambled

Would there need to be any change in logic if switching to a mechanical switch due to the high/low open/close difference? Never noticed M43 before, sounds up to the task

Filament detection sounds like a great idea I think everybody's had that problem when they run just a little shot of filament. For me personally I'd like to keep the heat bed on so the part would not come loose

Edited 1 time(s). Last edit at 01/21/2014 10:30AM by cnc dick.

cfeniak you would need to change the following

#if defined(PAUSE_PIN) && PAUSE_PIN > -1
if( 0 == READ(PAUSE_PIN) )
pause();
#endif

to

#if defined(PAUSE_PIN) && PAUSE_PIN > -1
if( 0 != READ(PAUSE_PIN) )
pause();
#endif

Note the != rather than ==

cnc dick M600 and M43 both leave the bed heater on.

Edited 1 time(s). Last edit at 01/21/2014 10:44AM by lazzymonk.

I just did a filament change during a print this evening. Printing from an SD card, selected "Pause Print" from my G3D LCD menu, pulled out the rest of the old filament, and replaced it with the new. Unfortunately (and perhaps inevitably), I moved the extruder in the x-axis while replacing the filament, so I needed to rehome (just the X) prior to resuming my print. This is not possible from the LCD (which only has menu items for "Auto Home" which homes all axes and is not what I want to do with a half-finished print on the platform), so I had to connect my laptop to the printer (which reset it and made me lose all positions. To fix this, I edited my Gcode file to start at the last good Z position, rehomed the X/Y axis, and sent a G92 command to reset the Z position prior to restarting. This worked, and my print is finishing up now.

Long story short, this would have been a lot easier if there were axis-specific home commands in the LCD menu structure, and/or an equivalent to the G92 command, per axis.

bkpsu
I haven't tried it yet but if you implement M43 above it homes only the XY. Hopefully when you "resume print" it works out.

This is really slick. Thanks for checking this out for everybody. Not completely necessary but sounds pretty easy to implement and low cost as well.

Cheers,

KDog

Adding home x to the LCD is easy. All you need to do is find the the following in ultralcd.cpp

MENU_ITEM(gcode, MSG_AUTO_HOME, PSTR("G28"));

Then add this after

MENU_ITEM(gcode, "Auto Home X", PSTR("G28 X0"));

Edited 1 time(s). Last edit at 01/22/2014 08:30AM by lazzymonk.

So how does this work if you don't move the hotend away before the pause happens? In my experiences when the printer froze, it has created a nice melted spot where it had just sat there and dumped all the heat. Even if you move the hotend before a pause, I'm not sure how you would get it back unless you can somehow grab the last X-Y position and inject it before the print resumes. If you do figure out how to get the last X-Y position before pausing, I would also add an X-Y home sequence before resuming just to make sure nothing was screwed up during filament change or recharge.

That exactly what M600 does. M43 does very much the same too. Which is why the code I made uses M600.

Hello

I am very interested in this post and it is working as described.
The only problem is I am getting the M600 command sent 4 times.

Once I hit the encoder on the LCD 4 times it begins printing where it left off.

Is there something else I can do to ensure the M600 is added only once?

I am in the homestretch here and would really like to move on as this is an awesome upgrade.

thank you much,

Joe

if you look at my earlier code you will see that enquecommand("G4 P0"); is there 3 times after the m600 call.

this is to fill the command buffer stopping m600 being added more.

Thanks for your work on this.

Here's what I have:

void pause()
{
enquecommand("M600 X0 Y0 Z10 E0 L0");
enquecommand("G4 P0");
enquecommand("G4 P0");
enquecommand("G4 P0");
}

Do you think the additional code beyond M600 is the problem?
I cant have filament retract on my setup.

thanks,

I just checked it with the exact code you have and I'm still getting 4 instances of M600.

stumped...

maybe the buffer size has been changed recently. you could try adding enquecommand("G4 P0"); more times and see what happens.

Well I added G4 P0 up to 40 times and then up to 80 times just for fun and I'm still getting the same results.

Should I be looking elsewhere?

I was slightly confused on exactly WHERE to define the PAUSE_PIN in PINS.H

So I defined it under MOTHERBOARD == 33 as well as under the section for the REPRAPDISCOUNT controller.

Maybe that is my problem. Can you tell me exactly where i need to define the PAUSE_PIN so i can eliminate that as a variable?

I appreciate your help!

pause pin would not be the problem. The fact that m600 is triggering at all means pause pin is defined correctly.

the best way to resolve it would be to do something like this

bool pauseAdded=false;

void pause()
{
    #if pauseAdded == false
        enquecommand("M600");
        pauseAdded = true;
    #endif
}

then at the end of the m600 code

pauseAdded=false;

Edited 1 time(s). Last edit at 07/11/2014 02:49AM by lazzymonk.

I am really stumped, I just can't seem to prevent it from sending the command multiple times.
I tried your piece of code as well and it responds the same way.

I've attached a screenshot of the monitor window in S3D. Maybe that will help shed some light on it...

I'm open to any other ideas, i really want to get this working right because it is sooooo close.

The only other thing I can suggest is that you get a fresh copy of marlin, only make the changes listed above and see what happens.

yeah, no love.

Fresh marlin and the exact code above. I am using a mechanical switch but other than that it's identical.

I wonder what would have changed to make what you did a year ago not work right today.
Do you think there's a better option than M600? I see the other posters mention using M25 or M43.

I'll play around a little bit more tomorrow, but I may just have to move on.

Too bad, I love this idea.

thanks,

I'm sorry to resurrect this old thread, but I, too, am experiencing the M600 being sent four times. I thought perhaps the "G4 P0" may be getting ignored, as it's "0", so I changed them to "G4 P1" instead, but no change. I'll put up with it for now, since I have to be present to thread in the new spool of filament anyway, might as well stick around to ensure the print starts again. I hope a fix is found evenually, though.

Also, does anyone know where the retract speed setting is located for M600? It's too high for my printer, it just buzzes the motor. It's actually a handy bug, as I don't have to worry about reseating the filament in the extruder four times.

Edited 1 time(s). Last edit at 08/27/2014 12:06AM by AbuMaia.

---

MakerFarm 8" Prusa i3v
RAMPS 1.4
0.4mm E3D v6 for 1.75mm

I just did a test. Instead of

void pause()
{
enquecommand("M600");
enquecommand("G4 P0");
enquecommand("G4 P0");
enquecommand("G4 P0");
}

I rearranged the commands to be

void pause()
{
enquecommand("G4 P0");
enquecommand("G4 P0");
enquecommand("G4 P0");
enquecommand("M600");
}

It seems to work to prevent the command being sent four times. At least, when I tested it with my printer cold and not printing, it only went through one cycle.

---

MakerFarm 8" Prusa i3v
RAMPS 1.4
0.4mm E3D v6 for 1.75mm