RepRapFirmware 2.04RC4 released

TPJensen

Is it possible to use costum logo ?

dc42

@TPJensen said in RepRapFirmware 2.04RC4 released:

Is it possible to use costum logo ?

On PanelDue we provide the means for you to use a custom splash screen. On 12864 displays you can use custom images in the menus. Beyond that, all the firmware is open source, so you can make whatever changes you like.

themelle

@dc42
Thanks for this release candidate. I will give it a try shortly.

I see a mentioning of a new firmware release for the magnetic filament monitor:
The new status information provided by Duet3D magnetic filament monitors with version 3 firmware are now supported
Are there any plans to release this firmware to the public?
And how does the firmware update process on the magnetic filament monitor work?

Thank you
Andreas

garyd9

@dc42 said in RepRapFirmware 2.04RC4 released:

It's at https://github.com/dc42/RepRapFirmware/releases/tag/2.04RC4. This fixes the issue with BLTouch introduced in 2.04RC3 and includes some other bug fixes and minor feature improvements.

I seem to be seeing a strange issue with delta bed leveling with RC4. Once in a while, after I level, I get a CRC error. (It's happened twice so far out of several dozen G32's) Here's an example:

10/20/2019, 3:25:56 PM	Error: Uploaded file CRC is different (00000000 vs. expected 8d5b3fb6)
10/20/2019, 3:25:53 PM	G32 Calibrated 8 factors using 13 points, deviation before 0.041 after 0.028

No, I'm not trying to upload anything. I'm just running G32 via the DWC2 console. Here are the (uncommented) lines in bed.g:

G31 X0 Y0					; don't want any probe offset for this
G28							; home the printer
G30 P0 X-86.60 Y-50.00 Z-99999 H0	; X tower  +.1
G30 P1 X0.00 Y-100.00 Z-99999 H0	; between X-Y towers +0.1
G30 P2 X86.60 Y-50.00 Z-99999 H0	; Y tower
G30 P3 X86.60 Y50.00 Z-99999 H0 	; between Y-Z towers
G30 P4 X0.00 Y100.00 Z-99999 H0		; Z tower
G30 P5 X-86.60 Y50.00 Z-99999 H0 	; between Z-X towers
G30 P6 X-43.30 Y-25.00 Z-99999 H0	; X tower +.1
G30 P7 X0.00 Y-50.00 Z-99999 H0 	; between X-Y towers +.1
G30 P8 X43.30 Y-25.00 Z-99999 H0 	; Y tower
G30 P9 X43.30 Y25.00 Z-99999 H0 	; between Y-Z towers
G30 P10 X0.00 Y50.00 Z-99999 H0 	; Z tower
G30 P11 X-43.30 Y25.00 Z-99999 H0 	; between Z-X towers
G30 P12 X0 Y0 Z-99999 S8		; center and auto-calibrate 8 factors

Edit: The error also pops up on the PanelDue..

I've run G32 several times since then from DWC1 and no error (on the PanelDue or DWC1.)

oliof

That's probably an error trying to write the heightmap.csv file.

chrishamm

@garyd9 It sounds like DWC2 attempts to replace the settings and/or cache file stored which then generates an error. Can you check what options are checked on the Settings -> General -> General panel and if turning off those options stops the error?

dc42

There was bug in 2.03 concerning resurrect.g and tool selection that was supposed to be fixed in 2.04RC4 but wasn't. I have put corrected 2.04RC4+1 binaries at https://www.dropbox.com/sh/mk3jlsoi6gyxd8q/AABbEvX2qb19McbRe6UvRmI9a?dl=0. There are no other changes from 2.04RC4 in those binaries.

Unless I receive other bug reports for release 2.04RC4 or 2.04RC4+1, I will release 2.04 final a few days from now.

resam

@dc42 about: Pullup resistors are no longer enabled on endstop inputs used to connect filament monitors when they are configured using M591.

This change feels like it is a severe breaking change that requires hardware (!) changes to a previously working printer. I'm not sure, but I think there has been no similar case in the past (or at least non that I remember) where a firmware update required hardware changes. Changing my config and adapting macros after upgrading a firmware is fine - but having to change hardware feels like a very invasive software update.

Is is possible to only disable the pullup-resistor based on the selected filament monitor? Or have it available as a new parameter to M591.

