Deleting config.g file

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

Krzysztof

Hi everyone, are there any updates on this topic? We encountered the same issue with our machine yesterday. Unfortunately, it happened on the machine we had sent to our customer for evaluation
We need to act quickly, so the best solution was to ask them to remove the microSD card from the machine and copy a new configuration file onto it. As you can imagine, they weren't very happy about it
Our setup is a Duet3 6HC running RRF 3.5.2 and DWC 3.5.2.

droftarts

@Krzysztof As far as I'm aware, shipping SD cards don't have the factory test macro that deletes config.g on them. I don't know if SD cards that you prepare and ship with your machines do. Other older issues with the config.g file deleting when changes are made have been fixed for a long time in firmware. We haven't had any reports of the config.g being deleted recently.

As suggested before, check that the factory test macros are deleted from the macros folder.

Ian

lazy_mosquito

The same problem here. I have a 6xd board. And very regularly the system deletes my config file. It happens always after an emergency stop in the web interface.

Now i used for the first time the STOP button in the paneldue. After this STOP i rebooted and the duet is not connecting with the web anymore. In the paneldue i got a startup but without configfile. So no connection with the webinterface and no homing, so no printing. When the SD-card was checked in Windows. the SD-card was not readable anymore in windows and after complete format as ex-plained in the duet documentation it is ok for windows but stil not readable according to duet. (No errors with windows check and the files are there in Windows)
So now i can start up my delta. i get a screen in paneldue. it can't find the sdcard and i get no internetconnection anymore. So, i suppose it is starting up from eprom but is not reading anything from the sd-card file.

Using all the newest firmware for as well the board as the webinterface

Any idea?

Phaedrux

@lazy_mosquito
Your issue sounds more like an issue with the SD card slot on your particular board. I suggest you create a new thread for your issue. Please include some pictures of your SD card slot soldering and when and where you purchased the 6XD.

droftarts

@lazy_mosquito as @Phaedrux suggests, please start a new thread. Please connect via USB, send M122, and post the response. Also see the troubleshooting guide here, and post the responses to the commands found there: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues

Ian