System files check

Veti

which firmware are you running?

version 2 has a lot of defaults.

version 3 does not.

fcwilt

Hello,

I,ve found that deleting a file in sys folder makes no impact for running a firmware. The lack of file is noticed only in the monent of calling a function. Is it possible to perform a self check of firmware at the beginning of run ? I mean that in case of a lack of file should be clearly noticed right after powering on the electronics.

How do you envision that working?

The firmware would have to scan each file found to see if there were valid references to any files that were not present.

That might be doable.

Frederick

Phaedrux

What files specifically are you talking about?

Arek

@Veti I am running version 3. When you deleta a system file responsible for some action nothing happens until you call the action. If you push the button on screen the firmware responds with error message, but in my opinion this message should apear at the beginning, when you turn on the electronics. This means that firmware is unaware of deleted files (function files) util you call them. That, in my opinion isn't a good solution, because it may lead to unexpected results.

Arek

@Phaedrux pause.g, trigger3.g, trigger.g etc,

Arek

@fcwilt said in System files check:

envision

When you see a main screen on tft there are many buttons. Each button triggers an action. When you delete a file responsible for such action you get an error message or nothing would happen. So, imagine that someone by mistake, has deleted a file responsible for emergency stop, and during the operation this button is pressed in. Nothing will happpen but you get only an error message...

Phaedrux

Well the Duet isn't really designed around babysitting the end user. It's a very powerful system, but with great power comes great responsibility. Why would you delete a system file in the first place? Many functions may not be used by some printers at all. So how would the firmware know what a relevant file is or not? What about custom macros?

The firmware assumes you've configured the printer. There would be too much guesswork involved in predicting what every user expects.

Arek

@Phaedrux Well, please do net get me wrong. It is powerful system, but many basic functions are hardcoded in competitive systems. I do not see any advantages in allowing flexibility for basic functions that refer to g-files. I am rather talking about safety. As you know, deleting a file through a web application isn't a big deal. In my opinion when you see a bunch of buttons on tft screen, you assume all of them are working. It's not about custom macros. It's about firmware that points to files that may not exist even without warning.

Arek

@Phaedrux As an example. You have a car that almost all things are wired. Your brakes are controlled by wire and requires a g- file to strat an action. If there is no a g-file for your brakes your car should not start. If it does you probably would be in a big trouble when you put the brake on. Why ? Because nothing happens due to a lack of g-file, and the only thing you you would see before a crash is a warning message on your control screen - no g-file found.

Phaedrux

This is what commissioning is for. You need to implement your configuration for the printer.

You should be using the config tool to build a config file set that contains all the required files and then testing it before using it.

https://configtool.reprapfirmware.org/Start

A Former User

If it boils down to having PanelDue throw an error if it tries to run a non-existing macro then its a reasonable feature request to either throw said error and/or ensure the displayed macros match the filesystem at any given time. (erase operations could perhaps trigger an update to the PanelDue?)

OwenD

If that type of checking is important to you then I suggest creating a macro which uses M38 to check for the existence of whatever file(s) you're worried about and call it from config.g
Which files are critical may well depend on what the board is being used for and which board it is.
Hard coding such checks would likely have negative effects on many users for a use case that is arguably of limited value.
The firmware checks at the time of usage because that's the logical assurance that the file in question is actually going to be used.

Arek

@OwenD Thanks ! Your solution is awesome !