I will dig the rpi out and see what happens when I have upgraded it, I had almost given it up... I have been using matterhackers for the last week with a windows tablet but I would rather the rpi..
That is looking good now, the only waits were two that were waiting for the bed to be heated. That was with a simple Marvin keychain, see how it goes with a complex one.
Two waits at the start (acceptable) and one at about 19 minutes into it, I don't know why because the printer is plugged directly into Raspberry pi 2 and I am using a new power supply just to be sure it has enough current.
I will try a different file and see how it goes with another one!
I have set the Communication Timeout to 50 and it looks better.... The bed heat is not going off after a job finishes even though it is being sent! I thing at a time I guess...
I can not say why you are getting the wait. Something prevents sending the command for a second. I don't see them so the guess is that something keeps the pi busy for a short while. Has it enough cooling? Mine got a bit unstable after a while when I had it in a double housing.Could also be a cron job starting also I would assume that programms still get their time. Last thing that you could test is not having a browser open while printing. Both are separate processes so nearly no influence is there, but until we know the source of the problem we can assume everything as a reason.
The timeout has no effect on this problem. It is for more extreme problems where firmwares ends no wait at all.
Yes.... I will next try running a job with no browser running.
The pi2 is about as raw as it could be, no display, no video just the printer and wireless lan card. I usually ssh in to it from my Mac.
I suppose I could try printing a file off the memory card too that would prove the printer. The printer is fine under repetier-host so it is probably ok.
Firmware sends wait if it does not get a command for a second while buffer is empty. So it is not a firmware thing. You could install the server on the mac and see if you still get waits. Mac ist so much faster that even a browser would not make a difference.
It would appears to be working correctly on my Mac, i7, 500Gb SSD, 8Gb etc... That is a fairly decent machine, I have been printing all day and I have only seen one wait right the beginning of the third file. I would really like it to work on the raspberry Pi 2 but if it is going put the waits in!
I may try reloading again and see if it fixes it....
Tried a completely fresh load on the Rpi2 with 8 Gb memory card, upgrade and updated to the most current raspian and still got a heap of (wait) in the log for the print job.
Put the same card into a RpiB+ and still getting (wait) in the printer logs, same job...
The only test to be done will be repetier-host now!!!
Ok, now I really wanted to know it. I hooked up the Pi2 with server and web browser running on it and an other connected to it and printed an hour. No waits at all in the log, not even at the beginning. So I think the pi is very well to handle this and your combination must be part of the special problem.
Things to test:
- Send M111 S24 and run a job. This only does communication no moves etc get executed. I use this always for communication testing.
- Use a other (faster) sd card on the pi. Not sure what you use and I also think it should not make a difference and maybe you already did it.
- What printer board are you using. I run my tests now against a Arduino Due driven board.
First configuration is rpi2, powered hub, printer plugged into hub, WIFI lan card plugged into hub, power supply plugged in to the hub. Rpi2 powered with it's own power supply. Did the M111 etc and suffered two waits. The file would have taken 13 hours to print normally it probably took one and a half hours to do the test print.
Second configuration is rpi2, printer plugged directly into USB, WIFI lan plugged directly into USB. Same file test printed and this time there were No Wait(s).
Card is Samsung 32Gb and Printer is using Rambo 1.3 controller (seemecnc).
I won't say fixed yet but it is looking good so far. I will do some prints tomorrow afternoon and if they pass I will be very happy.... Thanks!
Interesting result. I also print without any hub since the Pi 2 can have powered outputs and with 4 usb I had no reason. Will test with usb hub when I get the time. But might also be depend on the hub it self if that really is the cause. But it is at least one more device that could fail or at least cause troubles. Could also be the usb cable only adding some error and if correction takes to long we get a wait. Only speculating here.
Didn't get too much printing done, the one I did do did not have the waits but it was only a 20 minute file. I must have done something to the printer last evening, told it to print a couple of times and it was printing about 200mm above the table. It must have gotten a corruption, reset the z height and it was going again.
Now that it is finally working I have got another powered hub which is totally different so I will try that later.on to see if it works. Not really a concern now that it is working!
I am going to take the baud rate down, I have been using 250000 and it may be the cause. Can't see any other area that would be the cause and I will beat it!
I am going to take the baud rate down, I have been using 250000 and it may be the cause. Can't see any other area that would be the cause and I will beat it!
I have knocked it down to 115.200 so we will see how that goes... I didn't what your baud rate was, I just thought everyone was up at 250000.
This is an 8 hour print job. The last one had six waits and couple of checksum errors but that was with the faster speed.
I think also it is pi related, but as I said I have no waits when printing with it. Didn't you have also no waits when connected to pi directly and not over a hub? I remember such a discussion.
Comments
pi@raspberrypi ~ $ sudo dpkg -i Downloads/Repetier-Server-0.60.2-Linux.deb
dpkg: error processing Downloads/Repetier-Server-0.60.2-Linux.deb (--install):
cannot access archive: No such file or directory
Errors were encountered while processing:
Downloads/Repetier-Server-0.60.2-Linux.deb
pi@raspberrypi ~ $
The pi2 is about as raw as it could be, no display, no video just the printer and wireless lan card. I usually ssh in to it from my Mac.
I suppose I could try printing a file off the memory card too that would prove the printer. The printer is fine under repetier-host so it is probably ok.
I may try reloading again and see if it fixes it....
Second configuration is rpi2, printer plugged directly into USB, WIFI lan plugged directly into USB. Same file test printed and this time there were No Wait(s).
Card is Samsung 32Gb and Printer is using Rambo 1.3 controller (seemecnc).
I won't say fixed yet but it is looking good so far. I will do some prints tomorrow afternoon and if they pass I will be very happy.... Thanks!
Now that it is finally working I have got another powered hub which is totally different so I will try that later.on to see if it works. Not really a concern now that it is working!
Got to get busy printing.....
I am going to take the baud rate down, I have been using 250000 and it may be the cause. Can't see any other area that would be the cause and I will beat it!
I have knocked it down to 115.200 so we will see how that goes... I didn't what your baud rate was, I just thought everyone was up at 250000.
This is an 8 hour print job. The last one had six waits and couple of checksum errors but that was with the faster speed.
I will have to get back on the raspberry pi2 and try and find out why the wait(s) are happening I am pretty sure it has to be in the Pi somewhere...