Resurrection code and circuit for Rostock

[robgs]

I know this idea isnt "brand new" to 3d printing, so has anyone tried to implement this open source idea to the Rostock? Seems like a pretty simple circuit.. but there must be more to it than meets the eye if we dont have an implementation yet...

http://3dprint.com/28079/wasp-start-and-stop/" onclick="window.open(this.href);return false;

[lightninjay]

Looks to me like a simple script that could be run on the rambo (or 3rd party-hosting app) that was copying over the gcode as it was written, and then deleting it from the beginning to the end, as the printer successfully ran the gcode. In the event of a power outage, the script would be ended ad-hoc the power outage, leaving you with "ressurect.gco" which, by nature, is the remaining gcode to be completed by your printer. It would maintain the necessary heat-up temperatures in the header of the gcode, and resume the exact coordinate it left off at when the power shut off.

If any of this is unclear, just ask and I'll try my best to explain it a different way.

[robgs]

I can build the power/voltage saving circuit on a breadboard, attach it to the io, and test its functionality... but would need help with the code... Have you done this yet?

[lightninjay]

No, I've been working on an honors thesis project for my University, but this kind of thing was right up my alley for after I graduate in the Spring.

[Earthbound]

May need to be more elaborate than just handshaking the completion of each line of gcode. To restart the job at the proper point, machine would need to know actual position when drive stopped. Gcode command said go to X, Y and extrude while moving. There is no measure of how much of that move was made if only monitoring gcode. A snapshot of real coordinates needs to be captured for resolving how to complete an unfinshed command. Seems possible to add that though.

[Eric]

And then theres a few details like if the motors have no power, they also have no holding torque. Gravity may pull the still hot hotend into the print and destroy it anyway.

If it's gotta be done, I'd do it a bit differently. First off, use a UPS that can run the system for at least 15 minutes...just doing that will take care of the 99% of users who have reliable enough power.

For the remaining 1%, all the better UPS's are able to inform a host if there's power, what the load is, and how much battery is left. Interface with that, and the hardware is complete.
On the software side, its a case of monitoring and having a clean shutdown sequence when the battery gets to a certain point. Moving the hot-end to a safe location should be part of that. You also have enough time to be a little picky about where the print is interrupted....one could finish a layer, for instance.

Oh, of course you also need a restart sequence, which sounds easier than it is.

[bvandiepenbos]

This could be very useful not only in the case of power outage but also having the ability to pause/resume a print would be very handy. And pause/shutdown/restart next day would be great to.

[robgs]

Well... I'll make the circuit and test the discharge time for the cap... the voltage divider they show allows for a 5.76V monitoring voltage for the arduino to sense a power failure... have to look into the IO for this on the Rambo arduino, pretty sure just goes to one of the digital 5V pIN... on the normal Mega2560 thats easy to spot but how that looks on our board i will havta research... not familiar enough just yet...
I am a ladder logic programmer and gcode is new to me... but reminds me of block programming, so hopefully i can catch on quickly.... lets do it just for kicks....

[robgs]

Looks to me like a simple script that could be run on the rambo (or 3rd party-hosting app) that was copying over the gcode as it was written, and then deleting it from the beginning to the end, as the printer successfully ran the gcode. In the event of a power outage, the script would be ended ad-hoc the power outage, leaving you with "ressurect.gco" which, by nature, is the remaining gcode to be completed by your printer. It would maintain the necessary heat-up temperatures in the header of the gcode, and resume the exact coordinate it left off at when the power shut off.

If any of this is unclear, just ask and I'll try my best to explain it a different way.

Hey Lightninjay... did you look at the code? If so where did you find it? Can you provide a link?

[lightninjay]

Sadly I did not look at the programming, just theorized about the mechanization of it after watching the video at the bottom of the page you linked.

I tend to have an overly active imagination, the actual functions of the code are not as simple as I made it seem. As Earthbound mentioned, if the power went out during the middle of a long X,Y move from one coordinate point to another, the printer would know what Z-height to go to, but it wouldn't know exactly where between the two X,Y coordinates to place the head on the segment the printer died on.

EDIT: Or possibly, even the creators of this printer didn't account for that variable, as many of the X,Y moves are routinely, fairly small and picking up with a little overlap could be insignificant.

[robgs]

Well... here's a link to the code if you wanna take a look at it.... may have to break out the ol google translate unless youre fluent in Italian...

http://www.personalfab.it/downloads/dow ... are2-0-p0/" onclick="window.open(this.href);return false;

ima look through it an try to spot the code for the resurrection... but if you find it let me know....

Actually... it looks like the code descriptors are bi lingual... thats great! Should make this a little easier...