Posts made by punamenon

@bearer Thank you!

As I understand it:
The PS_ON header has three wires. 5V, GND and Signal (PS_ON). The GND pin is connected to the GND rail of the Duet board. The 5V pin is an INPUT meant to accept 5v-20v from an external source. The PS_ON pin is controlled via M80 and M81 commands. When activated by an M80 command this pin will be connected to the 5V input pin next to it.

Is this correct?

Please forgive me for asking a question which should be easily testable and not require a forum post. I suspect I might have burned up this circuit, so I am trying to verify how it is supposed to work.

@Phaedrux Well, apparently the problem is not fixed in version 3.01-RC12. Bummer. Now I need to downgrade to the previous 2.05.1 version of the firmware. Bummer.

@Phaedrux The Chamber heater problem was on an older version of the firmware. 2.01 maybe. I need to get back to that project.

@Phaedrux Thanks! Helpful as always you.

maybe you'd prefer an old version of marlin?

Ha Ha. No thanks. I like the thermal runaway protection, I just don't like not being able to control what rise in temperature is determined unsafe. That's why I felt I was being Nannied. The issue as you explain it is more nuanced and I guess if it worked correctly (as it apparently does in 3.01) I wouldn't feel like I was being over protected.

-Ender 3 Pro printer with newly installed Duet2 WiFi running Reprap firmware version 3.0
-This printer was working perfectly running with a Maestro board and an older firmware version. No issues with bed heating
-When I try to heat up the bed I get the error: Heating fault on heater 0, temperature rising much more slowly than the expected 1.6°C/sec
-The bed is wired correctly with crimped ferrules going into the screw blocks, and the solder joints at the bed are flawless.
-I can get the bed up to temperature by babysitting it and manually increasing the temperature by 1° increments until the desired temp is achieved.
-The wires connecting the bed to the Duet are cool to the touch. Even when the bed is holding a temperature of 100°C

I believe that my only issue is the firmware setting that decided my bed heats too slowly. How can I change this setting, or disable it entirely. I don't like being Nannied here. I know my hardware works. The manufacturer knows it works. Why is the Duet board telling me that it is unsafe?

@bot That worked thanks. Turns out that it was retracting for each layer change already so I didn't need the M83, but that was a good tip. Thanks. Here is what I ended up with:

G60 S1 ; store current locating information
G1 X267.5 F6000 ; move off the edge of the bed for print wiping
G1 R1 ; recall location information from the G60
M400 ; wait until movement is finised before proceeding

Thanks Phaedrux M400 seems to be working, but I didn't do rigorous before and after testing so I can't say if it is needed or not. At any rate the above script achieves the desired outcome.

@bot Actually, it's a bit of G-code that I have implemented into my slicer (simplify 3D) By inserting it at every layer change.

I will try the changes you have suggested. These appear to be very good information. Thank you.

During Layer changes I want to move the print head to the far extreme of X movement. To this end, I am using a G60 S1, to save the last print location, then a G1 R1 to recall that location and move the print head back to the location. This is functioning perfectly. I'm having a problem with retraction. Specifically the re-priming of the nozzle to resume printing. As you can see in the code of my macro, the priming command is issued AFTER the "G1 R1" This should mean that the printer moves to the last print location before priming the nozzle. The machine is instead priming the nozzle before the print head has finished moving back to the saved print location. Is there a way to ensure that the Duet board will pause on a line of the G-code and not do anything else until the previous command has completed it's action?

G60 S1 ; store current locating information
G91 ; relative coordinates
G0 F2000 ; feedrate of 2000mm per min
G0 E-4 ; retract 4mm of filament
G90 ; absolute coordinates
G0 F5000 ; feedrate of 500 mm per min
G0 X267.5 ; move off the edge of the bed for print wiping
G1 R1 ; recall location information from the G60
G91 ; relative coordinates
G0 F2000 ; feedrate of 2000mm per min
G0 E4 ; prime nozzle for restarting print
G90 ; absolute coordinates

I updated from:
Firmware Version 2.03
WiFi Server Version 1.23
Web Interface Version 1.22.6

Board: Duet WiFi 1.02 or later (duetwifi102)