nhof

@dc42 This appears to fix the output buffer lockout issue I ran into last week. Thank you!

garyd9

@chrishamm said in RepRapFirmware 2.04RC4 released:

@garyd9 It sounds like DWC2 attempts to replace the settings and/or cache file stored which then generates an error. Can you check what options are checked on the Settings -> General -> General panel and if turning off those options stops the error?

Only thing on is "save cache in local storage." I just got the error again, this time after 4 G32's and a M500. (It happened after the M500.) (It's very unpredictable... I wouldn't know if it stopped happening because I can't seem to find a way to force it to happen.)

10/21/2019, 6:49:43 PM	Error: Uploaded file CRC is different (00000000 vs. expected 2a5cf7cd)
10/21/2019, 6:49:40 PM	M500

dc42

@resam said in RepRapFirmware 2.04RC4 released:

Is is possible to only disable the pullup-resistor based on the selected filament monitor? Or have it available as a new parameter to M591.

This is possible in RepRapFirmware 3.

It's likely that simple switch-type filament sensors will continue to work if they are connected to endstop inputs other than the ones on the CONN_LCD connector.

dc42

I have add DuetWebControl 2.03 to the RRF 2.04 release files at https://github.com/dc42/RepRapFirmware/releases/tag/2.04RC4.

Adrian52

@nhof The output buffer problem isn't completely solved for me. I have been printing on and off for most of the day, but now M122 does not return output, although the connection is maintained. M122 from yat gives a full response, with "Used output buffers: 14 of 24 (24 max)". Have tried restarting wifi, and updating dwc to 2.04. Thanks for your efforts - this is a big improvement over previous versions. Is there anything else I can try?

dc42

@Adrian52 said in RepRapFirmware 2.04RC4 released:

@nhof The output buffer problem isn't completely solved for me. I have been printing on and off for most of the day, but now M122 does not return output, although the connection is maintained. M122 from yat gives a full response, with "Used output buffers: 14 of 24 (24 max)". Have tried restarting wifi, and updating dwc to 2.04. Thanks for your efforts - this is a big improvement over previous versions. Is there anything else I can try?

Please disconnect your Duet from the network, wait 20 seconds, then send M122 from YAT again. I am interested in whether the number of used output buffers remains at 14, or drops to a more normal number.

PS - in normal operation, do you have any comms channels to the Duet apart from Duet Web Control? For example, Telnet, FTP, or USB?

Adrian52

@dc42 I am only connecting via dwc. Will try your suggestion tomorrow - thanks. Thanks also for the recognition of kisslicer alpha filament /time estimates - excellent.

jdjeff58

I'm going crazy over here. I just updated from 2.02beta on the M3D Promega and now my motors are noisy when running with D3 stealthchop enabled and constant nagging errors Duet error.PNG

When I edit gcode I will get errors saying can't delete file when trying to save. I tried the latest duet web interface 2.04 and reverted back to 1.22.6 and the firmware is creating all this the behavior is the same. Ugh....I've been at this all day duet config.g.txt

This was all working before and I decided to upgrade because the progress bar wouldn't work with files uploaded from Prusa Slicer. Every print I start the first layer is not level even after I ran the bed mesh leveling routine. And I can't delete my own files off the SD card????? WTF?

I'm just going to roll this back to 2.02beta if I can. I remeber actually rolling back to 2.02 beta from 2.03....These updates are absolutely horrible. No need to respond I'm sick of this.

droftarts

@jdjeff58 The errors are because you're loading the bed mesh in config.g (G29 S1), before Z has been homed. Better practice on Z homing is to clear bed compensation, home Z, load bed mesh/compensation. Apply this to your Z homing macro, rather than having it in config.g.

For the noisy motors, not sure. D3 StealthChop2 is the default for Maestro, so maybe remove D3 from M569 commands in config.g. As you call lots of macros for settings, I can't see if there are other problems in your motor settings. Otherwise I'd guess some issue with steps per mm/interpolation, or the 'V' parameter in M569.

You're using "M667 S1 ; Enable coreXY mode"; this is deprecated, use M669.

