RepRapFirmware 2.04RC4 released

[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).

[dc42]

@Adrian52, thanks for your report. Looks like output buffers are still being lost somewhere. I will look into it.

[jdjeff58]

@droftarts said in RepRapFirmware 2.04RC4 released:

@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

Hi Ian....i still have yet to troubleshoot my hardware other than smelling smoke from the PS. But I've been thinking about the historical problems I had doing firmware upgrades. As it stand, my 3Dprinter/Duet2 Mauestro are connected to my home network via ethernet. Being old school on wired networks, this is how everything is connected in my house up to and including my media devices and TV's.. However, the laptop I use to send files to the Duet, is connected to my network wirelessly. I've upload many print files this way but was wondering if this could be causing issues when trying to upload firmware. I've always used the upload tool in the web interface and have ALWAYS had problems updating firmware using that blue button.

[garyd9]

@chrishamm

I just got the CRC error again while trying to save a system file I was creating/editing in the DWC editor. I don't know if the problem is the duet firmware or DWC.

10/27/2019, 10:55:49 AM	Error: Uploaded file CRC is different (00000000 vs. expected f722db83)
10/27/2019, 10:55:48 AM	Failed to upload resurrect-prologue.g
Operation failed (Reason: err 1)

The second time I went to create the file in DWC from the same machine, it worked fine.

DWC is 2.04. The Duet Wifi is 2.04RC4. In settings->general, neither option is enabled in the 'general' section. CRC32 is enabled on the machine-settings page.

[chas2706]

@chrishamm

I get this as well but sometimes the system file gets deleted.
I just attempted to make a small change to config.g and after saving I got the error message 'Uploaded file CRC is different' but now config.g no longer exists.
Luckily I always save a backup.

[themelle]

@themelle said in RepRapFirmware 2.04RC4 released:

@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

@dc42 just a quick bump

[T3P3Tony]

@themelle you update the firmware using a ISP connected to the programming pads on the filament monitor (the 6 pads on the same side as the connectors) I use a USBTiny copatible ISP and pogo pins to do this easily. Adafruit make a nice one:
https://www.adafruit.com/product/46

[dc42]

The new firmware is released at https://github.com/dc42/MagneticFilamentMonitor/tree/master/Release-44a. Installing it requires a suitable programmer (e.g. AVRISP or USBasp) with a cable terminated in six spring-loaded pins to contact the programming pads on the filament monitor PCB.

The most significant change is that the new firmware sends the sensor AGC value to the Duet. This is a measure of the magnetic field strength. During testing it allows us to weed out sensors with marginal strength.

[garyd9]

@chas2706 said in RepRapFirmware 2.04RC4 released:

@chrishamm

I get this as well but sometimes the system file gets deleted.
I just attempted to make a small change to config.g and after saving I got the error message 'Uploaded file CRC is different' but now config.g no longer exists.
Luckily I always save a backup.

This is pretty bad if it can result in system files getting deleted. @chas2706 , are you using 2.0.4RC4? I thought I read something in the changes recently that would try to prevent deletion from happening:

File uploads are now done to temporary files that are renamed when the upload succeeds; so that if an upload fails, an original file with the same name is not lost

Perhaps that isn't enabled for system files? If that failsafe isn't working, and the CRC32 code between duet and DWC isn't working properly, it might be best to disable the CRC32 feature entirely and a warning shown if/when it's enabled. Something like "There have been reports of this feature resulting in files being deleted. Enable at your own risk."

(I'm turning of CRC32 on my machines for now. It's just too unreliable.)

[themelle]

@T3P3Tony and @dc42
Thanks for your replies - those are the answers I wanted to get in the first place; that is: the new firmware is available to the public, and flashing is done by a proven and well-documented process.
I just ordered a pogo-pin adapter from eBay, will give the new firmware a try when the adapter has arrived safely.

Thanks again!
Andreas

[chas2706]

@garyd9

Yes I am using 2.04RC4 and the latest DWC 2.04. The files definitely get deleted.
I did find that I had a config.g.bak file that seemed to be up to date but it is still scary when it happens (which for me is everytime I try to make changes to a file!).
I can get round it though by turning off CRC32 checking in DWC settings.

[wilriker]

@garyd9 said in RepRapFirmware 2.04RC4 released:

File uploads are now done to temporary files that are renamed when the upload succeeds; so that if an upload fails, an original file with the same name is not lost

Perhaps that isn't enabled for system files?

