RepRapFirmware 2.04RC4 released

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.

garyd9

@dc42 said in RepRapFirmware 2.04RC4 released:

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.

According to @chas2706, the original file is deleted or renamed with 2.04RC4 (with RC3):

@chas2706 said in RepRapFirmware 2.04RC4 released:

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.

dc42

UPDATE:

There is an intermittent problem when you upload to 2.04RC4 with CRC checking enabled. Sometimes the CRC calculation is not carried out, resulting in the calculated CRC being reported as zero and the upload failing. Uploading to RRF 3.0 beta11 or later with CRC checking enabled does not have this problem.
This issue is compounded by the fact that whenever you edit config.g, Duet Web Control first renames config.g to config.bak. So even though RRF 2.04 doesn't replace the original file until the upload has definitely succeeded, this renaming means that if you try to edit config,g and the upload fails because of the CRC calculation or any other error, the original config.g file is left renamed to config.bak.

chas2706

@dc42
In my case it is not intermitant it is guaranteed as long as crc checking is enabled.

wilriker

@chas2706 Have you already tried flashing the firmware again? There are very rare cases where flashing succeeds as a process but something was still going wrong. Usually flashing the firmware again (after a fresh download) helps then.

chas2706

@wilriker I just did an upgrade from 2.02RTOS.
Are you talking about just going through the upgrade process again or pressing the erase button and re-flash with 2.04RC4 ?