@Parabolic:

@dc42:

PanelDue provides only one fan adjuster. It send the M106 command without the P parameter just as slicers do, so any fan mapping that you specify in your M563 commands will be used. You can of course use the Console page to send an M106 command for any other fan from the keyboard. You can also set up macros to set the fans in a particular way.

So…..if I add the F2 parameter to tool#1 then according to what you said, the "fan" button on the PanelDUE should be "linked" as well? I.E. show the fan speed for Fan 2?

Good point - I'll need to check which fan setting gets sent to PanelDue.

@dc42:

So the M307 H3 command isn't working, or else it is being overridden. Perhaps there is one in your config-override.g file as well? If so, delete it. If not, delete and re-type the original M307 H3 line in config.g in case it contains an unprintable character.

Ugh you're the best. I knew I was overlooking something simple…! It was overridden.

My config-override.g is as follows:

; This is a system-generated file - do not edit ; Delta parameters M665 L291.060 R144.158 H387.800 B120.0 X0.000 Y0.000 Z0.000 M666 X0.000 Y0.000 Z0.000 A0.00 B0.00 ; Heater model parameters M307 H0 A100.7 C757.4 D25.1 S1.00 B0 M307 H1 A516.8 C155.7 D2.9 S1.00 B0 M307 H2 A340.0 C140.0 D5.5 S1.00 B0 M307 H3 A340.0 C140.0 D5.5 S1.00 B0 M307 H4 A340.0 C140.0 D5.5 S1.00 B0 M307 H5 A340.0 C140.0 D5.5 S1.00 B0 M307 H6 A340.0 C140.0 D5.5 S1.00 B0 M307 H7 A340.0 C140.0 D5.5 S1.00 B0 ; Z probe parameters G31 T1 P500 X0.0 Y0.0 Z-0.05 G31 T3 P500 X0.0 Y0.0 Z0.70 G31 T4 P500 X0.0 Y0.0 Z0.00

Thank you so so much! Now I can figure the rest of this stuff out!

By default the enable signals are all active low. So when connecting external drivers, it's easiest to connect the enable output to the -EN driver input and the EN+ driver input to +3.3V.

If you connected the driver enable input between the Duet enable output and ground instead, you can use the R1 parameter in the M569 command for that driver to invert the polarity.

Most external drivers intended for use with 5V driver signals work OK on 3.3V signals.

Just for info, the 5 colour Diamond hot end is supplied with an 80Watt cartridge heater as standard. When I tuned it, the result showed that if unchecked, it could reach a potential temperature of 647 deg C. In use, the PID did it's best but it was impossible to tame the overshoot/undershoot. I ended up running it with 0.6 PWM which tamed it somewhat but I was still concerned that a failure on the control side would be dangerous. I don't know at what temperature PLA is likely to burst into flames but I do know that incipient red heat for metal start at around 500 deg C so to me, the potential to reach 640 plus is downright dangerous. A bit of molten plastic is one thing but flames are another thing all together. I swapped the cartridge for a 40 Watt one which is more than enough and would only reach 340 deg C unchecked (hopefully molten plastic but no flames) 🙂

Answered in your other thread.

OK, great!

Thanks for the direction… Slicer controls fan in G-Code... M106 not required in config.g.

Sorry about the additional work, lol!

VB,

The GPIO pins have high value (100K) pullup resistors to +5V. You probably need to use a much lower value pullup resistor to +5V to provide enough current to activate your mosfet board.

Homing Z will reset the Z=0 position. If the head is not at the same XY position as one of the probe points when you home Z, this may give you a slightly different Z=0 level compared to running bed probing after homing.

@appjaws:

sorry typo should have been M555

Ah OK. - (Still doesn't make an sense though). AFAIK, that only affects output via USB. Maybe it was moving the M669 to an earlier place in the file that fixed it ?
Who knows? Hey, it's fixed which is all that really matters.

Cheers

No worries. Glad you got it fixed. (and we've all done it so feel bad about it).

David, you are a legend. I'd configured the homeall.g file but not the individual axis files.

I owe you a beer one day.

I was considering slowing the acceleration on the external perimeters to get rid of some wobble and keep it high on hatching and travels. I had started to play with slic3r's acceleration control. Am I barking up the wrong tree here?

Edit: I'm optimising with the aim to get solid filled parts built as fast as possible.

Here are two options for powering the Duet off either totally or partially when a print has finished:

1. Provide a separate 5V power supply as you have done, and use the PS_ON output to switch a relay or SSR that feeds AC mains to the PSU. Then you can use M81 to turn off the main power. This won't actually save much power on the Duet, because if your end-of-print script turns off all the heaters, fans and drives, then the power draw from 12V or 24V will be very low anyway. But it does turn off the main PSU. To turn the PSU on again, send M80.

2. Don't provide a separate 5V power supply, but enable the 5V internal regulator. Connect a relay or SSR to PS_ON as before, also connect a mains voltage push button in parallel with the AC terminals of the SSR. Put M80 right at the start of config.g. To turn the printer on, press the push button for long enough to start the Duet so that it runs the M80 command and turns the SSR on. To turn the Duet off, run M81. Also make sure there is no USB cable connected, else it will supply 5V USB power and keep the MCU on.

Some notes on the above:

1. PS_ON is an open drain output. You can connect the control input of an SSR between PS_ON and +3.3V, +5V or even +12V or +24V. Similarly for a mechanical relay board that has an optically isolated input. If you connect the coil of a mechanical relay directly between PS_ON and a positive supply, then you MUST connect a flyback diode in parallel with the relay coil.

2. The only risk to removing power abruptly is that if you have enabled logging and the log file has not been flushed, then you could end up with a lost cluster on the SD card. The M81 command flushes and closes the log file (and turns off logging), also the log file is flushed every 15 seconds when there are new entries to be written.

Thanks!

I had the M29 without the filename and thought that was the reason for it not working so I changed it, as the RepRap-Wiki also shows the example with the filename.

I am troubleshooting the board. it would be helpful to know the expected resistance between 3.3v and ground. I only measure 53 ohms between 3.3 and gnd, which seems low, possibly a short. i have included an image. as for the end stops, i am using optical end stops, which i have wired correctly from instructions on the wiki. i can trigger the endsops manually and the board is not effected. when i run g28 however, the board seems to experience a software crash. it is very strange. it seems that it only crashes when the board is "looking" for an endstop input.
Here is the link for the photo: https://photos.app.goo.gl/o4goUBbz8ZwnPlfh1

What I actually recommend is motors rated at around 2A but not more than 3A. You can use lower powered motors, but I suggest no lower than 1A and preferably a littl higher.

thanks for sharing your input guys

I'm sorry, it's not pin 2 that carries +3.3V it's pin 3.

GreaT

@deckingman:

@peirof:

What mode is best? And… What is the difference?

Absolute values are still relative. The difference is that absolute values are relative to the start of the print, while relative values are relative to the last extrusion. An analogy that I've seen elsewhere (can't remember where) is like getting directions when driving a car. If the directions were relative, it would be something like this. Drive 1 km to point A, then turn left and drive another 2 km to point B. If the directions were absolute it would be like this. Zero the Odometer, then drive until the Odometer reads 1km, turn left and drive until the Odometer reads 3km.

It is generally best practice to use relative extrusion. The reason being that any extrusion move will be rounded off (albeit to5 decimal places). With absolute extrusion, the rounding error, no matter how small, could potentially accumulate and over several hundred moves, it could start to become significant. In firmware, any absolute extrusion values would have to be converted to relative in order to calculate how much filament needs to be extruded for any particular move.