Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Driver doesn't support microstepping SBC

    Duet Hardware and wiring
    7
    13
    38
    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.
    • BeosDoc
      BeosDoc last edited by

      I'm running Duet 3 MB6HC V3.2.2 and I've hooked up rPi 4B. I'm using the same config.g file that I used in stand-alone mode and I'm getting this error:

      Error: M350: Driver 2 does not support x0 microstepping with interpolation
      Driver 3 does not support x0 microstepping with interpolation
      Driver 5 does not support x0 microstepping with interpolation
      Driver 4 does not support x0 microstepping with interpolation

      The M350 config line is:
      M350 X16 Y16 Z16:16:16:16 E16:16 I1

      I don't get that error in stand alone mode even when I send that command directly. With the SBC I don't see it on first boot but I do see it when I do an emergency stop or when I send that command to it. Obviously it won't even do a home.

      The printer works fine in stand alone mode.

      1 Reply Last reply Reply Quote 0
      • jay_s_uk
        jay_s_uk last edited by

        you should not be mapping extra Z axis on commands other than M584
        Your above M350 should be

        M350 X16 Y16 Z16 E16:16 I1
        
        BeosDoc 1 Reply Last reply Reply Quote 0
        • BeosDoc
          BeosDoc @jay_s_uk last edited by

          @jay_s_uk

          I have 4 Z motors

          deckingman 1 Reply Last reply Reply Quote 0
          • jay_s_uk
            jay_s_uk last edited by

            I know, but they are not valid on M350 like you had it
            they should be mapped in M584 and nowhere else

            1 Reply Last reply Reply Quote 0
            • deckingman
              deckingman @BeosDoc last edited by deckingman

              @BeosDoc What @jay_s_uk is saying is that once drivers have been mapped to axes using M584, then all commands such as M350, relate to axes, not drivers. So you should only refer to one Z axis in those commands (not multiple Z axes separated buy colons).

              Note that each extruder is treated as if it were an additional axis, so for extruders, you do need to use the colon separator (but not for axes).

              1 Reply Last reply Reply Quote 1
              • Veti
                Veti last edited by

                see the note in the documentation. there is a note that mentions this explicitly

                https://duet3d.dozuki.com/Wiki/Gcode#Section_M350_Set_microstepping_mode

                RepRapFirmware does not support individual motor settings where an axis has multiple motors connected to different stepper drivers. The first parameter specified will be used for all motors on the axis. You should use identical motors on any axis that has more than one motor to avoid unexpected behaviour.

                1 Reply Last reply Reply Quote 0
                • BeosDoc
                  BeosDoc last edited by

                  Then in stand alone mode it should also give an error then.

                  Changed

                  Thanks

                  1 Reply Last reply Reply Quote 0
                  • gloomyandy
                    gloomyandy last edited by

                    @BeosDoc In stand alone mode it may have been giving an error, but you had no easy way to see it as the config.g was been processed as the board started. Try running:
                    M98 P"config.g"
                    and see if you get an error.

                    BeosDoc 1 Reply Last reply Reply Quote 0
                    • BeosDoc
                      BeosDoc @gloomyandy last edited by

                      @gloomyandy

                      Incorrect. Here's M98 results:

                      M98 P"config.g"
                      HTTP is enabled on port 80
                      FTP is disabled
                      TELNET is disabled

                      Also when manually sending the M350 X16 Y16 Z16:16:16:16 E16:16 I1 it also doesn't give an error.

                      droftarts 1 Reply Last reply Reply Quote 0
                      • droftarts
                        droftarts Moderator @BeosDoc last edited by

                        @BeosDoc @gloomyandy sounds like some parsing of the command, or error checking, that has been implemented in the firmware, but not in DSF. I'll ask @chrishamm to take a look.

                        Ian

                        1 Reply Last reply Reply Quote 0
                        • gloomyandy
                          gloomyandy last edited by

                          @BeosDoc I did only say it "may" be getting an error :-). Thanks for checking, can you confirm that the M98 output was in stand alone mode.

                          1 Reply Last reply Reply Quote 0
                          • dc42
                            dc42 administrators last edited by dc42

                            I can see why there is a difference. DSF doesn't attempt to decode most commands, it just parses rthe numbers and repacks the command in a binary format that is more efficient to send over SPI and saves RRF some work. If it sees multiple values separated by colons, it flags the data as an array. Whereas RRF understands the command. If RRF is expecting a single number and the input is from a text stream, then it doesn't care what character comes after the end of the number. So if you say P1:2:2 and it expects just P1, then the "2:3" will be ignored. Whereas if it is received over SPI, it will be expecting a single value but find an array, and report an error.

                            We could change RRF to report an error if it finds a colon after the single value it is expecting, but that would probably break a lot of users files. However, it may be appropriate to provide a warning.

                            1 Reply Last reply Reply Quote 0
                            • gloomyandy
                              gloomyandy last edited by gloomyandy

                              I've just checked the RRF source. It only looks for the colon items when an "extruderLetter" is being processed. So it will be ignoring them on Z(hence no error). I'm not really sure what DSF is doing though.

                              				for (size_t axis = 0; axis < numTotalAxes; axis++)
                              				{
                              					if (gb.Seen(axisLetters[axis]))
                              					{
                              						if (!LockMovementAndWaitForStandstill(gb))
                              						{
                              							return false;
                              						}
                              						seen = true;
                              #if SUPPORT_CAN_EXPANSION
                              						axesToUpdate.SetBit(axis);
                              #endif
                              						const unsigned int microsteps = gb.GetUIValue();
                              						if (ChangeMicrostepping(axis, microsteps, interp, reply))
                              						{
                              							SetAxisNotHomed(axis);
                              						}
                              						else
                              						{
                              							result = GCodeResult::error;
                              						}
                              					}
                              				}
                              
                              				if (gb.Seen(extrudeLetter))
                              				{
                              					if (!LockMovementAndWaitForStandstill(gb))
                              					{
                              						return false;
                              					}
                              					seen = true;
                              					uint32_t eVals[MaxExtruders];
                              					size_t eCount = numExtruders;
                              					gb.GetUnsignedArray(eVals, eCount, true);
                              					for (size_t e = 0; e < eCount; e++)
                              					{
                              						const size_t drive = ExtruderToLogicalDrive(e);
                              #if SUPPORT_CAN_EXPANSION
                              						axesToUpdate.SetBit(drive);
                              #endif
                              						if (!ChangeMicrostepping(drive, eVals[e], interp, reply))
                              						{
                              							result = GCodeResult::error;
                              						}
                              					}
                              				}
                              

                              Edit: DC42 beat me to it, with a much clearer explanation!

                              1 Reply Last reply Reply Quote 1
                              • First post
                                Last post
                              Unless otherwise noted, all forum content is licensed under CC-BY-SA