Posts made by dc42

@vladimir_u in the tests we did using a E3D V6 hot end, the compensation needed to act instantly, because the additional heater power took a small number of seconds to reach the nozzle, whereas the fan took less than a second to reach the new speed. So the fan speed increased faster than the heat reached the nozzle. As a result, the best compensation we could achieve still resulted in a slight dip in indicated temperature when the fan speed increased; but this dip was smaller than without heater feedforward, also the recovery to the set temperature was faster.

I am surprised that in your graph, the temperature is rising so much because of heater feedforward. Have you tested whether the heater feedforward is compensating correctly when you change the fan speed and leave it at the new value for several seconds? It may be that the feedforward constant (the second K parameter in the M307 command) is not appropriate for your hot end.

What type of hot end do you have, and what type of print cooling fan?

@schild0r yes it's possible, if you know what you are doing. See https://duet3d.dozuki.com/Wiki/M569.2 for how to read and write the TMC5160 registers directly.

@tekstyle I've tested that running as a macro under RRF 3.4beta7, and I don't get any error messages. So I believe whatever the issues were have been fixed. Please try that version.

EDIT: I did find an issue that doesn't give rise to any error messages. It is triggered by the M117 line being very long. Your M117 line has a lot of space characters after the trailing quotation mark, so it is triggering this issue. I will fix it in RRF 3.4.0rc1.

@bierent is your print cooling fan still working?

@vladimir_u I've checked the code. The only situations in which the heater power is adjusted are:

1. When a M106 command with an S parameter but no P parameter is used to adjust the speed of the print cooling fan for the current tool. In this case the feedforward correction is used, controlled by the second K parameter n the M307 command for that tool heater. No correction is applied if that second K term is zero.

2. If the VIN voltage measured by the Duet drops, then the tool heater power is corrected to allow for that voltage drop.

There is no path for a thermostatic fan turning on to cause a change in heater power, unless that fan draws such a large current that the power voltage drops - which would be unusual for a fan.

@sgk perhaps you just need to tab the cursor away from the Y origin box?

@jayt if you send M18 Z after the Z axis has been operated, does the bed drop the same as it does at power down? Or more, less, or not at all?

It may be possible to speed up the brake action by using an external circuit to control the brake solenoids. The reason is that the flyback diode that protects the mosfet slows down the release of the brake solenoid. I can provide a schematic of what's needed if you like. However, it will still take a little while for the spring to engage the brake after the solenoid releases it; so although this may help it's unlikely to be a complete solution.

Another thing you could do is to disengage the brake in the M911 power off script.

Regarding levelling at power up, have you seen https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors ? You need only probe the bed 3 or 4 times to level the motors. One they are levelled then you can load an existing height map, if that height map was obtained by probing immediately after the motors were levelled.

@pertti you should not need to set up any tool change scripts in Cura, assuming you have done everything necessary within the tool change files. Are you certain that your tool change files (tfree#.g, tpre#.g and tpost#.g) work regardless of where on the bed the pickup head is when you change tools?

@matt77 I can't think of anything that needs to be changed for 3.3 relating to the strength of extrusion.

Please try the following:

1. Run M98 P"config.g" to see if there are any error messages. If there are errors in your config.g file then the way they are handled may have changed between 3.2.2 and 3.3.
2. Send the following commands and post the responses:
   M584
   M906
   M913

It may be that your system had developed a poor stepper motor connection (or just possible a partially-failed driver) coincidentally with the firmware upgrade.

@deckingman if you use G11 in the tpost file then the amount of un-retraction will be the value configured for the new tool. However, the amount of z-hop that is undone with be the amount of z-hop done by the previous G10 command regardless of any tool change that happened in between.

@KevinMar it looks like you are using Duet Control Server 3.4b5 instead of 3.4b7. Please upgrade it via the package server.

@adam-v3d you might like to take a look at the CN Pendant project at https://github.com/Duet3D/CNC-Pendant-Firmware. This communicates to the Duet through the serial port.

If you will he using the USB interface to the Arduino as well, then I suggest you use an Arduino Leonardo, Arduino Pro Micro, or Arduino Mega. All of these give you a hardware serial port that is separate from the USB port. Also, the Leonardo and the Pro Micro accept 3.3V input signals, so although you need a simple resistive divider to reduce the Tx output of the Arduino from 5V to 3.3V, you don't need to level shift the output from the Duet up to 5V - although I suggest you use a 1K series resistor.

@tekstyle which firmware version? Standalone mode or with attached SBC?

@kevinmar please provide your config.g file and tell us which h Duet you have.

@dogma2k this is a documented limitation, see https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations#Section_Temporary_limitations. It is fixed in the latest 3.4beta build.

I've used telephone cable too for bench setups. However UK telephone cable is usually solid core, so I wouldn't recommend it for connecting a moving print head.

@deckingman said in M505 / M98 question:

Having just read that again, it may not make sense. Assuming I have /sys/SixInput/PrePrint.g and sys/SingleInput/PrePrint.g, and config.g had the line M505 P"SixInput", if the slicer start gcode was M98 P"0:/PrePrint.g" would it pick up the correct macro from /sys/SixInput.

No, it will look for the macro file in the root directory.

If so, do I need the "O:/" or would simply M98 P"PrePrint.g" work?

Yes it should work without the "0:/".

1. The CAN cable is not critical unless the cable is very long. Two single core insulated wires twisted together is good enough.

2. You don't need the terminator if you are using a tool distribution board. There is a jumper selectable terminator on the distribution board.

3. If the Duet main board is powering a high current bed heater directly then it is best to daisy chain the power from the main board terminals. Otherwise, it doesn't matter and it is usually simplest to run wires from the PSU to the tool distribution board.

4. The tool board has a built in TMC2209 driver.

@msamblanet yes you can pass multiple values where a GCode parameter needs them. See https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Use_of_expressions_within_GCode_commands.

@zivo said in Change axis order in DWC:

@dc42 y es, thats definitly the order

OK, so DWC is displaying them in the order they are created. So you need to create them in the order that you want them displayed.

Note this paragraph in the description of M584 on the wiki:

If you create more than one axis in a M584 command, the axes are created in the order UVWABCD regardless of the order of the parameters in the M584 command. This affects which axes will be hidden if you use the M584 P parameter to hide axes. For example, M584 C5 U6 creates axes U and C in that order, so M584 P4 would hide the C axis, not the U axis. If you want to create the axes in the order C then U (so that M584 P4 hides the U axis), use two M584 commands: M584 C5 followed by M584 U6.

@nxt-1 thanks for reporting this. That echo command work in standalone mode, so I've logged this as a bug in SBC mode.

@zivo with that config.g I expect the order to be X Y Z W C U V D. Is that the other you get in DWC?

@vladimir_u said in setting the temperature using 12864 mini:

@dc42 I can say with confidence that the problem with negative temperatures was on the stable release 3.3

What exactly is the problem?

@nxt-1 so do you think this may be an issue in SBC mode but not in standalone mode?

@peirof standard red/blue/yellow automotive crimp tools will crimp these terminals. There are ratchet tool to crimp these as well as low-cost non-ratchet tools that are included in generic tool kits, similar to https://www.amazon.co.uk/Rolson-Multi-Purpose-Crimping-Tool/dp/B004V9AROU (this is not a recommendation).