RepRapFirmware 2.04RC4 released

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

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!