Best posts made by nhof

@token47 if you set a maximum axis speed to 150mm/s using the M203 command in your config.g it will probably do what you want.
Any rapids trying to go faster will be capped at the 150mm/s, but slower print moves will still see the increased speed up to that limit.

Do you have any M376 taper height for bed level applied? Could be that the Z20 move in your non-working script is high enough to disable the bed compensation.

Not sure it works that way but the old script has no similar Z move.

What type of machine is it?

OK here is a basic guide.

• Thermistors: Polarity does not matter, resistors work both ways equally
• Heaters: Polarity does not matter, resistors work both ways equally
• Fans: Polarity does matter, most fans have red (dc+) and black (dc-) leads. Don't plug these in backwards the fans will usually break.
• Stepper motors the wire order does matter.
  • Most motors follow the wire color scheme red, blue, green, black. Red and blue are one phase (coil) black and green are the other. The duet wire diagrams actually are color coded as well.
  • To double check motors, measure two of the wires on resistance mode on a meter. If it has a few ohms of resistance, those two wires are a coil. If it does not, try another pair.
  • if you plug a motor phase in backwards (for example, black/green instead of green/black) the motor might not move properly, but it is easy to fix and should not damage the motor.

Power supply to board is pretty simply, Just look for V+ on the PSU and hook it up to VIN+ on the duet. Same thing for V- from the psu to GND on the duet. Use ferrules if possible, they're nice and keep everything clean.

Check here for diagram: https://duet3d.dozuki.com/Wiki/Duet_Wiring_Diagrams

The only part that's a bit tricky (besides the motors) is the home switches. For a basic switch it should be wired between GND and STP on the home switch header.

And that's really all you need besides bed probe if you want one.

OK so just to clarify on the M574 code because I think there is confusion about the terminology.

The M574 command has two parts. The first Xn Yn Zn describes the physical location of the end-stops: whether is it at the min or max travel of the axis (or whether it is not installed).

The second part,Sn, describes the logic level of the end-stop input pin when triggered and is described by the terminology 'active [low/high]' The terminology can be a bit confusing but here is a breakdown for the function of standard microswitch endstops:

For a Normally Closed (NC) switch, the circuit is connected through the switch until it is pressed, so it will work as follows:

• When switch is not pressed, STP pin is shorted to GND through the switch, resulting in a STP pin logic state of LOW.
• When switch is pressed during homing, the STP to GND connection is broken, so STP is pulled hi through the pullup resistor. Thus a NC switch will result in an 'active high' (S1)signal on the STP pin.

For a Normally Open (NO) switch, the circuit will not be connected until it is pressed:

• When switch is not pressed, STP pin will be pulled HIGH through the pullup resistor.
• When switch is pressed during homing, STP pin will be shorted to GND through the switch, resulting in a STP pin logic level LOW. this is 'active low' (S0)

So 'active high' and 'active low' do not refer to which end of the axis the switch is installed on, but rather the logic level of the STP pin when triggered.

So an example config lines might look something like this:
M574 X2 S0 'active low' NO switch connected to X endstop input. X switch is physically installed at the max travel point of the X axis.
M574 Y1 S1 'active high' NC switch conneted to Y endstop input. Y switch is physically installed at the min travel point of the Y axis.
M574 Z0 S0 no 'Z' home switch is installed.

We may just be getting the logic level high/low confused with the axis position high/low.

In the picture you posted, if the bed is moving in toward you, then isn't the nozzle moving in +Y direction relative to the bed/part, correct? Assuming since the bed moves then the nozzle is not moving in Y direction. A G1 Y200 should move the bed towards you on most standard bed-moving printers (prusa i3 style, etc).

If this is the case then you need to change your motor direction (M569), endstop direction, and homing macro files.

But I could be looking at the picture wrong.

Note that in the latest version of RRF, it will run the start.g macro automatically before any of the sliced g-code file is run (i.e. before the temperatures are set).

You may have to create an alternate macro (start2.g for example) in the /sys/ folder, and call it up in the slicer startup script using M98 P/sys/start2.g. This would run the new start macro only after temperatures are set by the g-code.