Following your instructions is the same as simply reuploading the new firmware .bin file. It updates the firmware without incident. After that update it still will not update configuration files such as config.g when pressing the "upload system files" button. Also, it does not restart the board for changes to take effect

I think the problem is with uploading a config.zip and having the duet unzip that file. When I unzip the files on my PC, and upload them individually it works just fine.

It's a new day and a new printer build. I just updated the firmware to 2.05.1 and the Web control to 2.1.3 tonight. When I click on the "upload files" button it tells me that it successfully uploaded, but the board doesn't restart for changes to take effect. I restart using the physical reset button. Nothing Changes. The only way I can update my configuration files is by popping the SD card out of the board and putting the configuration file onto it manually.

Uploading .gcode files works fine.

You may find that you need a file called iap4e.bin in order to update/upgrade the firmware on your Duet2 control board. I know of at least two people who have had this problem. This file can be somewhat hard to find at the moment because it doesn't seem to be included in the newer versions of the Duet firmware. Here is a github link to an older version of the firmware which does include this file. Simply put it in your duet file system and proceed with the update:

https://github.com/dc42/RepRapFirmware/releases/tag/v1.19.2

I hope this helps.

@Phaedrux Yes. 2.05 because 3.0 does not yet support BLTouch functionality. At least it is not an option in the online configurator.

@Danal I am receiving no Yes/No restart option. I don't know if it matters, but I'm running a pretty old Duet2 PCB. I just updated from firmware version 1.2

Bug #1
In the new Duet Web Control 2.0.7 when updating configuration changes made in the "RRF Config Tool" the user clicks the "upload system files" button, and then selects the config.zip folder which was downloaded. The files are uploaded to the Duet board, but a restart is not performed. This means that changes do not take effect until the User manually restarts the board. The board should restart automatically so that all changes may take effect. Otherwise the user will be confused why there is no change to the behavior of their printer.

Bug#2
When setting up a Delta Printer: In the "compensation tab of the "RRF Config Tool" the "Bed Probing for Delta Calibration" point matrix generation is doubly compensating for the probe offset. Those coordinates are the points where the probe itself touches the bed, not where the nozzle touches the bed as the points are being measured. This is correct and it is the only probe offset compensation needed. It is unnecessary to make the points asymmetrical in order to avoid having the probe measuring off the edge of the bed. As you can see, the points which are generated currently are asymmetrical. All that is needed to fix this issue is to remove probe offset compensation when generating the point matrix.

@aidar
Thank you. I will dive into this tomorrow. At first glance it seems like your reply may solve my problem. However, I welcome other feedback. I will be making a video on the subject, so any help which you provide to me will be passed on to many others. This is me: https://youtu.be/bFQjFvxiIkg

Ok, here are more specific questions:

1. How can I correctly activate Bang-bang for use with a chamber heater, so that it behaves as expected (not inverted as I talked about previously)?
2. If question #1 does not have an easy answer, how can I change the "temperature rising slowly" safety protocol for my chamber heater? This is clearly set WAY too sensitively. There is no reasonably affordable chamber heater that could possibly heat a cubic meter of air by 1.5° per second. That's crazy talk.

What happens when you use M301 H3 B1 as described in the chamber heater wiki?

It turns off the heater, triggers a fault condition, and gives me the warning
"Heating fault on heater 2, temperature rising much more slowly than the expected 1.5°C/sec"

I suspect that using the line you asked about does not activate bang-bang. As I said, the documentation is poor. Near as I can tell the "B1" parameter does not activate bang-bang. The documentation you referred me to does not say anything about a "B" parameter, however the documentation you told me to disregard does say the "B" parameter sets the sensitivity of the PID band (Errors larger than this cause heater to be on or off).

It looks like PID control will not work with a Chamber Heater unless the user can set the "XYZ° rise per second" parameter that triggers the heater fault for a chamber heater (M141). Otherwise, PID control will not work for chamber heaters. In that case, with PID not working, we need a way to get bang-bang working correctly. I believe it may be appropriate for me to move this discussion to the "firmware wishlist" category. I seem to have stumbled upon an undeveloped corner of the Reprap firmware. Alternately, I am mistaken, and this is a faulty implementation that I've done. In which case, the documentation should be edited.