It is done for any file that is uploaded. The code does not care for what file is being uploaded. The issue here is that DWC will treat config.g in a special way: whenever it will upload a new version (i.e. when you edited the file and save it) it will first rename the existing config.g to config.g.bak and then upload a new file config.g (so in the rare case that you have a powerloss exactly in the middle you would also end up with no config.g). But when that upload fails due to failed CRC check then you will stop at where you only have a config.g.bak.

EDIT: interesting though is that DWC seems to send the CRC32 correctly but RRF fails to calculate it.

[garyd9]

@wilriker said in RepRapFirmware 2.04RC4 released:

@garyd9 said in RepRapFirmware 2.04RC4 released:

File uploads are now done to temporary files that are renamed when the upload succeeds; so that if an upload fails, an original file with the same name is not lost

Perhaps that isn't enabled for system files?

It is done for any file that is uploaded. The code does not care for what file is being uploaded. The issue here is that DWC will treat config.g in a special way: whenever it will upload a new version (i.e. when you edited the file and save it) it will first rename the existing config.g to config.g.bak and then upload a new file config.g (so in the rare case that you have a powerloss exactly in the middle you would also end up with no config.g). But when that upload fails due to failed CRC check then you will stop at where you only have a config.g.bak.

EDIT: interesting though is that DWC seems to send the CRC32 correctly but RRF fails to calculate it.

Regardless of how it's supposed to work, it isn't working properly. If it's also impacting system files, the CRC32 "feature" can be viewed as dangerous until the problems are resolved.

[jdjeff58]

This post is deleted!

[jdjeff58]

@droftarts Updated: I have done the troubleshooting. I have a bad power supply and the drivers burnt on the board. I have found out that the Maestro board that was made for M3D Promega is a troublesome board. My board's bad behavior when trying to upgrade firmware was typical for that board. Not sure if I'm going to continue on with this Promega or just get a different printer. Either way I was told that the duet wifi/ethernet is superior to the bastardized maestro. That's what I have been told.

[droftarts]

@jdjeff58 The Maestro is a capable board; I have one! I haven't had any problems with updating firmware, but M3D did roll their own version of the firmware. It depends what version you were updating from, too; there are some caveats updating from old versions. Sometimes it's better to erase the board and upload new firmware via USB, as described here: https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Fallback_procedure_Num_3

Have you got a link to where problems with this board are discussed? As far as Duet3D are aware, the problem seems to have been that the motors were not well matched to the board. I don't have any more details than that. If the PSU has died, is the machine still under warranty? I'd approach M3D and see what they say.

Ian

[A Former User]

@droftarts said in RepRapFirmware 2.04RC4 released:

Sometimes it's better to erase the board and upload new firmware via USB

still a good idea to study the whats new file to see if any new/removed features or configuration items will affect the use case.

[droftarts]

@bearer said in RepRapFirmware 2.04RC4 released:

still a good idea to study the whats new file to see if any new/removed features or configuration items will affect the use case.

Already suggested that!

Ian

[dc42]

@garyd9 said in RepRapFirmware 2.04RC4 released:

Perhaps that isn't enabled for system files? If that failsafe isn't working, and the CRC32 code between duet and DWC isn't working properly, it might be best to disable the CRC32 feature entirely and a warning shown if/when it's enabled. Something like "There have been reports of this feature resulting in files being deleted. Enable at your own risk."
(I'm turning of CRC32 on my machines for now. It's just too unreliable.)

Those reports apply to 2.04RC3. In 2.04RC4 the original file is retained if the CRC doesn't match, and to the best of my knowledge this feature works properly.

[dc42]

@droftarts said in RepRapFirmware 2.04RC4 released:

@jdjeff58 The Maestro is a capable board; I have one! I haven't had any problems with updating firmware, but M3D did roll their own version of the firmware. It depends what version you were updating from, too; there are some caveats updating from old versions. Sometimes it's better to erase the board and upload new firmware via USB, as described here: https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Fallback_procedure_Num_3

Have you got a link to where problems with this board are discussed? As far as Duet3D are aware, the problem seems to have been that the motors were not well matched to the board. I don't have any more details than that. If the PSU has died, is the machine still under warranty? I'd approach M3D and see what they say.

Ian

FWIW the Maestro in my M3D Crane Quad works very well. But perhaps M3D used different motors in the Promega.

The Maestro also works well in my Ormerod, even though that machine uses only 12V power.