Endless messages when printing or simulating
-
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.
-
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.
-
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 S1000That'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 T2000Could that be causing issues with acceleration value changes in general?
-
@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.
-
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.
-
@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.
-
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.
-
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
closed New Marlin acceleration M204 syntax #2745
-
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.
-
@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.
-
From the whatsnew file entry for firmware 1.19:
- M204 S parameter is supported for backwards compatibility e.g. with Cura
-
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.
-
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 E10000Edit:
Tested with M204 T now as well and the messages don't appear.
RRF v 1.20 -
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.
-
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?
-
Marlin compatible mode mostly only affects commands sent via USB or Telnet. There are no particular caveats.
