0.60.1 Looks Good

crocky · May 2015

Just did the upgrade to the Raspberry Pi 2 and running a print through it now.

The user interface is starting to be very good now and I can extrude new filament without looking too hard

crocky · May 2015

Nice and easy to upgrade.

Using chrome on the Mac and just press the upgrade button!

When it finishes just load the page again and away she goes at 0.60.1

Repetier · May 2015

Thanks. We are doing our best to make it as easy as possible.

crocky · May 2015

Just noticed a couple of pauses part way through a couple of print files, the printer just sits quiet for a couple of seconds.... then continues on happily. The pausing does show as a blob because the tip is hot. This is on the Linux version registered with iPad informer and the printer is Rostock max 2. The Linux system is a raspberry Pi 2.. I can test it using Windows 8.1 if you like and a tablet PC.

Repetier · May 2015

What firmware did you use?

If you still have the log could you check what it shows around the time it happened? Had something similar yesterday but there the printer had 32 moves buffered and did not move for a while. It seemed like the firmware caused the pause here as I understand server can not send when firmware buffers are full and firmware was not crashed. So I now need to sort out which component causes the pause.

crocky · May 2015

I'm glad I wasn't seeing things. The firmware is the current raspian and it had update and upgrade applied to it just before the files were printed. I printed the files a second time just verify that I was seeing it, paused during the second print as well. Presently it is disconnected and I have configured a windows 8.1 tablet and it appears to be working properly. The install from an earlier version was not as simple as raspberry, I actually had to install it myself at the server. It is printing at present and when it finishes I will put the raspberry on and see if there is a log file.

crocky · May 2015

I can't see an area to view the system logs, does it have to be turned on... The doc says it is under settings---->printer, but I am not seeing it?

Repetier · May 2015

If you are inside a printer it it in the right printer dropdown menu (Settings) named "Printer Logs". The view that opens shows the logs for the last 5 prints and offers a download.

punkti · May 2015

phu, just had complete stop of the print, luckily i was standing next to the printer.

i had this in my logfile:
63 Y54.095 E3758.39676
> 21:15:30: ok 57507
< 21:15:30: N57514 G1 X26.443 Y55.385 E3758.48136
> 21:15:30: ok 57508
< 21:15:30: N57515 G1 X25.928 Y56.687 E3758.56868
> 21:15:30: ok 57509
< 21:15:30: N57516 G1 X25.354 Y57.923 E3758.65367
> 21:15:30: ok 57510
< 21:15:30: N57517 G1 X24.697 Y59.140 E3758.73992
> 21:15:30: ok 57511
< 21:15:31: N57518 G1 X23.969 Y60.314 E3758.82606
> 21:15:31: ok 57512
< 21:15:31: N57519 G1 X23.955 Y60.336 E3758.82769
> 21:15:31: ok 57513
< 21:15:31: N57520 G1 X23.246 Y60.975 E3758.88721
> 21:15:31: ok 57514
< 21:15:31: N57521 M105
< 21:15:31: N57522 G1 X22.840 Y61.273 E3758.91862
> 21:15:31: ok 57515
< 21:15:31: N57523 G1 X22.415 Y61.544 E3758.95005
> 21:15:31: ok 57516
< 21:15:31: N57524 G1 X21.967 Y61.790 E3758.98193
> 21:15:31: ok 57517
< 21:15:31: N57525 G1 X21.033 Y62.185 E3759.04517
> 21:15:31: ok 57518
< 21:15:31: N57526 G1 X20.045 Y62.454 E3759.10903
> 21:15:31: ok 57519
< 21:15:31: N57527 G1 X19.068 Y62.584 E3759.17049
> 21:15:31: ok 57520
> 21:15:32: ok 57521
< 21:15:32: N57528 M105
> 21:16:04: Warning: Communication timeout - resetting communication buffer.
< 21:16:04: N57529 M105
> 21:16:04: Warning: Communication timeout - resetting communication buffer.
< 21:16:04: N57530 M105
< 21:16:04: N57531 G1 X18.525 Y62.603 E3759.20438
< 21:16:04: N57532 G1 X17.861 Y62.602 E3759.24578
< 21:16:05: N57533 G1 X0.942 Y62.603 E3760.30090
< 21:16:05: N57534 G1 X0.431 Y62.602 E3760.33277
< 21:16:05: N57535 G1 X-17.315 Y62.603 E3761.43946
< 21:16:05: N57536 G1 X-17.859 Y62.602 E3761.47338
> 21:16:36: Warning: Communication timeout - resetting communication buffer.
< 21:16:36: N57537 M105
> 21:16:36: Warning: Communication timeout - resetting communication buffer.
< 21:16:36: N57538 M105
< 21:16:36: N57539 G1 X-18.525 Y62.602 E3761.51492
< 21:16:37: N57540 G1 X-19.068 Y62.584 E3761.54880
< 21:16:37: N57541 G1 X-20.045 Y62.454 E3761.61026
< 21:16:37: N57542 G1 X-20.565 Y62.330 E3761.64360
< 21:16:37: N57543 G1 X-21.517 Y61.998 E3761.70648
< 21:16:37: N57544 G1 X-21.967 Y61.790 E3761.73739