With external drivers it's critical to be aware of minimum pulse time requirements for drivers (see M569 command).

Most external drivers will require longer step pulses than the on-board drivers, this could be why you are losing steps.

Here is an example from a datasheet from JMC showing pulse timings which you would have to guarantee with the M569 command:

@rflulling @dc42

Did a bit of testing this morning on my machines.

I did not see any abnormal motion if the M208 commands are the same value. e.g. M208 X0:0. Motion is normal in this case.
I did not see any abnormal motion with M208 command depending on positive or negative values e.g. M208 X-100:-90, M208 X-500:500, M208 X-50:-50. These worked as expected.
I did see abnormal motion with M208 when min value > max value. e.g. M208 X100:0, M208 X0:-1, M208 100:-100 etc. Moves after homing in this case will result in hard to predict motion.

Motion was not that different with different values for M574 (for me). This could depend on homing scripts but I didn't bother testing any of this.

I also did not see any non-commanded moves on alternate axes (like XY moves when Z move was commanded), but I am using external drivers on drive 5, 6, and 7 for my axes so that may have an impact.

Poking around in the code, it looks like it may be an issue with the end coordinates of a move being re-calculated if the end points of a move fall outside the axis limits, as this will always be the case if the M208 command has been given inverted axis limit values and may result in the end points of moves being offset by the entire axis length in the opposite direction from the expected one.

I still think the best thing to do would be to add input validation on the M208 command. I think it is reasonable to require that the minimum limit is equal or less than the maximum limit.

Here is the file GCodes2.cpp with a little input validation. I don't have the build set up for RRF so I have not compiled or tested this code and it might need refactoring to clean it up, but the idea is there:

