Deleting config.g file

fcwilt

@idaho-creator said in Deleting config.g file:

@fcwilt Yea my network is channels is not near any other channel nearby. wifi signal strength is really good and the duet 3 connects but after a reset it might not connect until reset again. some times its several attempts sometimes its just once.

Hmm...

All I can say is I have 4 printers - one with a Duet 3 Mini 5, two with Duet 2 WiFi/Duex 5 and one with Duet 3 MB6HC.

I had to install a nearby WiFi Access Point to get reliable connections but once I did that I never have any problems with connection on power up or after a reset.

Frederick

idaho creator

It has now deleted everything in the config.g file but left the empty file. This is getting annoying I have not used it in a week because of this still occurring.

idaho creator

@fcwilt My wifi router for this section of the house is just on the other side of the wall. It has no issues connecting when it does but there are times it just wont connect.

fcwilt

@idaho-creator said in Deleting config.g file:

@fcwilt My wifi router for this section of the house is just on the other side of the wall. It has no issues connecting when it does but there are times it just wont connect.

Odd.

I have no idea why that might be.

Frederick

Phaedrux

Contact your vendor and initiate a warranty exchange. Include a link to this thread as authorization. There may be a problem with the SD card slot.

idaho creator

@Phaedrux Ok I will contact filastruder. Thanks

FrankV

@t3p3tony This was very helpfull. I accidentily pressed this macro and all files are gone. I will delete it. As a newbie you try everything....

lromberg

3 years later, and I've recently encountered the same issue on my Duet3D 6HC mainboard. Config.g and config.bak are deleted, yet there is the a new config.g file dating back to when we first started the mainboard last year - has the generic 5-6 lines of code.
All other files for homing the axes and all gcode files of previous jobs are still on the card. We've even printed sth about 4h prior to the deletion of the config files.
We also had that 2_test_macro preinstalled at from when we bought the Duet3D.

soare0

@lromberg said in Deleting config.g file:

3 years later, and I've recently encountered the same issue on my Duet3D 6HC mainboard. Config.g and config.bak are deleted, yet there is the a new config.g file dating back to when we first started the mainboard last year - has the generic 5-6 lines of code.
All other files for homing the axes and all gcode files of previous jobs are still on the card. We've even printed sth about 4h prior to the deletion of the config files.
We also had that 2_test_macro preinstalled at from when we bought the Duet3D.

Exactly today, when starting my printer (6XD+3HC, 3.5.rc2)... it would not start, so I checked every bit of SDcard, including formating it. After some file checking, I realised that my config.g was missing.

Yesterday I tried to print some stuff. I printed a little, but being ugly I stopped the printing, and then reload the file, resliced. I do not remember if exactly then, or after I used EMERGENCY STOP in DWC for some reason, I kept receiving some connecting errors. They would seem to pass, if I restarted the printer and DWC, but while reloading that file, at some point I got connection errors again.

Sometime later I gave up and started to change the nozzle. At this was for some reason complicated, I turned off the printer and gone to other stuff.

Today, starting the printer, it would not connect, neither to Panel Due, or DWC. I found config.g missing, and also config.bak.
The rest of the files were there, in good order.

Regarding the SDcard, formatted it, and it seemed to not have any errors. Also, yesterday, while the printer was still working, I did not messed up with the file system, at all.

The coincidence, two DUET3 filesystems loosing minds on 13-14.02.2024, seems to me, very doubtful.
I can understand a SDCard slot being faulty, but not simultaneously (basicly) on 2 (very similar) boards. And not resulting in the same file being f....d up. As I not familiar with RRF or DWC, I cant say in what condition exactly config.g would be erased, giben the fact that I was not working with the files, I mean editing or such.

While the file sent to the printer is large, It was just a Cura gcode file, and cant be sure if that iteration had something to do with the event. I can anyway submit it if needed, I did not parsed it, for now.

I am almost sure that this is a bug. Costing more than a month of work, because of my lazyness in doing backup lately.

L.E. What is (somewhat) funny, is that from the first occurence of this ...event, passed almost exactly 3years, 18.02.2021, so... RRF virus? Maybe the date of that system was 14.02... Valentine's day Duet bug. VDDB.

L.L.E. I recovered some part of my config.g from a forum post, at least my frustration is halved now...

T3P3Tony

@lromberg @soare0 @jameswookyz

Please confirm the firmwareand hardware versions you are running

soare0

@T3P3Tony Is there a possibility for that macro, 2_test_macro, to run, other than manually? The file was there, I left it undeleted being ”from Duet” (good file, hehe...), but almost 99.999% I did not touched it when that happened, as I was simply trying to upload a new file for printing.
I will inspect the Cura file to search for a M30. but I would say this is a long shot.
Meantime, I deleted that macro file, just for revenge...

