Z height back function?

[Đức Nghĩa Thân]

I often get fault because the filament was jammed when R2x is running and have to start again from begining. I think there are so many people like me.

With the Z height back function, after detecting machine jammed, we can go back to the position jammed then continue from that. The important issue is position of z layer that was jammed.

I think we can locate z layer by manual: first we move spray head to position "far home" (similar the position that we change filament) to get the value of Z, then for manual adjust Z position (like the Zog Mode) to the layer jammed. After finishing set the z position, the machine will read the file and continue to run at the position corresponding to the position z we have set above.

Sorry about my english.

[Jetguy]

The problem with all that is, generally the X and Y homing position is not nearly as accurate as the Z axis homing.

For example, this is why you see a double home on Z at the start of each print. We home fast so as to not take forever if the platform is the furthest away, but then after the first home, we back off 5 or 10mm and then home again at a slow rate to prevent overrunning the switch. You see, it still takes time for the microprocessor to acknowledge when the switch is tripped and then stop sending pulses to the axis. At speed, we could actually overrun the trip point by a few steps.

Since in most cases, X and Y homing is only about trying to get the print centered into the build area of the platform, these fractions of a mm are not critical and thus we don't normally double home X and Y.

So that is just part of the problem right there.

Then, the next issue is that we put the start.gcode into the file not like a script or function called at the beginning of the bot. You might have missed previous discussions about the controller for the bot but basically, it's COMPLETELY maxed out flash space wise for current firmware. There is no room for even the smallest of additional functions. The alternate Sailfish firmware had to start removing some of the lesser used scripts and functions in the firmware to add new requested ones. Examples of added functions include large card support for greater than 2GB SD cards, improved error handling, ditto printing, gcode temperature override, P-stop, and so on.

Not to mention, recent discussions that stock firmwares have some bugs in the SD card library and can actually corrupt files on the SD card when just reading them.

Let me give a giant thanks to Jake, Dan, Jetty, and others who helped implement P-stop which I discuss later in this post!!!

 

 

So, from a technical standpoint, there are so many problems with your idea it's been discussed before and is just not possible. To implement it requires a massive overhaul of the entire system as we know it. The current system is not "smart enough" to read the start.gcode and get the machine set up and homed to a precise and repeatable place to resume a print. Further, it cannot currently parse the entire file searching for the gcode at a certain Z height to begin printing from the middle of a file. Then we get into other major logistical flaws. The biggest one is we home Z min. If there is an existing print on the platform, we cannot home Z min. Because we use steppers, any time they are disabled and not holding, there is no chance they will not be moved and thus we lose all positions.

 

Now, rather than leave you with no hope, I requested a special feature get added to Sailfish called Pause stop (AKA P-stop). We can pause the bot and this keeps the steppers enabled and even possibly the heaters on depending on how you set up the function. P-stop is basically a modified version of the normal pause function that is triggered by an input to the motherboard. This triggered input can be anything, a button, a sensor, and in particular, an entire separate microcontroller with multiple sensors could be used. There are a couple of starter designs out there, but one thing that needs developed is a custom filament drive in which the motor and the idler wheel which pushes the filament against the knurled wheel on the motor both would have rotary encoders. You would have to sense 3 things here.

Pulses from the stepper driver indicating when steps are called for.

Count from the motor side encoder to detect skipped steps

Count from the idler to compare to the previous 2 things for filament slippage against the pinch wheel.

 

Then, we also cannot forget other causes such as filament out detector at the spool and spool drag caused by tangles. Also, if we are going this far into print error detection, we might as well sense incoming AC power to a UPS.

A single Arduino board could easily combine all those signals and trip points to send the trigger command to initiate a pause if any condition is met. This would pause the print and send the bot into a lower power mode but still retain positional accuracy and the exact point in the gcode where we could resume the print. If combined with the UPS, this could leave the bot in this state for some time as long as the UPS could keep the bot powered. I think this represents the best case scenarios since it's been discussed that it's basically not possible to write to the SD card given all the limitation and common errors we are seeing today with the current hardware. Simply put, this is about the best scheme we have going.

 

This is about the only way today without a complete re-design of the entire system we could detect comprehensively common failures and be able to reliably and easily resume a print once the problem is corrected.

It's up to you folks to help design and implement the sensors. The function exists only in Sailfish firmware, you just have to use it.

http://www.thingiverse.com/thing:107775 My preliminary version of a pre-feeder and spool tangle detector

http://www.thingiverse.com/thing:83274 Is an example of a very simple out of filament detector

Here is great information on the Replicator 2 series (2 and 2X) implementing P-stop

http://www.extrud3d.com/p-stop

 

Now, recently I had hands on a Cubify CubeX and they do have exactly what I described for the filament feeder. They have 2 encoders, one on the motor shaft, one on the idler and both are combined with the stepper input control to determine when filament slippage happens in the filament feed section of the extruder.

It's basically an aluminum Wade's style setup but most shafts extend to the face of the filament drive and had optical (black and white patterned) discs that obviously where being read by a PCB in front of it, most likely with infrared detectors, No reason many of the off the shelf magnetic rotary encoders couldn't be used.

 