case 208: // Set/print maximum axis lengths. If there is an S parameter with value 1 then we set the min value, else we set the max value.
	{
		bool setMin = (gb.Seen('S') ? (gb.GetIValue() == 1) : false);
		bool seen = false;
		for (size_t axis = 0; axis < numTotalAxes; axis++)
		{
			if (gb.Seen(axisLetters[axis]))
			{
				float values[2];
				size_t numValues = 2;
				gb.GetFloatArray(values, numValues, false);
				if (numValues == 2)
				{
					if (values[0] > values[1])
					{
						reply.catf("Invalid %c axis limits, min limit cannot be greater than max limit", axisLetters[axis]);
						result = GCodeResult::error;	
					}
					else
					{
						platform.SetAxisMinimum(axis, values[0], gb.MachineState().runningM501);
						platform.SetAxisMaximum(axis, values[1], gb.MachineState().runningM501);
					}
				}
				else if (setMin)
				{	
					if (values[0] > platform.AxisMaximum(axis)
					{
						reply.catf("Invalid %c axis limits, min limit cannot be greater than max limit", axisLetters[axis]);
						result = GCodeResult::error;	
					}
					else
					{
						platform.SetAxisMinimum(axis, values[0], gb.MachineState().runningM501);
					}
				}
				else
				{
					if (values[0] < platform.AxisMinimum(axis)
					{
						reply.catf("Invalid %c axis limits, min limit cannot be greater than max limit", axisLetters[axis]);
						result = GCodeResult::error;	
					}
					else
					{
						platform.SetAxisMaximum(axis, values[0], gb.MachineState().runningM501);
					}
				}
				seen = true;
			}
		}
			if (!seen)
		{
			reply.copy("Axis limit");
			char sep = 's';
			for (size_t axis = 0; axis < numTotalAxes; axis++)
			{
				reply.catf("%c %c%.1f:%.1f", sep, axisLetters[axis], (double)platform.AxisMinimum(axis), (double)platform.AxisMaximum(axis));
				sep = ',';
			}
		}
	}
	break;

I agree with Ian that text editors are the way to go for minor edits. Notepad++ chokes up for me on files past 100,000 lines, so I switched over to VS Code with a g-code plugin for highlighting. Works flawlessly even with 1,000,000+ line files.

Note that if you don't set the standby temperature if you switch tools it will drop to a standby temp of 0 on the inactive tools. I can't remember whether M104 sets standby temps or just active...

To avoid this you can use G10 to call out a specific tool and explicitly set the standby temps as well, then select them in order with Tn P0 to avoid running tool change macros:

G10 P0 S235 R235 ; set tool0 to active 235, standby 235
G10 P1 S235 R235 ; set tool1 to active 235, standby 235
G10 P2 S235 R235 ; set tool2 to active 235, standby 235
T0 P0 ; select tool 0, don't run tool change macros
T1 P0 ; select tool 1, don't run tool change macros
T2 P0 ; select tool 2, don't run tool change macros

This is similar to what Ian suggested but in 'native' RRF gcode format with a bit more granular control. It will result in all three tools heating up to 235 and T2 active.

If you want a particular tool active at the end instead of T2, just put the relevant tool change command at the bottom.

If you wanted to also heat the bed up just add it as a M140 Snnn Rnnn in the same format as above.

M140 S120 R0 ; set bed to active 120, standby 0
M116 H0      ; optional wait for bed heater to reach target temperature

M116 is the RRF equivalent of the M190/M109 command (wait for X temp). Used like so

M116 P0 ; wait for tool0 to reach temperature
M116 P1 ; wait for tool1 to reach temperature
M116 H0 ; wait for bed heater to reach temperature

etc.

@Antipasta @Cherno-Alpha This is almost certainly a step or dir timing issue.

Basically what is happening (most likely) is the dir signal from the board is flipping, but the next few step signals don't get applied in the correct direction, so over time it results in a gradual shift.

The way to fix it is the M569 command as my post above. Use the T parameter to guarantee dir setup and hold timings. From the data sheet it looks like the step pulse width should be 0.25us which is ok, but the dir timing signal is probably off (spec sheet doesn't provide these values).

So do something like this for all the M569 commands connected to external drivers
M569 Pn Sn T1:1:5:5 ; 1us pulse width, 1us interval, 5us dir setup, 5 us dir hold

This should make sure that when the DIR line changes, the steps are counted in the proper direction. If it doesn't work at first, increase from 5 to 10 or 20 or something until it fixed the issue.

This probably has more to do with RRF rather than the DWC specifically.

S3D g-code files do not have any comment strings or setting strings for either total number of layers or object height. So what RRF does is runs through end of the file looking for a Z move and guesses that the last non-relative Z move is the height of the part. This file information is passed to DWC.

In your case the last absolute move is Z=148 so it assumes that is the part height, 148/0.2 is the 740 value you're seeing.

RRF estimates layer-based print time by averaging the last 5 layer times and applying that average time to expected remaining layers. Unfortunately in your case because it expects to print hundreds more layers this will throw the estimate way off.

It might be possible to change the parser to look for the last 'Layer xxx, Z = yyy' comment instead as it might provide a more reliable object height value, but I'm not sure how easy it would be to implement. It would be unreasonable (I think) to re-write the file parser to account for every slicer g-code variation and user g-code input, as it is quite difficult to parse these values from the g-code files given a lack of a standard g-code print info headers and the wide variation among slicers. However it may be reasonable in this case to change given the popularity of S3D.

It would be possible of course for DWC/RRF to change to use just the file size based percentage estimate (this is what Marlin uses, and RRF calculates this as well). This method will calculate percentage (of file) completed perfectly, but will not provide accurate time remaining estimates.

Here are a couple things you can try in the meantime:

• Try running 'Simulate' on a file from DWC to get a better estimated time. This may result in time estimates during the print being more accurate (I don't really know tho)
• Change your ending g-code to a relative instead of absolute move. If you have your FW travel limits set properly you should be able to do something like this (i have not tested):

G91 ; relative moves
G1 Z+500 F900 ; move farther than Z max
G90 ; absolute moves

RRF should truncate your move at Z max automatically. This will not require splitting g-code by calling up custom end scripts, etc. Obviously it doesn't work if you don't want Z-max specifically but such is life.

I won't argue that DWC/RRF should be improved to better handle these cases, however it's probably lowish priority as a largely UX issue. Depending on where it might be in Duet3D's work list so you may get faster results by using a workaround for the time being.

I've worked on these machines a bit. The company who builds these started out of a linear motion component manufacturer, so the mechanics are pretty bulletproof. They have a dry teflon-type coating on the lead screws with wear-compensated anti-backlash nuts, it's a good setup. I think the main idea is for the machine to run reliably for a long time with minimal maintenance.

It would be possible of course to design and build something better, but it will certainly cost more money if you're paying someone else to do it, and good luck on docs/support/service. For most companies it's probably not worth the risk compared to buying this machine, bigrep, or another from an established player with everything already in place.

I would love to tackle a build on this scale, but then I would have a project rather than a printer. Not to mention I have no space remaining in my apartment to put it

The M574 syntax is confusing, here is an explanation:

The number right next to the axis letter Z1 or Z2 indicates the physical position of the home switch.
M574 Z1 ; physical location of Z switch is low end of axis stroke
M574 Z2 ; physical location of Z switch is high end of axis stroke

The number after S is the logic state of the endstop input when triggered.
M574 Zn S0 ; endstop input pin is LOW when sensor is triggered
M574 Zn S1 ; endstop input pin is HI when sensor is triggered

So in the second line M574 Z1 S2 we are actually asking for the Z probe to trigger when the Z reaches min limit. Not what we really want to set up for the subsequent G1 move.

I imagine something like M574 Z2 S1 might serve you better, double check the home sensor state using M119 (or thru DWC) to ensure you have the proper S value (active hi vs active low).

Side note, but I think the newer G1 syntax is using H instead of S. G1 Z300 H1 is the new 'standard' home-seeking command format.

Hello @Vlad

I do understand your frustration with the issues you are running into (I have built many industrial automation machines and dealt with my fair share of supplier woes), however I do think your approach towards getting them solved may be less than productive.

For example, posts such as 'Half-assed update...' and others could be considered unprofessional, and might even damage goodwill with both the Duet team and the community here. Even while dealing with trying issues it's good to remember that we're all human, and to try and find professional ways to communicate frustration.

It's also important to keep in mind that this is a public forum and is frequented by people in the 3D printer community and industry (which is surprisingly small). As a business owner yourself, I'm sure you're aware of the importance of maintaining professional image, and that it does not just apply in the context of communicating with your own customers, but also in dealing with suppliers and others. We would hate to see your reputation tarnished by a few trivial comments written in haste.

I don't personally hold ill will toward you or anyone. I'm writing this simply because I made these same mistakes in a past life, and hope that my hard-learned lessons might be of service to a newer player.

@MJLew If it's centered around (50,50) and you're starting at (55,50),
you could try something like this:

; Quarter arc, starting (55,50), moving CW to (50,45).
G1 X55 Y50
G2 X53.535534 Y46.464466 I-5.000000 J+0.000000
G2 X50.000000 Y45.000000 I-3.535533 J+3.535533

It looks like in your example, you might have CCW coordinates specified for a G2 CW arc move, which might be causing the spiral weirdness. Additionally it looks like your center point is defined relative to the destination point, rather than the start point. I think defining center relative to start point of the move is the intended usage.

In this case your formula would be something like:

I = Xcenter - X(start of move)
J = Ycenter - Y(start of move)

which should work for both G2(CW) and G3 (CCW) moves

I am gonna throw a few things in here because I had a long journey getting the compensation to work on my machine. In my case it was twist in the X axis causing the problem, but it took me a long time to discover because I was just randomly changing settings and hoping for improvement rather than using a systematic approach.

There are several possibilities where the bed compensation could have problems. In order to troubleshoot systematically you'll need to build a list of potential error sources, and then troubleshoot by eliminating variables and testing what remains until you narrow down the root cause of the issue.

Every time I made a change, I would take another height map reading and save it into an excel spreadsheet. This allowed me use the charting tools and math functions to easily visualize and compare different readings to see what the similarities and differences were, and to see if I was making improvement over time.

There are many potential sources of errors in the bed map process. You'll have to come up with your own list, but here is what I ended up checking on mine:

1. Probe itself. Could be poor repeatability on the component. I replaced my bltouch with a simple microswitch just for testing purposes. Didn't change anything in the height maps, which eliminated the probe as a source of error.

2. Probe mounting location. This is a big one, particularly if the probe is in front of or behind the nozzle, any twist in the X axis could lead to incorrect readings due to the cosine error of the measurement. This will normally present as a 'tilted' height map, where one side is significantly higher than the other and it's fairly even over the distance. If there is a lot of downward deflection in X you would normally see a humped height map where the center is higher than left and right edges. This ended up being the problem in my case as my X axis was tilted. My probe was mounted far enough from the nozzle in X that a slight tilt was enough to introduce more than 0.4mm deviation into the readings.

3. Probe offsets. Large offsets can cause issues for mechanical reasons as above. Just validate the numbers otherwise. I think this is correct for you so unlikely to be an error source.

4. Interference in wiring between probe and duet. I replaced the existing wiring harness with a shielded wire just for testing which was ran far away from motor wires etc. This didn't change readings at all so it eliminated cable interference as a significant error source.

5. Temperature variation. Make sure at least the bed is stabilized to print temp before probing as it will certainly affect level. If you have a plastic probe mount it could possibly be softening slightly with temperature and changing readings as well (not terribly likely but possible). In my case this did make a big difference in readings between temperatures. My process is now to re-run the height map when I change materials with a significant difference in bed temp (from PLA to Polycarbonate for example)

6. Height map generation within firmware. You can check that this is OK by manual bed map generation. You can make one by attaching a dial indicator or similar. Fasten it to the extruder so it rides the carriage around. Record readings at various points to manually generate a height map csv file for the firmware. Compare this to the automatically generated maps. Load it up, then check to see if the compensation is better or worse. If the compensation is correct with a manual map, then something in the automatic map generation step is the source of the problem. If the compensation does not change or gets worse, then it's more likely to be with the compensation math / implementation itself (or the manual readings were taken incorrectly). In my case the manually generated map did not match the automatically generated map, which indicated problems with the automatic map process.

7. Compensation within firmware. You can make a fake height map with some easy to visualize error, such as a straight left-right variation of 5mm or so. Then just move across the bed with compensation enabled to ensure the system moves the expected amount. A dial indicator as above is a very helpful tool for this. In this case you would leave the dial stationary on any point in the bed, just to measure Z axis motion only. For my machine the compensation with the manually generated map worked perfectly, which indicated that the problem was NOT in the application of compensation but rather in the height map generation process or probe.

Sorry for the novel, hope this helps

If you are running in tool mix mode to ditto extrude, you can modify the mix ratios with M567 to change the extrusion from each nozzle. Like M567 P2 E1:1.05. This would set the second drive to 105% flow for example.

This is certainly a comms issue of some sort. The paneldue is normally send M408 commands regularly and reads back the status. Because you are constantly getting M508, M4080, etc it's probably the serial signal that's getting messed up.

The stepper motors are enabled when you command motion for homing, and these tend to be electrically noisy. You can check to see if any motor cables run near the paneldue cables, this could cause interference. You should also check the paneldue cables to make sure all the crimps are making good contact, there is no damage, it's plugged in securely etc. Also make sure the cable is not too long. My money points towards being related to the motor cabling as you say there isn't any issue until you move the system, and generally the motors will not be enabled on startup until you command a move.

You might also be able to reduce the baud rate of the paneldue and the duet, slower baud rates might reduce the bit errors. You can reduce the baud rate by using the M575 P1 command in your config.g, and selecting the same baud rate on the paneldue setup menu. This would be a workaround rather than a fix though.

If you have spare end stop inputs you could use M581 to configure triggers which increments babystepping up or down. Just wire the buttons to the end stop inputs.

Could use E0 and E1 stops if you aren't using them for anything else.