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

This is an option I've used before, maybe not 'soft', but it looks clean and easy to break out different wires at different points: https://www.amazon.com/dp/B07JQ1QHVF/

Other thing I've used is paracord sleeving, something like this: https://www.tweaktown.com/guides/5175/case-smithing-getting-started-with-diy-cable-sleeving/index.html

Paracord is a little softer than the expanding nylon sleeving and looks better IMO, also has a large color selection.

I'm surprised they won't send at least a binary... it's not like anybody is gonna spend the time to reverse engineer and steal their super valuable corporate top secret 3d printer touch screen firmware specific to their machines .

If their version uses elements of the original PanelDueFirmware then they should provide the code per GPL as they are redistributing the code inside their physical product. But if they rolled their own firmware I suppose they can sit on it.

Maybe you could implement zones using G10 workplace coordinate offsets? It should work well for mutually exclusive fixed size zones. Trickier bit would be a way to track which zones are ready to go and which are already used.

I know Ultimaker has a print queue already implemented, you can enqueue several jobs, and the only user interaction after is a confirmation that the print area is ready to go (i.e. print removed, bed prepped between jobs). iirc It even supports multiple printers so you can just send all your jobs to a central queue from which they are dispatched to any available machine. Pretty nice.

yeah they're standard A4988s

The socketed drivers can also give out from time to time, so it may be worth checking those to see if they are still good on the ramps.

I have used both old and new machines but I have not upgraded 1000 to duet. Most of the base hardware is common (motors, extruders, &c), the main challenge will be changing / modifying the old wiring harness to work with the new box.

Some suggestions:

• Route the 48V power for the drive motors through individual cables to each motor, rather than inside the controls wiring (prevents future problems).

• See if their support is willing to give you a wiring schematic for the old unit. If not, start your own documenting for which wire goes where. The 3dp1000 units have pretty well labeled harnesses, so this should not be too difficult if you have to start from scratch.

• The machine is pretty standard outside the mechanics, with motors, extruders, etc. as on every other printer, so don't overthink it.

@jzagaja Yep I am familiar with those machines although it's been a while since I have touched any of them. What's up? May want to start a new topic as this one is p old.

If you wanted to confirm, you could always run the M143 H0 command manually from the console once the machine is already on, it will read out the max temp settings.

Also note that if you want temps of 180, you should set the max temp to a bit higher than 180, else it may throw an error every time it goes slightly above the setpoint, which would get annoying to deal with.

Try logging periodically with M573 to see what PWM the heater is running at under full load. This should give you an idea of whether you can tune the control values up.

For example, if it's constantly running a PWM of 1 (full power) then you are just running too fast for your heater power. At that point your decisions will be either print slower, substitute a more powerful heater, tune the voltage up as high as possible if you have adjustable output, or cut wasted heat by insulating better or something like that.

If it's running a lower PWM value, say 80-90%, or it oscillates around, then you should still be able to tune it up, maybe by aggressively increasing the gain? I prefer just using overpowered heaters, although there's some safety things to consider here.

Could you just locally cache and display the babystep request on the paneldue, until the object model updates it for real? Kinda hacky but it might help smooth out the user experience if you can't get the update rate up enough.

@chris974M Yes, the PT100 or thermocouple should work well between 200-450C.

If you have questions on the temperature sensor components you can also check with Dyze Design. They are in Montreal, so they can help you in French as well