Again, to recap, the problem is there is NO SPACE for even the smallest of features or functions left in the firmware. At this point, you have to start deciding what other functions are less useful. Rather than mess with firmware and possibly cause print performance issues, it's smarter to use this built in P-stop function and let an external microcontroller do the sensor checking and determine when a failure happens to then trigger the main controller to pause.

Also, keep in mind that P-stop and pause in general must clear the command buffer which might be as long as 16 more gcode segments. SO pause isn't instant and there is no good way around that. Your detection system needs to be sensitive and detect a failure early enough that the print is paused early on when the failure has just begun. But, because I believe we actually see a fair amount of slippage and skipped steps in the extruder under normal conditions, this may be a lot of perceived false or early triggers that also could frustrate the user. You would want to be able to tune the sensors and trigger points specific to your bot and your running condition as well as "acceptable" failure rate.

[Dan Newman]

As mentioned previously, there's just not enough spare program space on
Makerbot Rep 1, 2, or 2Xs for this without removing other functionality
from the firmware. Thing-o-Matics have twice the program space so there's
room on them for this, but then ToMs simply do not jam or air print anywhere
near as frequently as the Rep 2 and 2X. (Rep 1s are also more reliable
in this specific regard.)

Comments

1. You can do this manually by
a. Note the bot's current Z home position.
b. Heat the bot's build plate up if you were printing on a heated plate.
c. Manually park the extruder nozzle where you think the last layer ended.
d. Run a short script which first homes X & Y (so as to get the extruder
nozzle clear of the model). Then have the script define the current
position to be Z=0. Then have the script carefully home Z twice and
then save the current Z position to the Z home offset.
e. See what the Z home offset is and use it and the Z home position from
step a to compute the Z height where the model ended. If the Z home position
from a was 0.00 mm and now the Z home position is -33.1 mm, then the
layer where printing ended was 0.00 - -33.1 mm or +33.1 mm.
f. Restore the Z home position from a.
g. Hand edit the gcode to carefully home X, Y, and Z twice each. Remove
all the printing gcode up to the layer height determined in e.

Would be nice if the slicers could visually help you in doing step g
and then output updated gcode for the print. The slicers could also,
over USB do steps a, b, d, e, and f for you. This makes it easier for
many people without having to update the firmware or otherwise figure
out how to fit it in the already full microprocessor within the bot.
Thus, this issue can largely be handled from the slicer/desktop side
without a firmware change.

Comments continued

2. Would be even nicer if the hardware didn't experience extruder jams. Before
the Rep 2, this list rarely saw postings with people having air printing or
otherwise jammed extruders. So, MBI can produce bots with much higher
reliability in this area. Put differently, I'd rather see MBI put
their efforts into the underlying problem -- jams & air printing --
than methods to patch up the errors caused by the problem. But then
MBI is a large company: they could work on both at the same time
if it met their priorities to do so.

3. Consider using (or developing) hardware which can automatically detect
problems of this nature and then automatically pause the print and
then resume it after the issue is corrected. People are doing this
already with modifications to Makerbots and other DIY 3D printers.
Would be nice if MBI could work on this as well.

Dan

[Jetguy]

One comment:

You really cannot do step D in many cases. Due to the gantry design, unless he part is very small, the gantry still covers much of the build area space even when in the back corner for homing. Thus, because we home Z min, 99.9% of the time you aren't going to be able to home Z min without running the already printed part into the gantry.

 

If it was small enough to clear the gantry, then you might as well just restart the print given the fact that even with effort, the odds of success are very low. If it's too big to clear, you'll basically have to eyeball it by hand anyway and all bets are off.

 

I'm not saying it cannot be done, it's just one heck of a lot of work right now praying you can recover the print job and certainly, the novice who may not fully grasp the entire gcode system has a significant learning curve to be able to pull this kind of recovery off. I've seen James Armstrong pull this kind of amazing recovery off on a Rostock, but the other advantage there is the Rostock keeps the current position once homed. As long as you don't disable the steppers it knew where it was. I personally, even with all my knowledge have never even attempted this on a MakerBot, just because I knew the odds of me getting it registered back over the print were slim to none.

[Dan Newman]

On 19 Oct 2013 , at 8:50 AM, Jetguy wrote:

> One comment:
> You really cannot do step D in many cases. Due to the gantry design, unless
> he part is very small, the gantry still covers much of the build area space
> even when in the back corner for homing. Thus, because we home Z min, 99.9%
> of the time you aren't going to be able to home Z min without running the
> already printed part into the gantry.

Agreed. And, as I wrote before, I personally prefer solutions to the underlying
problem rather than accepting the problem as is and attempting to live with it.
But then, MBI is large enough that it could work on both issues if they thought
it warranted being addressed. (They certainly want to make more reliable bots,
so they assuredly work towards fixing the underlying problem. Just wish they
hadn't taken that step backwards in the first place between the Rep 1 and 2.)

Dan