crocky · May 2015

Thanks punkti, that looks pretty similar to what I am getting but I can't get the log files up for some reason.

I have looked in the printer setup and I'm still not seeing it, I have General Extruder Printer Shape Webcam G-Codes but no log file. I will start a print and see whether it changes..

crocky · May 2015

Just found it

looking for it now!

crocky · May 2015

< 21:05:35: N94493 G1 X-4.03 Y21.18 E5.616

> 21:05:35: ok 28954

< 21:05:35: N94494 G1 X-4.15 Y21.24 E5.6215

> 21:05:35: ok 28955

> 21:05:35: T:227.78 B:89.87 B@:191 @:255

> 21:05:35: wait

< 21:05:35: N94495 G1 X-6.49 Y21.24 E5.719

> 21:05:35: ok 28956

< 21:05:35: N94496 G1 X-6.49 Y21.02 E5.7281

> 21:05:35: ok 28957

Then later in the file...

> 21:06:19: ok 29430

> 21:06:19: ok 29431

< 21:06:19: N94970 G1 X-27.35 Y20.78 E4.9255 F824.3

> 21:06:19: ok 29432

> 21:06:19: T:227.22 B:89.65 B@:178 @:255

> 21:06:19: wait

< 21:06:19: N94971 G1 X-27.33 Y20.92 E4.9316

> 21:06:19: ok 29433

< 21:06:19: N94972 G1 X-27.42 Y21.19 E4.9433

< 21:06:19: N94973 G1 X-27.55 Y21.24 E4.949

> 21:06:19: ok 29434

Not sure if they are the ones... I will check the other files too..

crocky · May 2015

They appear to be the problem areas in my printer logs. I do not get any error messages, just wait for a split second and then it continues on like nothing has happened but there is a blob where the tip has rested.

Repetier · May 2015

@punkti your stop looks exactly like the one I have. As you see firmware has stopped returning "ok xxxx" so server is not allowed to send new commands. What version (date if available) and processor are you using. I fear this is more a firmware bug and will try to reproduce it with a debugger. Hard work as it happens only every x hours and it often takes several tries to find real reason.

@crocky same firmware question. Your log starts a bit late. The last ok before waits is for line 94968 which is not visible. Also it seems different as I see 4 wait within one second while it should be every second, on the other side it also continuous within the same second. So it looks more like a tiny stop not what punkti and I seem to get. And without a second without commands there should be no wait from firmware at all, so this also looks not correct but would need more lines to get an idea where it came from.

crocky · May 2015

This should be dropbox link for the file https://dl.dropboxusercontent.com/u/30430570/climbing.log

Repetier · May 2015

Thanks crocky. After analysing the log I see that the server has send commands to firmware and firmware reacts as if it hadn't seen the commands. wait is only send if there are no bytes waiting. At some point firmware sees commands and continues working on the commands we had send seconds before. So these send bytes must be somewhere and that part causes the problem. From this they should be in the usb driver which waits for some reason to send the data. In my case I was using the due native port for communication. Now I switched to programming port which is a different usb connection type.

What board and firmware version are you using?

crocky · May 2015

Raspberry Pi 2 with

Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Thu May 28 20:23:46 2015 from roberts-macbook-air.local

pi@raspberrypi

Had update and upgrade installed 2 days ago.

Printer is seemecnc rostock max v2 with a standard rambo 1.3 and seemecnc repetier .091 software.

Anymore, just ask

crocky · May 2015

