Printing from SDCard while uploading g-code from Host

One of the problems with printing with from an SD card is the slow transfer from the host to the ATMega. So, for big files (5 MB or more), we have to wait for the slow upload to complete before we can start printing. In this case, I usually pull out the microSD card from RAMPS, plug it to the host, copy the file after renaming it, unplug from host and plug it back to RAMPS for printing instead of uploading it. I wish there was another way. Wouldn't it be nice if we can upload the g-code and the have the printer start printing from SD Card as soon as possible, while the upload continues. I think this is how the Up! printer works.

Is there a firmware that do this? Is there a reason why this can't be done?

Why firmware? Sounds more like an option for the host. The host knows when upload is finished and could send the start command right after that. No need to modify the firmware for that. Maybe I add this option to my host. And before you ask, I'm working on the MacOS X version, but unfortunately mono has some strange behaviour on mac which needs some workarounds.

Until then you might end you G-Code with

M29
M23 filename_form_upload
M24

Repetier-Firmware will ignore the second G29 and I'm quite sure Sprinter & Co will do the same.

Edited 1 time(s). Last edit at 11/25/2011 01:39PM by repetier.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

I think you meant M29 and M23. Won't the firmware still wait for the completion of the upload to get to the end of the file where these additional commands are before starting the print? So, this would be a slight improvement since I can leave after starting the upload and the printer automatically starts when it gets to the end of the upload. But most of the time, I like to watch the first layer to finish before leaving the printer. So, I would still have to wait around for 15 to 30 min or more to wait for the print to start.

Yes I meant M29/M23 changed that.
If you upload a file, the host does M28 sends your G-Code and stops with M29. If your code contains M29 the printer will think uploading is finished. Then M23/M24 select the file and start the print. After that the Host sends its M29 but since the firmware has already finished uploading, nothing should happen.

I see now what you really meant. You wanted to start during upload!

Why do you want this? If you have communication errors or a hardware failure you still have a ruined print. What is the advantage to direct print? The only advantage I see is, you can shut your computer down, when the upload is finished.

I'm not sure you can do this with current firmware. You need to open the file you are currently writing. Not sure the fat-io library is designed for this and my Sanguino has not enough ram if it is possible. Greater MEGA2560 based controller may be able to open 2 files at once with their larger ram.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Quote

Why do you want this? If you have communication errors or a hardware failure you still have a ruined print. What is the advantage to direct print? The only advantage I see is, you can shut your computer down, when the upload is finished.

I usually print from the SD card since it allows me to use the computer for other things, like designing and slicing the next file for printing, without worrying about affecting the print quality. I've noticed that with printrun/sprinter combination on MacOS (probably true with marlin and repetier firmware too), I tend to get blobs in the print when the printer pauses due to communication delays if I use the computer heavily while printing. I suppose that this won't be necessary if the upload is fast. But going through the Arduino at a few kbyes/s is very slow.

> I usually print from the SD card since it allows
> me to use the computer for other things, like
> designing and slicing the next file for printing,
> without worrying about affecting the print
> quality. I've noticed that with printrun/sprinter
> combination on MacOS (probably true with marlin
> and repetier firmware too), I tend to get blobs in
> the print when the printer pauses due to
> communication delays if I use the computer heavily
> while printing. I suppose that this won't be
> necessary if the upload is fast. But going through
> the Arduino at a few kbyes/s is very slow.

A heavy loaded computer can have this effect. It's not the pure speed but sometimes the host doesn't get enough time to send the next commands. Had the same problem on windows. Sprinter is more affected from this then Marlin or Repetier-Host who have a large move buffer. But with wrong timings there is always a chance. So you are right, that only printing from SD can avoid this in any case.

If you don't want to remove your sd card, you can still increase communication speed and use data compression. Thats what I do with my Host/Firmware. Speed 250000 Baud and the binary format is 50% shorter compared to ascii format.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Quote

If you don't want to remove your sd card, you can still increase communication speed and use data compression. Thats what I do with my Host/Firmware. Speed 250000 Baud and the binary format is 50% shorter compared to ascii format.

I've already tried running Repetier host and firmware on Windows XP running under VMWare but I was unsuccesful and I didn't have enough time to figure it out. I'll try again later. I'm looking forward to the Mac version.

the upload from the serial interface is what makes sd reads slow especially if you are using spi hardware. I have just been experimenting with pronterface running at 1000000 serial speed. baud works ok , and pauses basically are no longer there. what was needed was reducing buffer to 64 char and 2 lines of it, that way it would all fit in the hardware buffer and not get lost, and the arduino is fast enough to process the buffer! printer works ok i guess with atmega. the best way is to go teensy, i upgraded oneof my machines to that, and without sd card it works very very fast

if you want to change spi timing i think it is in sdcard.h folder in firmware.


i think the serial send rate at 1000000 is faster than a buffer could process the data anyway. sprinter buffer ability needs redesigned as it sucks the life out of your firmware when it becomes larger.

now after all my playing around, i lost ability to init sd card on atmega , but that's ok for now,...

YMMV...