Best posts made by curieos

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.