• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

[3.4.1] Custom mCodes not supported in Console

Scheduled Pinned Locked Moved
PanelDue
3
5
220
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • undefined
    oozeBot
    last edited by 3 Nov 2022, 15:28

    We are now extensively using DSF-Python for custom mCodes. However, they are unavailable through the PanelDue's Console. A warning stating "Command is not supported" is returned.

    Is this something that can be expanded for it to handle?

    undefined undefined 2 Replies Last reply 3 Nov 2022, 17:14 Reply Quote 0
    • undefined
      T3P3Tony administrators @oozeBot
      last edited by 3 Nov 2022, 17:14

      @oozeBot question for @chrishamm about how gcode commands get passed back from other inputs like Serial back to DSF.

      www.duet3d.com

      undefined 1 Reply Last reply 3 Nov 2022, 17:17 Reply Quote 0
      • undefined
        chrishamm administrators @oozeBot
        last edited by 3 Nov 2022, 17:15

        @oozeBot Thanks for pointing this out, I'll add a fix to RRF. To work-around this limtiation for now, you should be able to create custom macro files for your M-codes and to wrap the M-code again from there.

        Example for M1010 S"foobar":

        M1010.g:

        M1010 S{param.S}
        

        Duet software engineer

        1 Reply Last reply Reply Quote 0
        • undefined
          oozeBot @T3P3Tony
          last edited by 3 Nov 2022, 17:17

          @T3P3Tony @chrishamm - Weirdly, we hijacked M587 through DSF-Python for some additional functionality and it is working through the console.. but nothing else is.

          Unfortunately, what we need won't work as a macro as it requires user input, but as long as it can be fixed in an upcoming release, we should be in good shape. Thanks!

          undefined 1 Reply Last reply 3 Nov 2022, 17:19 Reply Quote 0
          • undefined
            chrishamm administrators @oozeBot
            last edited by 3 Nov 2022, 17:19

            @oozeBot File-dependent M-codes are already sent back to DSF because DSF needs to handle or intercept them:

            // Pass file- and system-related commands to the SBC service if they came from somewhere else.
            // They will be passed back to us via a binary buffer or separate SPI message if necessary.
            if ( reprap.UsingSbcInterface() && reprap.GetSbcInterface().IsConnected() && !gb.IsBinary()
            && ( code == 0 || code == 1
            || code == 20 || code == 21 || code == 22 || code == 23 || code == 24 || code == 26 || code == 27 || code == 28
            || code == 30 || code == 32 || code == 36 || code == 37 || code == 38 || code == 39
            || code == 112
            || code == 470 || code == 471
            || code == 503 || code == 505
            || code == 540 || code == 550 || code == 552 || code == 586 || (code >= 587 && code <= 589)
            || code == 703
            || code == 905 || code == 929 || code == 997 || code == 999
            )
            )
            {
            gb.SendToSbc();
            return false;
            }

            I've just added some new code that makes sure unknown G/M-codes are sent back to DSF before the default action is attempted (i.e. execute Mxxx.g or report an error if that fails).

            Duet software engineer

            1 Reply Last reply Reply Quote 2
            3 out of 5
            • First post
              3/5
              Last post
            Unless otherwise noted, all forum content is licensed under CC-BY-SA