Driver doesn't support microstepping SBC

jay_s_uk

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

@jay_s_uk

I have 4 Z motors

jay_s_uk

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

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

Veti

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.

BeosDoc

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

Changed

Thanks

gloomyandy

@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

@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

@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

gloomyandy

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

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.

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!