RepRapFirmware 2.04RC4 released

themelle · 28 Oct 2019, 05:40

@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 · 28 Oct 2019, 09:16

@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 · 28 Oct 2019, 20:19

@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 · 28 Oct 2019, 21:52

@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 · 30 Oct 2019, 00:50

This post is deleted!

jdjeff58 · 30 Oct 2019, 00:53

@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 · 30 Oct 2019, 14:07

@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 · 30 Oct 2019, 14:20

@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 · 30 Oct 2019, 14:59

@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 · 30 Oct 2019, 17:44

@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 · 30 Oct 2019, 17:46

@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 · 30 Oct 2019, 18:46

@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 · 30 Oct 2019, 18:58

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 · 30 Oct 2019, 23:14

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

wilriker · 31 Oct 2019, 08:48

@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 · 31 Oct 2019, 12:56

@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 ?

wilriker · 31 Oct 2019, 12:57

@chas2706 There is no need to go the Erase-Reflash-Route. You can just redownload the firmware binary, upload it to the SD card and either run M997 manually or answer with yes if DWC asks you if you want to install the just uploaded firmware (if you do that via DWC).

chas2706 · 31 Oct 2019, 12:59

@wilriker OK cheers. I will do that and see if there is any improvement.

jdjeff58 · 31 Oct 2019, 15:13

@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

Hi Ian....the M3D Promega was an overall failure. It was poorly executed and it was cheaped out. Even with my limited experience, I was able to see where obvious corners were cut and shortcuts taken. Some of the more experienced guys were pointing out even more technical problems with the gantry, the motors, the idlers. M3D would ban people from the discord M3D.app for talking crap about the machine. (I at least give them credit for pioneering something as "banned for truth" has become pretty mainstream.) My contact from the user community told me (on the phone) this past week the M3D is all but shut down. As I said in one of my original posts that frustration peaked to the point of punching the print bed and likely surging the stepper driver(s). The machine along with the Promega community is pretty much dead. My contact bought 5 of their machines in hopes of boosting his production rates and he's stuck with a bunch of boat anchors. If you go on M3Ds' website they are selling the maestro for $99 all sales final. These people are the carnival that left town.

Mine was printing fine until I went and tried to update firmware and when I did it seemed like it wouldn't load the bedmesh as my prints were not level on the first layer. That was the final straw after all this screwing around with this horrible "project" Yes...it was not necessarily broke...although dual extruders were cut down to a single extruder, firmware painfully rolled back to 2.02beta (the only way I could get this thing to print successfully). So I was able to use it to print parts for my 2 Prusas....that by the way I built both from kits with an MMU2S on one of them and got them printing superbly from the start. Which is saying alot based on my experience level and comparing it to the stinking promega.

So the long answer to your question, the discord channel M3D was where all the noise was about the Maestro board. Testing was being done in the background proving numerous engineering mistakes/oversights/cheaping. These tests would either go ignored by M3D or just flat out lied about. The number of the screws used was cut in half and M3D came up with stupid excuses for having half the machine with open screw holes. Made the machine less rigid they said. They were explaining off all their cheaping out with some dumb explanation that made no engineering sense whatsoever. It needed a more powerful extruder motor as eventually someone fabricated a gearbox and later M3D sold a larger "upgraded" Stepper motor that yes...we had to pay $50 for. Anyway, even in my recent phone conversation, it was said to me that even the people at Duet were unhappy with M3D for one reason or another. And now I think I am hearing why.

So now that board and PS are burnt, I can either replace them and try to deal with the difficulty (at my current skill level) of setting up a new board, or shop around for a different printer. My contact told me to look into building a BLV Cube. Looks a little daunting based on what I've looked at so far. I need clear instructions for this stuff. So I'm still trying to sort out which direction I want to go.

Veti · 31 Oct 2019, 15:37

my maestro is working like a charm. i did get it from a duet redistributor.

could it be that the boards sold by m3d where cheaped out on as well?