Pronterface doesn't show print progress for SD card prints

Why can't the SD card print progress be displayed on the pronterface interface? Mine hangs at 0%. It displays g code and temps so it should be able to do this. I want to go have a beer but have to wait until this job finishes...

---

Ormerod 313

Probably because the DUET is now running by itself (you can unplug the USB while running from SDcard) and no feedback message is sent back....I guess ;-)

But I get all the Gcode lines and the temps as feedback. Which means I could definitely get some progress feedback as well.

Hi tracyb!

When the printer is printing, it is only transmitting debugging information,
Pronterface does not try to understand this info, it is only the messenger.

It does not know which file is printed, how large it is, or how long it takes!

The Ormerod should be able to read the size of the file, but that does not
tell it how long it takes to print that gigantic collection of gcode commands.

It would need to 'virtually print' the entire file first to make an estimation...

The Ormerod could tell Pronterface how much % of the file has been processed,
Pronterface could then show a somewhat accurate guesstimation of the total time.

But that would take a lot of developer time for a not-so-accurate print progress...

Since you already leave your PC on, you could try the improved USB printing.
It is currently at a usable state, and software testers are more than welcome!

---

RS-Online Ormerod #263, Kossel mini with Minitronics, Prusa i3 MK2

I understand. I do the the same. I don't think there is a line number/progress feedback from the Duet to Pronterface. What you see on the screen is the current Gcode that is being executed on the Duet.

Funny. It seems the Duet can send the Gcode fast enough over USB to the PC but not the other way around ;-)

So in summary you see the Gcode but neither the Duet or the PC/Pronterface knows how far it is when crawling through an SD file. What RRP needs to do is to send back a command (like te temperature) that states the file size and current file position. And then update Pronterface to interpret that. But that is easier said than done. Unless you pre-analyse the file on the PC you cannot determine time left. The first half of the file might be short straight line sections and the other half bigger arcs. So when at 50% through the file (which maybe took 30minutes) the remaining 50% might take another 3 hours.


BTW.
I just got my own controller going this morning with a single stepper (for another machine). I am using the Pololu DRV8825 stepper drivers (but will eventually just use the chips straight on my board. My controller is based on the SiLabs F345 chip (also USB, but I am not going to use it for several reasons). The micro only has 2kbytes of RAM, but that is enough to use as buffer space (probably only 1K). The Gcode is broken up into little vectors (lines, arcs etc...). Each vertex consists of a 8 bit command, and several 4 byte floats (depending on command). So a G1 command (for e.g. the 3D printer) will end up as 1byte for the command and 16 bytes (X,Y,Z,E) for the data, thus 17 bytes. I am still thinking about doing arcs inside the controller or at PC side. But lets assume the majority of of the commands are little line segments then I will have enough buffer space for 60 lines per 1Kbyte of RAM. At 9600bits I should be able to replenish the entire 1kbyte buffer in 1 second. The controller now feeds back the buffer level and the PC only sends more data when required. I will use a common Prolific USB to RS232 (or straight from multi-io card). I like to keep it RS232 because this will allow a 2nd microcontroller to be used as a file server (for printing from SD) without any major drivers (like USB and Ethernet). PLUS. My board is already compatible with an Ethernet module (and WIFI). These little things cost around $35 and with e.g. wifi i can have hundreds of CNC machines running at the same time. So the idea is to split the complicated maths to the PC and let the controller just control pulse and direction. The ultimate would be to use an FPGA (with built-in CPU, hard or soft IP). The DRV8825 can be clocked upto 250kHz. You cannot reliably do this with a microcontroller. In VHDL I can easily implement independent spline counters for each axis in parallel, so every stepper movement is in sync with the others. And all of this, including Ethernet, will still be cheaper than the Duet. I am doing this for my LDI machine, but might eventually sell units for the Ormerod and other 3D printers.

In Pronterface you can use "Load file" to load the same gcode file from the pc before starting. Then you get a few statistics in the text window, including a time estimate, that might be a bit better than having nothing to go by.

You can get a list of the files that are on the SD card. If you could also get the file size then you could do it.

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

It's on Adrian's to-do list to add a feedback mechanism to SD printing, so it does tell you how far along it is. It's best to calculate it from the lines of gcode, as if you do it by layer height, you don't get a particularly accurate figure, as the number of gcode lines per layer tends to reduce the higher you go.

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 01/19/2014 06:46AM by droftarts.