MakerFarm 8" Prusa i3v Enclosure

[TopJimmyCooks]

AbuMaia, can you post or link to more detail on your filament shut off switch - how does it report back and cause the pause command to be sent? thanks.

[AbuMaia]

Sure.

I use this switch housing http://www.thingiverse.com/thing:285504 with the switch plugged N.O. into pin 57 and 5v on RAMPS, right next to the servo pins. There are other switch housings available, just search "filament switch", I think I saw at least 6 versions scattered about.

I followed the instructions in this post http://forums.reprap.org/read.php?1,297350,399545 to modify Marlin to watch the switch and issue an M600 if it opens. Oh, I also modified part of the M600 code to not deactivate the steppers after a certain time, to try to prevent me from accidentally moving the X axis when replacing the filament. I commented out the "manage inactivity" line under M600.

I do have a problem of the M600 being sent 4 times, even with the "G4 P0" listed in that post. I haven't yet figured out how to fix it.

[Roxy]

I do have a problem of the M600 being sent 4 times, even with the "G4 P0" listed in that post. I haven't yet figured out how to fix it.

There are a number of approaches to do this 'Right'. By jamming commands into the serial buffer for the firmware to execute they gave up a lot of control, but it was a very quick and dirty way to get results.

One of the big flaws in how they did it is they have no idea how much buffer space is available for commands when the switch gets triggered. For starters, the buffer management routines should be rewritten to address the situation where there isn't enough room to jam more commands in the buffer.

But really... I would be very tempted to duplicate the M600 command as a stand alone routine that could be called when a condition is detected. Then it would not be very difficult in the main loop to check prior to executing any command if the filament needs to be changed. If so... You call the new (duplicate) routine and don't have to mess with the GCode command buffer.

[gmay3]

So I got my bowden tube much earlier than I had expected!

It's definitely slippery and feels like teflon which makes sense because after a google search I see that teflon is version of PTFE. It's also less flexible and more rigid that I had expected. I tried a few placement tests and for my printer and decided I won't be running the tube along with the other extruder/hotend wires. This is mainly because I would have to rotate my extruder motor and reroute all the wires which are going to my hotend. I like how everything is routed now so I don't want to change it right now. Plus if you want to do this, there are already parts out there as AbuMaia has already found that work great!

With this out of the way, the next decision is whether to route the tube over on the left side of the LCD or the right side of the LCD. I'm going to pick left because it is much more central to the print area, however it can't be in the way of the SD card (which is already hard to remove as it is).

My plan is to redesign the left side of the LCD mount, the part with the SD card slot. This way I can solve two problems, I'll make the SD card more accessible and I will be able integrate a filament guide structure at the top of this LCD part which will guide the tube in a loop over the LCD mount.

[printbus]

...it can't be in the way of the SD card (which is already hard to remove as it is).

I haven't tried it, but have you seen the SD card grip on Thingiverse? http://www.thingiverse.com/thing:370861

[gmay3]

I haven't tried it, but have you seen the SD card grip on Thingiverse? http://www.thingiverse.com/thing:370861

Yep I did see that one! It's a great idea but it wouldn't fit into the SD card reader in my laptop because when it's in there, the card only sticks out about 1mm.

[AbuMaia]

I've tried that card holder too, but it didn't hold onto the card. I've not had much trouble getting the card out of the LCD though, so it didn't bother me. I like the idea of an integrated filament guide in the side LCD mount piece.

[TopJimmyCooks]

a piece of clear packing tape folded over the card to form a flexible handle does the trick for me.

[AbuMaia]

But really... I would be very tempted to duplicate the M600 command as a stand alone routine that could be called when a condition is detected.

You think that would work? Right now the pause() routine that's activated by the switch is:

void pause()
{
  enquecommand("M600 E0 L0");
  enquecommand("G4 P1");
  enquecommand("G4 P1");
  enquecommand("G4 P1");
}

If I were to copy the contents of the "case 600" into the pause() routine in place of the enquecommands, would that work?

[Roxy]

You think that would work? Right now the pause() routine that's activated by the switch is:

void pause()
{
  enquecommand("M600 E0 L0");
  enquecommand("G4 P1");
  enquecommand("G4 P1");
  enquecommand("G4 P1");
}

If I were to copy the contents of the "case 600" into the pause() routine in place of the enquecommands, would that work?

Yes, most likely, but 'work' is the wrong word. That would be a very solid start assuming pause() is not being called at interrupt time. If so, you can't transfer control to the duplicate M600 (and modified) code. The reason I say that isn't enough and is a good starting point is because the M600 command parses command line options and you won't have any just because the switch got triggered.

Any of the code_seen() parameter parsing in the duplicate M600 code (such as shown below) will not be doing anything meaningful... In fact, they probably will be parsing (and messing up) the command line of whatever GCode command was executing when the pause() got called. You would want to hard code in reasonable values for any variable that gets messed with because of a code_seen():

 if(code_seen('Y'))
        {
          target[Y_AXIS]= code_value();
}