Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order
    1. Home
    2. ardenpm
    • Profile
    • Following 0
    • Followers 0
    • Topics 11
    • Posts 48
    • Best 6
    • Groups 0

    ardenpm

    @ardenpm

    6
    Reputation
    1
    Profile views
    48
    Posts
    0
    Followers
    0
    Following
    Joined Last Online
    Location Melbourne, Australia

    ardenpm Unfollow Follow

    Best posts made by ardenpm

    • RE: Servo control with frequencies other than 50hz and M280

      Just for prosperity if others come across this thread in the future, I finally got around to updating to RRF 3.4.x and the implemented change works great. I can now correctly define the servo with the needed PWM frequency like so:

      M950 S0 C”duex.pwm5” Q333
      

      And then move it with the servo commands like so:

      M280 P0 S45 ; set servo position to 45 degrees
      

      And it moves a sensible amount as expected.

      posted in General Discussion
      ardenpm
      ardenpm
    • G10 tool offsets can't be applied to ABC

      Is there any reason that G10 tool offsets cannot be applied to the ABC axes?

      The documentation has parameters for X, Y, Z, UVWnnn but not ABC and trying to provide them doesn't do anything. I understand those axes might not normally be used for things where offsets are appropriate but they just as easily could be.

      posted in Documentation
      ardenpm
      ardenpm
    • RE: PID autotune of Volcano duration?

      @jay_s_uk Will see how I go. Interestingly I tuned my other Volcano tool just now and it completed in about 13 minutes without the warning (where as that one previously had given me issues as well). I'll see how it all goes once I have them all done and try to get them to temperature.

      posted in General Discussion
      ardenpm
      ardenpm
    • RE: G10 tool offsets can't be applied to ABC

      @dc42 I think you may be right, when I tried it at first it didn’t work however when I switched to U it also didn’t at first but I was trying to define them in their own G10 lines. When I did it all on the same G10 call per tool it seemed to work.

      @fcwilt yeah, when I defined the B axis I redefined it as linear per the release notes.

      I’ll switch back to B at some point soon and see if it works anyway. Would be good to have the documentation updated if that is the case.

      posted in Documentation
      ardenpm
      ardenpm
    • RE: PID autotune of Volcano duration?

      @phaedrux I think it has a fair impact but I haven't quantified it and I do have socks on the hotends so not as much as it would otherwise. Tuning as a heater is what I resorted to originally but circled back as I wanted to try accounting for the fans.

      I'm going to try it with the tools in a more realistic position first and see how I go, if that is still giving me dramas I may revert to just tuning as a heater. I haven't seen the heaters fault in any case so the fans can't really have that much impact.

      posted in General Discussion
      ardenpm
      ardenpm
    • RE: PID autotune of Volcano duration?

      Re-tuned with the tools over the center of the bed. The two Volcano tools both gave me the inconsistent behavior warning this time (where as only one did last time). They gave me:

      M307 H3 R1.312 K0.283:0.128 D7.94 E1.35 S1.00 B0 V24.1
      M307 H4 R1.396 K0.290:0.166 D7.39 E1.35 S1.00 B0 V24.1
      

      The second part of the K value is still fairly different between the two Volcano tools. At this stage I think I will go with what I have and wait and see if I hit any faults or other issues and come back to this when I have been printing with it more.

      posted in General Discussion
      ardenpm
      ardenpm

    Latest posts made by ardenpm

    • RE: Incorrect extrusion amount on slow and/or small axis moves

      Does your slicer have a place you can enter code during a retraction? Some of them do.

      @fcwilt I don't believe PrusaSlicer has custom G-code for retraction.

      That would solve the speed problem as you could set the extruder speed to the max for extrusion and in the retraction handler up the speed during retraction and then put it back to normal.

      I don't really see doing the above as too big a problem in any case since it's only for these specific priming moves which already have a fairly large amount of Gcode scripting around them, so it's just a few extra lines.

      posted in General Discussion
      ardenpm
      ardenpm
    • RE: Incorrect extrusion amount on slow and/or small axis moves

      If B and E are not kept in sync how do you see that working? Would E just continue to run after B is done?

      @fcwilt That's actually the issue, it does attempt to keep them in sync and it thinks on the extruder side it has enough headroom to run it all the way up to my configured maximum speed of 3600mm/m for extruders, where as my extruders can handle more like only 300mm/m without skipping.

      The reason the extruders are configured to allow a speed much higher than they can actually extrude is because of retractions, which happen at a much faster speed than extrusions. So by limiting the extruder temporarily to the limit for practical extrusion it should force the movement axis to slow down further to say in sync.

      posted in General Discussion
      ardenpm
      ardenpm
    • RE: Incorrect extrusion amount on slow and/or small axis moves

      @deckingman I prefer to restore the feedrates to their previous value rather than a hard coded value when done so if I change my configuration I don't need to hunt for values in my different macros. However that should be pretty straight forward, something like this.

      var defaultSpeed0 = move.extruders[0].speed
      var defaultSpeed1 = move.extruders[1].speed
      var defaultSpeed2 = move.extruders[2].speed
      var defaultSpeed3 = move.extruders[3].speed
      
      M203 E{param.F}
      G1 B{param.B} E{param.B} F{param.F}
      M203 E{var.defaultSpeed0}:{var.defaultSpeed1}:{var.defaultSpeed2}:{var.defaultSpeed3}
      

      Which is definitely still simpler than the first macro I had there. Definitely lots of ways to skin this particular cat.

      posted in General Discussion
      ardenpm
      ardenpm
    • RE: Premature termination of nested macro

      @gloomyandy It is in DWC, however the console output approach above is just to simplify it for the reproduction case so it could be run without having to move or print. In the real case where I encountered the issue there were moves and extrusion so it was pretty obvious it had stopped since nothing was moving or extruding.

      posted in Gcode meta commands
      ardenpm
      ardenpm
    • RE: Incorrect extrusion amount on slow and/or small axis moves

      @deckingman Yes, that’s true I could also do that. I’ll need to use the object model to find the current tool to apply it to the right extruder motor so that should be possible. I haven’t confirmed that limiting the extruder instead of the movement axis has the same affect but I would assume it must. I would still set the limit of the extruder though to the feedrate I actually want since otherwise it would just always run at 300 (I have multiple steps at different feedrates in my case). But limiting the extruder is simpler and shouldn’t hit the other minimum speed issue. I’ll definitely give that a go.

      posted in General Discussion
      ardenpm
      ardenpm
    • RE: Query maximum and minimum feedrates

      @deckingman Excellent question. Could the minimum feedrate be referring to the "tool" rather than the individual axes?

      posted in Gcode meta commands
      ardenpm
      ardenpm
    • RE: Incorrect extrusion amount on slow and/or small axis moves

      @gloomyandy No, because I don't want to limit the E axis to that feedrate, I want it to run at the specified rate but the B axis much slower than normal. Without this the E axis will run up to its limit to try and sync with the short B axis move time. Without doing this I need to slow down the E axis too much.

      posted in General Discussion
      ardenpm
      ardenpm
    • RE: Incorrect extrusion amount on slow and/or small axis moves

      So putting this together now that it is clear what's going on, I'm using a small macro which takes the same B, E and F parameters as my G1 calls but computes the feedrate limit for me, changes it then sets it back to the original value. This seems to be working well and I can now do a nice smooth drop of my priming platform while extruding at the needed rate. Obviously fairly specific to my use case but in case it's helpful to anyone else here it is.

      var defaultSpeed = move.axes[4].speed
      var extrusionTimeMinutes = param.E / param.F
      var newSpeed = abs(param.B - move.axes[4].userPosition) / var.extrusionTimeMinutes
      echo {var.newSpeed},{move.axes[4].userPosition},{param.B}
      if var.newSpeed < var.defaultSpeed
        M203 B{var.newSpeed}
        G1 B{param.B} E{param.E} F{param.F}
        M203 B{var.defaultSpeed}
      else
        G1 B{param.B} E{param.E} F{param.F}
      

      Thanks all for the lively discussion.

      posted in General Discussion
      ardenpm
      ardenpm
    • Premature termination of nested macro

      I'm having an issue with some Gcode scripts I have setup which are calling each other but stopping execution for no apparent reason with no errors. I believe it can be reproduced with the following:

      test_a.g

      if true
        echo "Yes"
      else
        echo "No"
      

      test_b.g

      if true
        M98 P"test_a.g"
        M98 P"test_a.g"
        M98 P"test_a.g"
      

      If I then run:

      M98 P"test_b.g"
      

      I get only a single "Yes" printed to the console. If I edit test_a.g to be:

      if true
        echo "Yes"
      else
        echo "No"
      echo "Done"
      

      I get then then expected three "Yes" strings output (and of course three "Done" strings as well). The above example is a cut down minimal reproduction case from a much more complex script.

      Note that in test_b.g, if the M98 calls are not inside an if clause then they do work as expected. So it appears to be something to do with the nesting of the if statements across nested macro calls.

      The absence or presents of a final newline has no effect on the issue. Note also the failure is silent, there are no errors it just stops executing code.

      I'm on RRF3.4.1, not sure if this is definitely a bug and whether I should file it on Github or not so hoping for a sanity check here.

      posted in Gcode meta commands
      ardenpm
      ardenpm
    • RE: Query maximum and minimum feedrates

      @deckingman From my tests it does appear to default to 30mm/m per the documentation, however it can be changed by the user so to be generic I'd like to be able to query the current value to be able to restore it. For my specific case of course I know if I have changed it so can live without it but would be nice to have when writing things that someone might use on another machine.

      When I tried to do a move slower than 30mm/m it definitely did not behave as expected until I issued an M203 Innn low enough. So for example if I just did G1 X10 F1 I'd expect it to take around 10 minutes, but it actually takes about 20 seconds, once I lower the minimum feedrate to 1 as well it takes the expected amount of time. I also don't really see the reason for the default minimum overall feedrate being 30mm/m, though I think Marlin has something similar from memory.

      posted in Gcode meta commands
      ardenpm
      ardenpm