Printed another different file and ended up with six wait at various places, I think I will try reloading the raspberry again with new software and see if it makes a difference.

I am reasonably sure it is working fine under windows so maybe the RPI has a problem.

Repetier · May 2015

Ok I found one line that was not covered by a thread mutex so there was a very slight chance that it missed a continuation. Might or might not be the problem. I'm now testing with the CubieTruck that had my stall. Yesterday no stall with mac. So maybe faster computers make it less likely to hit the condition. Will see in 6 hours if it stalls again for me. If not it might be the problem.

I'm still wondering why you get waits and I a more full stall. I have different firmware (0.92.3) but that would only matter if it's the firmware. waits are also much harder to find as they would be solved before I can do anything. So i hope it is the same reason only yours being not as aggressive for some reason. If you want, you can test this version

https://dl.dropboxusercontent.com/u/74036902/Repetier-Server-0.60.1-Linux.deb

which is for Linux arm hf so it should run in a Pi 2. It has the fixes I think could make a problem and which I'm testing at the moment.

crocky · May 2015

I am just building a new Raspian for Rpi and I will configure it and install update and upgrade and then I will put your test file on and see.

Thanks for the effort

Repetier · May 2015

For me it looks good. Problem file 2 times printed without problems. Other file printer without hang and now running again problem file. Before I was only able to print the file once and second try had a hang. Could still be luck but I can still hope:-)

crocky · May 2015

That sounds good.

I have built a new raspian wheezy for the Pi with update and upgrade done and I have installed your file as above, I will give it a workout tomorrow and see how it goes, might plug the printer in via a powered hub too just to be doubly safe.

punkti · May 2015

my pi is the following:

processor    : 0
model name    : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS    : 2.28
Features    : half thumb fastmult vfp edsp java tls
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2708
Revision    : 000f
Serial        : 00000000d8973516

firmware i use 0.92.3

i downgraded to serv er 60.0 and will try again. the one that stalled was my first print with the latest version

Repetier · May 2015

@punkti sadly my image will not work for that. The code in question is rather old and hasn't changed since 0.60. So on the one side this makes me think how it could go unnoticed so long by so many users. But maybe 0.60 has changed the timings a bit. So be not surprised if 0.60 does the same. But I think I will update next week to 0.60.2 with my fixes if tests continue to work well.

crocky · May 2015

Cooking my first print on the new rpi configuration....

I think I may have just heard a wait, I'll check when it is finished...

crocky · May 2015

Well it was a lot better than the previous ones were, only two waits... https://dl.dropboxusercontent.com/u/30430570/Unicorn(1).log is the log for it...

One at the start and one at 52:57.... It is better...

Repetier · May 2015

Ok first wait does not count. It might be from before start.

Second wait had no visible reason. So it looks more like something kept the pi busy for s short while delaying send. I have checked my yesterdays logs on the cubietruck and in 5 hours print I had no wait at all. Are you running any other services or jobs on the pi that could cause this delay? Normally we should have no problems if we get our time slice from the thread scheduler. We even cache the next 5000 lines to prevent out of data in case other software starts and blocks the sd card for a while.

What board does the firmware run on and has it a display?

Repetier · May 2015

Just an after thought. I have a very unstable wifi on my pi so that I sometimes can not even text in a console. So first question is if you also use wifi or are you using a stable ethernet connection. In case of wifi could you test ethernet. I'm not sure how bad wifi may influence printing as that part uses no internet but your browser is connected and pi might get busy reconnecting even without browser connection.

crocky · May 2015

That afterthought may just be the one. I have been using the rpi with a really short dongle and it may be the problem. I have fitted another one to it with a lead and a very different driver software, just doing a test print now and we will see if it does any good.

I can run a lead direct to the router but it would be a last resort and only for testing, see how the other dongle goes first.

The rpi2 is stock standard and just the bare raspian with only the repetier server at present, it has only just been loaded with everything.

Just caught a wait so it looks like the dongle is no good either, get the wire out and here comes a direct connection to the hub.

crocky · June 2015

hmmmmmmm....

Still two waits even with the thing connected directly to router, one at the start and one about half way - I am lost now...

I'll try windows now and see how that one goes!

Repetier · June 2015

So new version is out for update. Fixes the problem that might cause your waits. At least I got none, but I'm not sure I had some before. Anyhow it fixes some other issues as well.

0.60.1 Looks Good

Comments