Endless messages when printing or simulating



  • 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?





  • 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.



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



  • 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.


  • administrators

    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 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?



  • @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.


  • administrators

    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.


  • administrators

    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


  • administrators

    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.


  • administrators

    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 E10000
    
    

    Edit:

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


  • administrators

    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?


  • administrators

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


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.