Assistance needed - unable to queue up content

[akalyan]

Hi,

I'm super excited about this project and can't wait to get printing!  However, I'm stuck!

The problem:

- I'm able to see my printer when I go to http://printer.gofreerange.com/my-printer.  I get: http://printer.gofreerange.com/my-printer/0j1s1d6b0o2l2c5t.

- I'm unable to queue up any jobs to print.  If I try to print a test page, say with HTML input, it returns: {"response":"ok"}, but nothing prints

My setup:

- Adafruit IoT printer

- I've modified the printer.ino sketch to ignore the errorLED, readyLED, and the button

- The sketch successfully tries to download content, getting the following debug prints when I serial monitor:

1499: ID: 0j1s1d6b0o2l2c5t

3844: IP: 192.168.1.105

3852: Attempting to connect to printer.gofreerange.com

4345: Waiting for data

4365: Waiting for data

4389: Waiting for data

4415: Waiting for data

4440: Waiting for data

4464: Waiting for data

4490: Waiting for data

4545: Content length: 0

4558: Waiting for data

4566: Server disconnected

4743: Bytes: 0

4743: Duration: 898

14748: Attempting to connect to printer.gofreerange.com

15037: Waiting for data

15057: Waiting for data

15083: Waiting for data

15110: Waiting for data

15135: Waiting for data

15162: Waiting for data

15187: Waiting for data

15244: Content length: 0

15258: Waiting for data

15266: Server disconnected

15447: Bytes: 0

15447: Duration: 704

(rinse, repeat every 10 seconds)

- CURL produces similar negative results: 

> curl -H "Accept: application/vnd.freerange.printer.A2-raw" -H "X-Printer-Version: 1.0.5" -X GET "http://printer.gofreerange.com/printer/0j1s1d6b0o2l2c5t HTTP/1.0"

> (no output)

Any ideas?

Thanks!

Atish

[James Adam]

It looks like I failed to ensure the new database connection was configured for some of the out-of-request job processing; I'm going to restart the failed print jobs now, which should hopefully send all of the print attempts that you tried.

- James

--
You received this message because you are subscribed to the Google Groups "Printer" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/gfr-printer/-/0sg-bOyX2UcJ.
To post to this group, send an email to gfr-p...@googlegroups.com.
To unsubscribe from this group, send email to gfr-printer...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gfr-printer?hl=en-GB.

[akalyan]

Thanks for the speedy response, James!  I verified that I can see my archive now.

I'm still having a problem and, although this might not be the best forum, I thought I'd seek your help first.

When I attempt to print something, the data now makes it all the way from the server to my ethernet client, but still no actual printing.  Here's what I see when I monitor the serial output:

132098: Attempting to connect to printer.gofreerange.com

132392: Waiting for data

132413: Waiting for data

132441: Waiting for data

132467: Waiting for data

132495: Waiting for data

132521: Waiting for data

132549: Waiting for data

132576: Waiting for data

132602: Waiting for data

132661: Content length: 1793

132898: Waiting for data

132898: Waiting for data

132899: Waiting for data

132912: Waiting for data

132939: Waiting for data

133134: Waiting for data

133135: Server disconnected

133292: Failure, content length: 1793

length: 1793

133293: cache: 0

133298: Bytes: 1793

133319: Duration: 1208

