I think it would look pretty cool if there was a current layer visualization panel on the web interface. Maybe it could update with what paths it has drawn so far. I was thinking just a simple 2D one similar to the way pronterface displays G-code. I don't know how resource intensive it might be but I think it might be a cool extra feature if Chris or someone has the time to spare.

I've been noticing that DWC becomes very slow to respond if the page is not reloaded for a few days. This is especially problematic when using an SBC with a display plugged in, since it is not easy to reload the page without a keyboard attached (like in the case of a kiosk mode browser using a touch interface), though it also happens on Windows 10 in Firefox. We are using DWC 2.4.6

@curieos I found the answer to my own question. https://docs.duet3d.com/User_manual/Reference/Gcodes#m563-define-or-remove-a-tool I can use the L parameter to set which drive to map filament to.

@fcwilt I considered your method, but I foresaw maintaining parity with PrusaSlicer being a massive headache. That and, assuming a good amount of filament presets from multiple brands, the filament selection UI would balloon in size, similar to scrolling through all of the filament Prusa has in PS for their printers. I opted to go a generic route for DWC, which is a compromise to maintain usability. I don't want our customers to scroll through multiple pages of filaments in the UI, only to fat finger the wrong one (or accidentally tap PA6-GF instead of PA6-CF). The primary method of interacting with our machine is a touch screen.

If it existed, I would use it primarily in the pause/resume macros, though it could also be useful for the nozzle change macro.

@chrishamm I bumped it up to what I believe is the max, 115200, and it's still inconsistent.

@infiniteloop said in M911, Print not Resuming After Voltage Threshold is Reached:

As @Phaedrux states, you need to check carefully whether it is safe to proceed. If you suffer from frequent power outages, there’s no other way than to install a UPS.

You're not understanding, this is supposed to be a large, industrial machine that offers power loss recovery as a selling point. At our shop we do occasionally suffer from momentary outages, but that's not the point. We can't account for a customer's situation.

For one, most UPSs can't handle the amount of AC power this draws (just shy of 1kW while printing). We got the DC supply buffer to ensure the DC system could remain powered long enough for the Duet to detect it.

Two, this machine is large enough that prints can go on for weeks. If a 2+ week long print using tens of kilos of plastic fails due to a power outage that lasts less than a minute, that could be hundreds or thousands of dollars in material that is now scrap.

@infiniteloop said in M911, Print not Resuming After Voltage Threshold is Reached:

…and the print is left in a paused state
After the power is restored, you can use command M916 to resume the print from where it stopped.

It does not say, explicitly, that it won't resume after a full power loss incident. It also doesn't clearly explain the "R" parameter and what the expected behavior is. This is all that I can find in the docs:

Raaa Resume threshold in volts. Must be greater than the auto save voltage. Set to a high value to disable auto resume.

Hence my confusion. I can make a macro to enable this behavior, so it's not a huge deal, but it's not clear from the docs.

Regardless, it doesn't do the 100% expected behavior of resuming after a blip, where AC power is restored before the DC system fully loses power.

It was the wrong part number, I got the new one installed and avrdude accepted it for programming.

@dc42 I may have fixed it.

Turns out on this unit, there was a zero impedance connection between DC ground and Earth ground. I found the culprit, the cutout for the ethernet extension plugged into the pi was made upside down. This meant the shielding on the plug was in contact with the aluminum frame panel. The panel is powder coated, but it appears the coating wore away in this area. I flipped it upside down and now the grounds aren't shorted.

I ran a 6 hour print last night and there were no issues. The longest I've seen it go without locking up was 3-4 hours, so I think this means the problem is solved. I'm running a slightly longer print (22.5 hours) now, so that will definitely be definitive.

@Phaedrux said in M911, Print not Resuming After Voltage Threshold is Reached:

The same could likely be achieved with the object model and conditional gcode if you desired.

Yes, I know, that's what I meant by this:

@curieos said in M911, Print not Resuming After Voltage Threshold is Reached:

This logic can be implemented into the resurrect-prologue.g file very trivially.

In fact, I already did.

@ReXT3D What settings did you end up using for Klipper? Did you set the sense resistor value to 0.076, or did you have to configure vsense somehow? I'm having some overheating issues with the example klipper config, even with the motor current set quite low.

@chrishamm I bumped it up to what I believe is the max, 115200, and it's still inconsistent.

@DonStauffer It works fine on a printer that I have a Duet 3 Mini with a 12864 Display running in standalone mode.

I think it's a problem with the PanelDue. I believe the RRF team is already aware of other problems caused by it in standalone mode. The inconsistent M300 behavior is probably related.

@OwenD The SBC setup has a daemon file, but the Duet 2 setup does not. I've tried them on an SBC setup without a daemon file and it's also inconsistent.

We've been working on buzzer alerts for our machine. It's been a little frustrating because they don't play consistently. We've been testing on a Duet 2 wifi in standalone mode with a PanelDue attached, as well as the machine it's destined for. The machine is a Duet 3 6XD in SBC mode with a PanelDue. Neither of these setups play consistently. Firmware on the Duet 2 setup is is 3.5.3, and the Duet 3 setup is 3.5.2.

Examples:

M300 S5000 P100
G4 P150
M300 S5500 P100
G4 P150
M300 S6000 P100
G4 P150

M300 S6500 P69
G4 P250
M300 S6500 P69
G4 P100

Sometimes the first tone is cut off, sometimes the delay between tones varies by a significant amount, and sometimes it skips tones. Running them from the PanelDue is slightly more consistent on the Duet 2 setup.

I believe I have replicated it. I put M400s and echos into the pause and resume macros to get more useful information about user and machine position, but I think the M400s caused the issue to not happen.

It appears to occur regardless of how the machine is paused (filament monitor error or manual pause), or which interface resumes it. It appears that all it takes is one pause on the secondary tool. The ones I'm producing currently are small but noticeable, and don't occur without a pause. I believe multiple pauses create a larger shift.

I've confirmed pauses while the primary tool is active do not cause the shifting. I've also confirmed adding an M400 to the end of the resume.g file prevents this shift.

Configuration repo

@timschneider No, there are retractions in the pause and tool change files, but we do not use M207 and G10/11.

We have a customer with this issue. I've been able to reproduce it, but I haven't determined the steps required to reproduce it.

Both our machines are on 3.5.2. It's two 6XDs and two 1LCs in SBC mode with a Pi 5, using the image from April. There is also a PanelDue running the latest firmware. It appears to occur when the filament monitor detects a jam on the second toolhead.

I have theories as to what happens. It appears that it occurs specifically when a jam is detected, the print is paused, and then the print is resumed by the user without clearing the jam. It then pauses again since the jam wasn't cleared. The user then resolves the jam, resumes the print, and an offset is observed.

It may also have to do with resuming from the PanelDue. I observed this issue, more easily repeatable, with a machine that had an out of date PanelDue. I have verified with the customer that the latest version of that firmware is installed, and during all of the observed events it was on 3.5.0.

I'm still attempting to replicate the issue repeatably. I know 3.5.3 is out, but I don't want to try it until I can make the issue occur intentionally.

@chrishamm When will the new duet pi images be available?

@chrishamm Will this be fixed in a DSF update? We'd like to know if our customers will have this issue if they update in the future.

I updated the packages via apt this morning on a machine in SBC mode, and after restarting the Pi I'm getting this error:

The setup is two 6XDs and two 1LCs. The Pi is a Pi 5 running the bookworm image from April 19th. Fully rebooting the machine (cutting power) does not work.