Endless messages when printing or simulating

Floobydust · 3 Feb 2018, 03:33

Okay, I've got pretty much everything sorted and printing nicely with the Duet Wifi board running the mechanics of a Prusa i3 Mk2. However, when I print anything or run simulate against a gcode file, I get endless messages popping up in blocks on the web interface which eventually timeout and scroll off, but it's incredibly annoying. It's always the same content over and over… literally hundreds of them on a small print and seemingly thousands on a larger print. The content is always this:

Maximum printing acceleration 10000.0, maximum travel acceleration 10000.0

I'm thinking I've got something setup wrong but I haven't figured it out yet… any ideas? Is there any way to turn this off?

Also, when running a simulate against a file, the estimated time is not shown on same screen section, I have to switch to the Gcode console to see it. Is there a way to have this display on the same screen simulate is invoked from?

Jackal · 3 Feb 2018, 04:43

Maybe you have debug on?
https://www.duet3d.com/wiki/G-code#M111:_Set_Debug_Level

Floobydust · 3 Feb 2018, 13:54

Thanks, but no, debug is off in the config.g file. I have logging on, which was done to help diagnose a network dropout, but turning that off doesn't make any difference.

whosrdaddy · 3 Feb 2018, 15:20

The problem is caused by your slicer (Slic3r).
Set all acceleration values to 0 in Print settings tab and the problem goes away

Floobydust · 3 Feb 2018, 20:04

Brilliant! That did it… thanks for the tip. I even tried putting values in around 20-50 and the same messages appear, so zeros are in.

dc42 · 3 Feb 2018, 21:49

It's probably only the travel acceleration that needs to be set to zero, also the retraction acceleration if that is available. You should be able to use nonzero values for the printing acceleration if you want.

Hobsie · 21 Mar 2018, 13:46

I'm trying to get rid of this message atm during my prints - but it's a little odd because I'm pretty sure none of the Slic3r settings i've got atm set acceleration anywhere near 10k mm/s/s?

There also doesn't seem to be a setting for setting the travel acceleration in the version of slic3r i'm using (Prusa's Fork v 3.8.x). Taking a look at the GCode produced by the slicer it's setting the default acceleration periodically using:

[[GCode]]
M204 S1000

That's the gcode produced when choosing Marlin or RepRap/Sprinter as the gcode flavour (I think those only differ by the time estimations atm?). I did notice however that the http://reprap.org/wiki/ lists the syntax for reprap firmware as:

[[GCode]]
M204 P500 T2000

Could that be causing issues with acceleration value changes in general?

Hobsie · 30 Mar 2018, 11:52

@dc42 I probably timed my last post really badly with MRRF on!

I'm going to try and replace all the M204's in GCode produced by Slic3r with M204's using the syntax I mention above to see if it helps.

dc42 · 30 Mar 2018, 14:55

According to http://reprap.org/wiki/G-code#M204:_Set_default_acceleration the parameters supported by Marlin since 2015 are T, P and R. So i guess S is particular to Prusa's fork of slic3r. RRF doesn't recognise the S parameter, so it sees M204 S1000 as having no parameters, and in common with the standard behaviour of RRF it reports the existing values.

I could have RRF recognise the S parameter, but it would be nice to know what it is supposed to do.

Hobsie · 30 Mar 2018, 15:03

@dc42 thanks for the response.

Yeah it looked like a mismatch of expected syntax for the command to me. Tbh I think I'll submit it as a bug on Prusa's fork and see what they say.

dc42 · 30 Mar 2018, 15:07

It may be that Prusa's fork is derived from an old version of Marlin that supported the S parameter; or it may be that Marlin does support the S parameter now/still but they haven't updated the documentation at reprap.org.

tomasf · 30 Mar 2018, 15:07

This thread seems to suggest S is a legacy parameter that sets both P and T to the same value:

https://github.com/alexrj/Slic3r/issues/2745

thiagopeixoto16 created this issue 18 Mar 2015, 13:40 in alexrj/Slic3r

closed New Marlin acceleration M204 syntax #2745

dc42 · 30 Mar 2018, 15:11

I've just checked the RRF code and the current version does recognise the S parameter of M204. Those of you having this issue, please update your firmware.

Hobsie · 30 Mar 2018, 15:16

@dc42 perfect! I've sent a message to the Prusa guys anyway as they might want to support the more up to date version for the command.

dc42 · 30 Mar 2018, 15:19

From the whatsnew file entry for firmware 1.19:

M204 S parameter is supported for backwards compatibility e.g. with Cura

Hobsie · 30 Mar 2018, 15:25

Ooh, that's interesting then. I came across this because of the acceleration message spam I was getting which I came to the conclusion might have been caused by the S parameter on the M204's but I'm pretty certain I'm on 1.20 (since I'm using senseless endstops).

I'll have a poke about then when I get home and see if it's not something daft I'm doing on my end.

Hobsie · 30 Mar 2018, 19:14

OK I've had a chance to test this out now.

Attempting to print a bench from Slic3r outputting M204 S commands is giving me buttloads of:

Maximum printing acceleration 1000.0, maximum travel acceleration 10000.0

However, replacing all of those M204 S commands with M204 P instead makes the messages go away.

My accelerations are set to (CoreXY rig):

[[language gcode]]
M201 X2000 Y2000 Z250 E10000

Edit:

Tested with M204 T now as well and the messages don't appear.
RRF v 1.20

dc42 · 30 Mar 2018, 19:28

I've just looked at the code again and realised that you need to have firmware compatibility set to Marlin for the M204 S parameter to be recognised. So check that you have M552 P2 in config.g.

Hobsie · 30 Mar 2018, 20:31

M555 P2 (which I figured out you meant) seems to do the trick with M204 S commands, cheers!

Are there any caveats we should be aware of when putting it into Marlin mode?

dc42 · 31 Mar 2018, 06:54

Marlin compatible mode mostly only affects commands sent via USB or Telnet. There are no particular caveats.