v0.80.0 Pro: stalls / freezes during print (Communication timeout)

xBot150

Hello @all,

since updating to v80.0 on my rasPi 3 I experience stalls during every print, e.g. the head stops moving / freezes for ~10 seconds (+creates a blob on the print) and then continues.

I _think_ that how often this occurs depends on the actual print-speed (e.g. 100% vs. 70% or lower) set within the Web-GUI; the lower the setting the more often it happens...

I haven't figured out where the "sweet spot" is with my printer since my printer is quite fickle during the first two or three layers (I seem to *have* to run with 60-70% of the speed set in repetier-hosts cura-slicer (currently 25mm/s) or the first layer won't stick no matter what I do :-( ), if such a stall happens within layer1-2/3 the print is usally fscked cos' the blob collides with the nozzle and this pushes everything 'somehwere'

The strange thing is that I this behaviour started with the update to v80, while I do confess that I have my fair share of misprints (1st layer problems...) but I never had stalls before.

Except the v80-Update _nothing_ has changed (neither the raspbian-distro running on the Pi nor Repetier-Host on my Win7-Machine, no Windowsupdates, nothing... I *did* update Repetier-Server on the Win7-Box yesterday 'cos the Pi redused to offload render-jobs to this box but the stalls happened before too)

Stalls look like in the Pi's logfile (if you need a full log please contact me via email):
--
< 19:05:42.336: N3404 G1 F840 X80.217 Y53.178 E1210.93269
> 19:05:42.365: ok
< 19:05:42.365: N3405 G0 F2700 X80.217 Y53.673
> 19:05:47.427: ok
< 19:05:47.428: M117 Layer 2/50
< 19:05:47.428: N3406 M105
< 19:05:47.429: N3407 M105
> 19:05:47.513: ok
> 19:05:47.518: ok T:210.0 /210.0 B:50.0 /50.0 T0:210.0 /210.0 @:44 B@:0
< 19:05:47.518: N3408 G1 F840 X25.567 Y108.323 E1213.18194
> 19:05:47.522: ok T:210.0 /210.0 B:49.9 /50.0 T0:210.0 /210.0 @:45 B@:0
> 19:05:47.525: ok
< 19:05:47.526: N3409 G0 F2700 X26.062 Y108.323
> 19:05:47.628: ok
< 19:05:47.629: N3410 G1 F840 X80.217 Y54.168 E1215.41081
> 19:05:47.636: ok
< 19:05:47.636: N3411 G0 F2700 X80.217 Y54.663
> 19:05:47.640: ok
< 19:05:47.640: N3412 G1 F840 X26.557 Y108.323 E1217.61931
> 19:05:47.644: ok
< 19:05:47.644: N3413 G0 F2700 X27.052 Y108.323
> 19:05:47.648: ok
< 19:05:47.648: N3414 G1 F840 X80.217 Y55.158 E1219.80744
> 19:05:50.933: ok
< 19:05:50.934: N3415 M105
< 19:05:50.934: N3416 M105
< 19:05:50.935: N3417 G0 F2700 X80.217 Y55.653
> 19:05:55.778: ok
> 19:05:55.783: ok T:209.8 /210.0 B:50.5 /50.0 T0:209.8 /210.0 @:46 B@:0
> 19:05:55.787: ok T:209.8 /210.0 B:50.5 /50.0 T0:209.8 /210.0 @:46 B@:0
< 19:05:55.788: N3418 M105
< 19:05:55.788: N3419 M105
> 19:06:00.547: ok T:209.7 /210.0 B:50.8 /50.0 T0:209.7 /210.0 @:47 B@:0
< 19:06:00.547: M117 ETA 20:57:45 day 23
< 19:06:00.548: N3420 M105
> 19:06:00.554: ok T:209.7 /210.0 B:50.8 /50.0 T0:209.7 /210.0 @:47 B@:0Nok
< 19:06:00.555: N3421 M105
> 19:06:00.558: ok T:209.7 /210.0 B:50.8 /50.0 T0:209.7 /210.0 @:47 B@:0
> 19:06:00.562: ok T:209.7 /210.0 B:50.8 /50.0 T0:209.7 /210.0 @:47 B@:0
< 19:06:00.563: N3422 G1 F840 X27.547 Y108.323 E1221.97520
> 19:06:00.566: ok
> 19:06:31.566: Warning: Communication timeout - resetting communication buffer.
> 19:06:31.566: Connection status: Buffered:46, Manual Commands: 2, Job Commands: 5000
> 19:06:31.566: Buffer used:46 Enforced free byte:35 lines stored:1
< 19:06:31.567: M117 ETE 01:51:44
< 19:06:31.567: N3423 M105
< 19:06:31.567: N3424 M105
> 19:06:31.571: ok
< 19:06:31.572: N3425 G0 F2700 X28.042 Y108.323
> 19:06:31.576: ok T:209.8 /210.0 B:50.5 /50.0 T0:209.8 /210.0 @:45 B@:0
> 19:06:31.576: ok
> 19:06:31.580: ok T:209.8 /210.0 B:50.5 /50.0 T0:209.8 /210.0 @:45 B@:0
--

I haven't tried the newly available RasPi-Image from your site just yet (no second SD-Card big enough available and I didn't want to nuke the one available since it's driving the printer...) so I can't be sure whether my RaspiCam causes issues (getting this thing to work with v70.x needed quite some faffin' around..)

Any ideas?

THX very much in advance!

Repetier

I see no direct errors in the log which is good. In 0.75.0 we introduced showing time on display. That version had problems with older Marlin versions which interpreted ":" in time string as new command so we removed that later. Don't think is the problem here but disabling the eta view would make it sure.

The main problem is the communication timeout. You get this if the buffers have not enough free space - in this case it can not send additional 35 bytes since 46 bytes are already in use. Means your buffer is less then 81 bytes in server configuration. In past 63 was the limit when arduino changed this buffer to 63. But Marlin normally has it's own size of 127 so increasing this would reduce the number of pauses.

Still there must be some missed "ok" responses somewhere earlier, but that is hard to spot and not inside your snippet. If you have your Marlin configuration I would suggest uploading a recent Marlin version with:

- busy reporting activated. This allows you to reduce timeout from 30 to 3 seconds giving much smaller blobs if it happens. Not sure if it is active by default anyway in newer versions. It is a recent improvement so might only in RC tree.

- In advanced configuration you can activate line number and wait reporting. This allows the server to correct such errors without delay on the fly before you stall for a while in 99.x%.

Also hopefully today we release 0.80.2 which you should update to.

xBot150

Thankyou for your reply, will try 0.82 and disabling the eta-display (yup, my firmware complained about the : too...)

Changing the firmware could be tricky since I do not have the sources for the one that's running on this printer right now... so if I mess something up within my new firmware things could get interesting since I have no way to roll back to a known good one :-/

Thank you for now, will keep you in the loop.

xBot150

Hi!

since 0.80.2 didn't make it today (and somebody had ants in his pants ;-)) I decided to switch to the current raspi-image.

hoohum..:
- display ETE is set to off (wasn't quite sure where to set this, RepetierHost and/or Server so I unchecked both) but STILL shows up on my display (Reprap Discount something)

- the only thing I changed within the printer-setup was the buffer size, went from 127 to 63.

now... it's still early days (print on nearly the full plate-size -150x150 and the cylinder has ~120mm in diameter-) and I'm on Layer 3 now: no stall/blobs so far and things look VERY promising...

to sum up all changes since yesterday:
- switched from stock raspian (installed RepetierServer myself + quite some faffin' around with recompiling ffmpeg since avconf did not support some parameters submitted by repetier) to your ReadyToRun-Image v80.1

- ran raspi-update (the one thingy where you ssh into your Pi, submit raspi-config and run an update there)

- changed the buffer-size from 127 (default) to 63, I'm not quite sure what was set within the previous configuration; can't check since the printer is running right now and my PC here is running Win7...

- since the 4GB SD-card I used until now was too small to dd the new image onto it I switched to a 16GB Kingston-something
--> could this be the cuplrit? I do know that RasPis are somewhat picky with the SD-card you feed them with and had some trouble with my <other> RasPis running OpenElec...

That's it...
/still too many changed variables at once to nail down the cause, dammit :-/

*knockin' on wood* & blaming systemd 'cos there *has* to be a scapegoat :-D

P.S: exporting and importing my printer-configuration from "old raspian" to the new image failed with "invalid configuration file" and I don't see any severe differences between "working/blobbing printer 'old'" and the new configuration created/exported from scratch.
-> If you're interested I'll upload both of them to our webserver for examination (can't find an upload-button or somesuch here and copypasta of xml-files into some forum-software usually goes wrong in my experience)


to finish this up:
thumbs UP for your exceptional support & response-times, I don't know what I would do without Repetier.

THANKYOU!

Repetier

You should 16gb or higher sd cards any way. 4gb is quite full and for extended live time bigger cards are better plus server writes some data depending what you all do, so 4gb is quickly full.

A link to not working xml configuration would be good. Should not happen so it is always interesting to see why if it happens.

I think you had 63 bytes buffer before and I said 127 would be better. So maybe it really was the ETA. Newer version replace : with space so the problem disappears, that might be the solution as you now have 0.80.1 and not 0.80.0.

xBot150

Hello @all,

to keep you in the loop:
got the sourcecode for my old firmware today (Marlin / grbl mashup) and "ported" the relevant configuration to you firmware-configurator.

Got bitten with (https://forum.repetier.com/discussion/1969/error-compilation-in-eepron-cpp-error-expected-primary-expression-before-token), for me the cause were the weird(?) settings for the heatbed's PID as copied from the original source:
HEATED_BED_PID_IGAIN 0.23
HEATED_BED_PID_DGAIN 305.4
these came in empty from your configurator and caused the compiler to throw a fit.

(I'm currently waiting for the bed to cool down so I can run the M303-autotune-stanza, maybe I get values that 'stick' within the configurator so I don't have to remember where to fiddle around when your next firmware-version comes out ;-))

As far I can see -haven't done a print yet- all controls are working, the display is smoother than with the old firmware too..

The one strange thing I noticed is that it's possible to "overrun" the endstops via Display-wheel.
e.g. on the hisplay
- Home <Axis>
- Position (fast or slow, doesn't matter) -> turn the wheel into "direction of Endstop" -> the axis-coordinate shown on the display happily increases (no movement on the axis itself)

My setup is somewhat weird (seen standing in front of the printer):
X/Y 0 is on back/right
X/Y (max) on front left, X+150 / Y+150

If I home Y and turn the wheel so that Y moves "away from me" Y goes to -1..-5..-10 and so on
BUT: if I the turn the wheel into the other direction (Y moves toward me) the axis moves immediately and not when 0 is reached;
e.g. if I wheel from Y(home) to Y -10 (1mm / click = 10 clicks clockwise, NO axis-movement!) and then 1 click _counterclockwise_ the axis is 1mm away from the endstop and the display shows Y -9... (huh.. same in X and -I assume- in Z)

xBot150

Update:
back to 127 bytes buffer, 2 successful small prints with ~20min runtime: no problems at all
the third one is currently running, all stops pulled (no faffin' around with slower speed at the first layer...)
-> no stalls/blobs

YAY!
... will have to talk _strongly> to <vendor>, the old firmware cost me quite some gray hairs and *hours* of cursing.

Now this is gonna be a *good* weekend, not sure if I'll get out from by man-cave until monday :-D

THANKYOU!

Repetier

Yes, moving through endstops can be weird as the endstop prevents the move but the rest does not know this. In dev version we also have a boundary check now that prevents such moves before queued so it only happens with lost steps.

You can move your origin to left front. Invert x/y motor direction, homing direction and min become max endstops.

xBot150

tried that and after two ..brrrr.. rather unsuccesful attempts or three (either the damn thing moves into the wrong direction while homing or doesn't stop when hitting the endstop or the webgui-buttons move the axis in the wrong direction...there's somthing "interesting" going on with the wiring here but to check the RAMPS-Board I have to -nearly- disassemble the printer and... )
-> I will leave this adventure for another weekend

to sum it up & trying to not derail this thread completely:
- Blobs gone after updating to Reptetier Firmware 0.92.9
-> printer driver (a.k.a. me) is happy ;-)