It seems to be failing while writing to the cache (code in question: https://github.com/freerange/printer/blob/master/printer.ino#L202).  At first, I thought it's because my SD card was incorrectly formatted.  But I formatted and re-formatted the card with the official SD formatter (https://www.sdcard.org/downloads/formatter_3/) as FAT32 (although it was on my mac).  To test the correct formatting, I changed my initSD function to:

inline void initSD() {

  pinMode(SD_Pin, OUTPUT);

  if (!SD.begin(SD_Pin)) {

    // SD Card failure.

    terminalError(2);

  }

  

  /* test that it can write to the SD card */

  File myFile = SD.open("test.txt", FILE_WRITE);

  if (myFile) {

    debug("Writing to test.txt...");

    byte written = myFile.write("testing 1, 2, 3.");

    debug2("wrote: ", written);

// close the file:

    myFile.close();

    debug("done.");

  } else {

    // if the file didn't open, print an error:

    debug("error opening test.txt");

  }

}

test.txt was created and written to with no problem.  Still I can figure out why "cache.write(client.read());" writes nothing to the file (I've also verified that the client.read() contains data when I just debug output the results).  

I'm so close, I can feel it.  Your help would, again, be much appreciated.

Thanks!

-Atish

[Andreas W]

Hey,

i have nearly the same issue i think it is the size of the content.
Small content isnt the problem, but larger content make an error:

306731: Waiting for data
306758: Waiting for data
306785: Waiting for data
306886: Content length: 36025
317946: Waiting for data
317946: Server disconnected
317947: Failure, content length: 36025
317977: length: 18617
318002: cache: 18617
318031: Bytes: 18617
318047: Duration: 13676


Is there an timeout or something else which can be altered??

[James Adam]

I saw problems like this when I was debugging the ethernet connection, but I never really got to the bottom of it. I would occasionally see the transfer of data stall, or connections close before sending the full content to the Arduino. These issues are the whole reason why the sketch checks the "Content-length" header in the first place!

If I were you I would try and rule out as many variables as possible. Does the problem occur with different wifi networks? Does the problem occur if you run a local backend server and connect to that over Wifi?

If you're still seeing problems, you can certainly use tools like Wireshark to inspect what's happening on your local network, but they are very advanced and I definitely wouldn't recommend them to anyone who doesn't have a reasonable understanding of TCP/IP and networking.

I'm sorry that I can't be more helpful; debugging hardware is particularly hard, and you have my genuine sympathies!

- James

--
You received this message because you are subscribed to the Google Groups "Printer" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/gfr-printer/-/A09XpO0TPCQJ.

[Andreas W]

I really tried nearly anything, different networks different hardware (router), the gfr backend and a local backend - it ends up in a
non iot specific sketch and an simple file with many chars (up to 20kb filesize) and i get still the same error - an idea would be to split the
file into some smaller files and put them together if download completed, splitting could be based on content-length but i dont get in it to
write this kind of function for the arduino... dont know how to just download a specific part of a file!?
But that would be just a workaround as it should work in one file download...

The problem is that the file is deleted from the backend server once it get touched - without to check if it was transferred completely - perhaps
in one of the next releases the queue can be cleaned up with an extra request from arduino when file is really pushed to the printer?! (for sure we can
not check if it was really printed...)

[James Adam]

On 31 Oct 2012, at 16:30, Andreas W <nibelu...@googlemail.com> wrote:

> I really tried nearly anything, different networks different hardware (router), the gfr backend and a local backend - it ends up in a
> non iot specific sketch and an simple file with many chars (up to 20kb filesize) and i get still the same error - an idea would be to split the
> file into some smaller files and put them together if download completed, splitting could be based on content-length but i dont get in it to
> write this kind of function for the arduino... dont know how to just download a specific part of a file!?
> But that would be just a workaround as it should work in one file download...

Making the download robust is a really tricky problem. As it stands, the Arduino sketch is nearing the limits of what can be stored in the flash memory of most boards, so it's unlikely that you'd be able to reliably stitch the data back together again.

> The problem is that the file is deleted from the backend server once it get touched - without to check if it was transferred completely - perhaps
> in one of the next releases the queue can be cleaned up with an extra request from arduino when file is really pushed to the printer?! (for sure we can
> not check if it was really printed...)

Sending an acknowledgement of download is definitely an interesting idea, and could be worth investigating, as along as you don't hit sketch size problems (see above).

Has anyone else been seeing regular download issues?

[Andreas W]

Am Donnerstag, 1. November 2012 22:57:58 UTC+1 schrieb James Adam:

On 31 Oct 2012, at 16:30, Andreas W <nibelu...@googlemail.com> wrote:

Making the download robust is a really tricky problem. As it stands, the Arduino sketch is nearing the limits of what can be stored in the flash memory of most boards, so it's unlikely that you'd be able to reliably stitch the data back together again.

As in case of the low memory i thought about replace the arduino with an raspberry + its cheaper even with wifi adapter...
I have ordered two raspberrys and will try the script found here in the group, is there some delelpment to add the button and leds??
I really like the idea to ssh to my device to see whats going on and the possibilities are much bigger than with an arduion.. it will be the better
way for printing things as this idea of printing IOT is so much expandable!!

Sending an acknowledgement of download is definitely an interesting idea, and could be worth investigating, as along as you don't hit sketch size problems (see above).

Again a reason to use another device than an arduino, maybe gfr should also change the point of view to focus the raspberry solution ;)

Has anyone else been seeing regular download issues?

As this issue only occurs with the wifi shield (no problem with ethernet one so far!!) i dont think some one else will report this issue too - for now.

 

[Rebecca Torrey]

I've been getting this error with a content length of 5441. It works fine until I try to send a message. Then the "Waiting for data" message repeats for 90 seconds until I get the failure error. 

[James Adam]

I'm afraid I've been unable to figure out what might be going wrong in this case. If anyone has any bright ideas about how to debug SD card writing on an Arduino, please get in touch!

-- James

[Pez Cuckow]

Hi Atish, appreciate this is from over two years ago but did you ever find a fix? I'm was seeing exactly the same issue this weekend, SD card works just fine for println but when writing in the printer code the length of the cache file is always 0!