GCode Queuing for ABP

[D1plo1d]

It would be nice for ABP Makerbot people if ReplicatorG had the ability to queue parts.

For example if I start printing something that takes forever like the bunny and then continue surfing thingiverse and find more parts I'd like to print I have to wait until the first set of parts is done printing be able to load up the second set of parts. This sort of situation is made even worse at open nights at hackerspaces when 3 or more people all want to use the printer but have to wait for it to be available to load up their print (this also causes printer downtime between prints, causing many a sad pandas!).

A graphical print-job queue that just appends the gcode of the next object to the previous and allows you to add and remove future items would be extremely handy for this sort of operation. Any interest in implementing this?

[D1plo1d]

I am working on this.

[phooky]

Hi! We were planning on implementing queueing in ReplicatorG, but there's enough going on that we haven't had time to get started on it. We're building some backend mechanisms that will make this easier, but they most likely won't be ready until December, so the plan is to hack something in before then.

If you're already starting on this, let me know how it's going and how I can support the work you're doing.

[D1plo1d]

I hacked the gui together last night (actually in a service station between Boston and Toronto.. long story) and I think I've got the functionality coded.. We're going to be testing it tonight at Hacklab.to. Bounties always help us starving programmers but I'm posting this regardless because RepG needs this little extra bit of awesome :)

Oooh, also the simulation driver doesn't implement position stuff.. if it was able to simulate prints when you click build that would allow me to use those same mechanisms to simulate my build queue and help speed up my testing.

Screenshots

Queue Loaded (note the build queue button in the main button panel): http://imgur.com/kpbD9.png

No Queue Loaded: http://imgur.com/B0ySo.png

[phooky]

This looks fantastic. I'm on the verge of releasing 0020, and I'd love to talk to you about getting this in 0021. The trickiest bits in the design I was working on were the interface for queueing builds that were already on the SD card, as well as working out if it made sense to let the bot sit idle for 5-10 minutes while a build was uploaded to the card before a print.

We're also not above a bit of a bounty for folks who help us with big chunks of functionality like this-- drop me a line and let me know what you're thinking!

[ssd2]

Suggestion here... don't bother uploading to the card via serial! Instead, put the files on a second card via direct interface (I love my SD card slot on my computer, as well as my USB adapter), put a marker in the queue that sets off an alarm on the computer, and have it tell you to swap cards!

Or just set off the alarm when the queue empties, I suppose.

[D1plo1d]

Yeah serial write to SD speed is definitely a problem with the current setup.. I think your way would work well for current hardware but what I'd really love to have is a machine that can actually write to SD with some speed. We're just working around a major hardware limitation with software hacks until then.

Expanding upon your idea though since we are stuck with the current hardware at least for the immediate future I think we could load the whole queue to SD.. 2Gb SD cards cost < $10 and gcodes are minuscule in comparison. Alarms would be used to update the card when you get to models you append to the queue after you wrote the SD card.

[ssd2]

To continue this idea... I do a lot of repeat prints, and keep copies of those likely to be reprinted on some or all of my SD cards. The queue mechanism should be able to trivially handle adding one of those to the queue of course...

I suppose if you wanted to really integrate the card swapping, you could add the print to the queue, have it automatically copy the file to a card in the local computer, when the queued print comes up, have it beep you to swap and wait some delay for it to happen. If the delay expires, look down through the queue for one that is on the current card and start anyway...

Another possibility would be to trickle the part to the SD card through the slow serial while another part is printing from the SD card. However, this might make the already flaky SD card random file deletion problem worse. And I've noticed that it takes maybe 80% of the print time to transfer files through the serial, so unless you're queueing a short part while a longer part prints, this might not be terribly useful.

[D1plo1d]

Yeah, I keep wondering how much of SD card sloth is a software problem and how much is hardware.. any comment on this phooky? Perhaps this is best suited as a separate issue.

Certainly with a little more SD write speed and some form of binary gcode protocol (cough cough * http://github.com/D1plo1d/cnc.proto *) we could implement the SD card trickle your talking about... hell maybe the binary protocol would be enough on it's own to get sd card print speeds :)

[ssd2]

re: binary protocol Too late! I believe the s3g format that makerbot uses now is binary.

[D1plo1d]

so it is, well then.. I think for now we're SOL unless someone wants to go and optimize the sd card write stuff in the firmware.

[phooky]

The sluggishness is primarily due to the low speed of the serial connection and the buffer behavior of the FTDI cable, not the SD writes.

[phooky]

This issue didn't get migrated to lighthouse due to bugs in lighthouse's API. We'll keep tabs on this manually.