Duet 3 MB6XD MB6XD 3.5.0-rc.2
Duet 3 Expansion EXP3HC EXP3HC 3.5.0-rc.2
Duet Web Control DWC 3.5.0-rc.2

RepRapFirmware for Duet 3 MB6XD version 3.5.0-rc.2 (2023-12-14 10:33:00) running on Duet 3 MB6XD v1.01 or later (standalone mode)
Board ID: 0JD2M-999AL-D25S0-7JTDD-3S46L-1N1B1

T3P3Tony

@soare0 it should only run manually, but yes please feel free to delete it.

droftarts

@lromberg @soare0 @jameswookyz

Please check if you have the factory macros, and in particular the one name '2_test_completed', in your macros directory. It's best to just to delete the factory macros.

Do you have a PanelDue? Because the macro is named with '2_' it probably shows up on the macro menu of the PanelDue (and DWC) as 'test_macro' at the top of the list. That puts it in a place that can easily be accidentally pressed on the PanelDue. Macros run from PanelDue, and from the Macros sidebar on the DWC Dashboard, run immediately, without confirmation that you want to run them. It can also be pressed at any point from when the machine is turned on, and you won't notice it has been run until the next time you reset or power cycle the machine, as that is when config.g is run.

I have these macros on my printer, though I have moved them to a separate folder in the macros folder. They have never run other than manually. I can't think of a mechanism where they would.

This is the '2_tests_completed' (it may have had a different name before):

;test completed macro for mini 5+ v1.0 testing
M30 "0:/sys/config.g"
M30 "0:/sys/config.g.bak"
M471 S"0:/sys/config_default.g" T"0:/sys/config.g" D1
M30 "0:/macros/SETNETWORK14"
M30 "0:/macros/SETNETWORK24"
echo "Test macros deleted - restart"

As you can see, it deletes config.g and config.g.bak, copies the config_default.g to config.g, and deletes the test network macros.

Ian

soare0

@droftarts Indeed, I noticed. Until now, I was not interested what is in that file, it appeared in Panel Due, but:

I was always very careful to not select it - I did it maybe a month ago once, and canceled
I was not working with Panel Due, but maybe I simply have a memory lapse, and somehow I did it. But, at the same time a guy at 2500km (I think) did the same thing? If this is the case, that macro is a real threat, wich is needed to be addressed more... carefully.

@droftarts said in Deleting config.g file:

As you can see, it deletes config.g and config.g.bak, copies the config_default.g to config.g, and deletes the test network macros.
Problem is... I had no config.g after the event, this meaning that either the deletion was due to another fact, or config_default.g was missing, wich is most probably.
I think that somehow, that macro file should have a warning, after its first run, like: ” Dear client, please delete this file now, or do back-ups frequently, or get some indica, or all of the above”.

I would reiterate the fact that it is very, VERY, unlikely, to have used (even unwillingly, wrong mouse click, etc) that macro, manually, when the event occured. As I was working in DWC, it is difficult to upload something and at the same time to run a macro file (and why that file?), especially loading by standalone board, as the speed is slow. You just go and wait.
I would rather think that somehow a communication fault trigger the event, but for two people, 2500km apart, in the same day, Tuesday 13 (I still think that the event comunicated on 14 happened on 13 in the evening), 2 very similar boards (firmware)... this is bad karma!

Joking (but real), my sister asked in the morning, hey bro, are you ok? Why? Cause it is Tuesday 13. I laughed and said , yes, but the day is not over.
Soon it had been over, making my sis a profet...

soare0

@droftarts

One suggestion: if that macro is used just one time, and is provided with the boards from factory, why not made it like this:

;test completed macro for mini 5+ v1.0 testing
M30 "0:/sys/config.g.bak"
M471 S"0:/sys/config.g" T"0:/sys/config.g.bak" D1
if exists (0:/sys/config_default.g)          ;pardon my french, do not know if this is possible
       M30 "0:/sys/config.g"
       M471 S"0:/sys/config_default.g" T"0:/sys/config.g" D1
       M30 "0:/sys/config_default.g" ; at least it will not happen the second time
else 
       echo "config.g undeleted, back it up immediately, or you may be doomed soon."
M30 "0:/macros/SETNETWORK14"
M30 "0:/macros/SETNETWORK24"
echo "Test macros deleted - restart and delete this macro after, or you will be doomed on a Tuesday, 13. No kidding..."

droftarts

@soare0 We are investigating, because the macro should be deleted when tested anyway. The testing process is about to change anyway, as we have new test equipment, so hopefully the macro won't be needed or put on the next batch of SD cards.

Ian

soare0

@droftarts
config.g/config.g.bak, are small files. They easily may be stored in some onboard NVM, protected, available for easy restore. The same is true for all sys and macro files. This could be implemented in Duet 4 boards... maybe, with an onboard memory, protected, and sdcard used only for the rest, even if it is possible to store all of the files in a larger internal memory.
Just my 2c
Back-up is a good and cheaper alternative though,...