Not sure why you're having problems deleting/overwriting SD card files, but sounds more like a DWC incompatibility. Are you sure you updated this correctly? You can run v1 and v2 DWC side-by-side, by having both on the SD card, as they use different file names. To use v1.x, connect to your printer with reprap.htm on the end, eg http://192.168.0.4/reprap.htm. v2.x will load if you omit reprap.htm.

Unfortunately, firmware can't stand still, and feature additions and improvements require change that can make old code incompatible. Use the What's New document to understand how changes effect your setup.

Ian

jdjeff58

@droftarts This machine has now smoked...not sure if it is the board, the Power Supply or both. This SD card was made by the Promega community and made available to the dummy end users like me. I've gotten more proficient at using 3D printers since then, but when it comes to the coding, I was relying on someone else. So we jumped in at FW version 2.01 and everything worked and printer was printing fine although it had to be modded to run as a single extruder printer. So some of my code reflects that with all the commenting out of the 2nd extruder.

So as the community announced updates to this firmware/DWC, I followed along but had a miserable time even getting the updates to even install. I was finally able to get 2.03 to install and that's when the miserable whining started and I successfully rolled it back to last working quiet version 202 beta.

So long story longer....the SD card structure was built by M3D/the open source Promega community. I had nothing to do with it. Like I said, everything was running great...quiet as hell...printing nice for what the printer is (basically crap). I began to want to print some parts using Prusa Slicer. I've built 2 Prusa's and they are working superbly. And the progress bar in the duet web interface kept going to complete right when the print started. It began to bug me that I decided to upgrade the firmware/web interface based on a chat with somebody from the now defunct promega community. I figured by now the install bugs would have gotten fixed or easier to install but it hasn't...same crap trying this way and that way until it finally installed. Same thing with 2.04 DWC. 1.22.6 installed effortlessly. Motors were whining at idle. They quieted down with the D3 command added. The noise while motors are moving is (or was) tolerable I guess. But this thing was running fine with 2.02beta and DWC1.22.1. I should have just left it alone.

But now, likely through some "mishandling", the promega is dead. Sparks flew when I hit the on switch after a couple of high G adjustments...yes...I lost it...what can I say.

But for what it's worth...there are alot of newbs walking into these shows like ERRF and saying "oooh...aaahh...I want one of those". This code is being written for machinists and engineers and the instructions are so weak it's no wonder why this crap happens. You can't just get someone on the phone or go down to the local 3D printer shop and get questions answered. Github is a place akin to hell and if you don't have your secret decoder ring, you can't play with the group or be in the club. I don't even understand why you need to use words like "deprecated". Whoever writes this stuff needs to keep this in mind.

I do thank you for your patient and tolerant response. But it appear I'm dead in the water...at least on my duet maestro machine.

droftarts

@jdjeff58 Thanks for you reply. I understand your pain! The process of setting up a printer can be eased somewhat by using the RRF Configuration Tool, but there is still a level of technical knowledge that is required. The best place to start really is the beginning, here: https://duet3d.dozuki.com/Wiki/Step_by_step_guide

Duet doesn't have the option of a 'walled garden' approach, where it's just one printer type that's supported, so it has to be as customisable as possible, which does increase the complexity. We are working to improve the documentation, but with such a wide variety of printers, laser cutters, CNC machines, robots and who knows what else supported by Duet, along with new products and firmware versions being introduced, it's a battle!

If you find that your board is still functional (see https://duet3d.dozuki.com/Wiki/What_to_do_if_your_Duet_won't_respond), I'd recommend going back to the Promega community and looking for an update for your machine there, if you are unwilling to tackle the task yourself. I would say that if you start your own thread on this forum, this community is very supportive, and we'll get you up and running. You may learn something along the way, too.

And... "Deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use. It can also imply that a feature, design, or practice will be removed or discontinued entirely in the future." It's exactly the correct term to use when something gets changed/improved in the firmware!

Ian

Adrian52

@dc42 Disconnection from the network did not change the number of used output buffers (11 of 24 (24max)). The buffer usage during the day was: initial - 3 of 24 (8 max); 7 of 24 (17 max); 7 of 24 (21 max); 11 0f 24 (21 max); 11 of 24 (23 max). The next m122 from dwc gave no response, Yat gave 11 of 24 (24 max). This did not change after DWC closed, or after wifi switched off. With wifi off, I got a truncated response from yat m122. Switched wifi on again, got full m122, but buffers were 12 of 24 (24max).