Issues with saving grbl settings on BSCM04U bob

[gharbarka]

I am experimenting with a setup based on the BSCM04U board which sports an F103 clone and IOsender in Windows 10.

Saving the grbl settings appropriate for my hardware appears to work as long as I keep the board powered up. On some occasions after removing the power completely from the board and then powering up after a short period of time the settings are remembered but if I leave some time before powering up the settings revert to the default values.

Another minor issue I am facing is that sometimes, when saving parameters I get a warning stating "Settings Write Failed". Pressing save again however works which seems to indicate a USB issue. However, when I run a gcode program which last about 10 mins the program seems to run smoothly so I guess the USB interface is working correctly.

Similar results are obtained when I run this board with bCNC and Arch Linux.

Is there a solution to this issue please?

[terjeio]

Is there a solution to this issue please?

Short of replacing the MCU with a genuine one? I am not sure.
Since I am away for a while I do not have access to my BSCM04U board wich have a genuine ST MCU. I could use that to reverify the code. However, only BSCM04U users has reported this issue so it is likely correct? BTW most of the code is in the STM32 framework and some even in ROM?

What I could do is to add a few retries if "Settings Write Failed" before giving up - maybe that could help?

[terjeio]

A basic 3-axis driver:
Firmware.zip

[gharbarka]

Yesterday I reprogrammed the board with the software provided and proceeded with changing settings and saving. Apart for the occasional write error which I had mentioned in my first message, initially saving proceeded without a hitch.

I switched off and even disconnected the USB cable and then rerun the program to check if the changes had been retained.
I did this after one hour and then after 4 hours and the changes remained.

This morning, about 12 hours later, I switched on again and to my delight the changes were still there.

I then proceeded to make another couple of small changes and saved, but unfortunately when I switch everything back on everything went back to default.

[terjeio]

If possible you should try the other board.
When I am back home I'll verify the code again, until then I believe there is not much more I can do.

Another idea I had is to alter the default values in the file config.h to the figures which work for me and carry out a recompilation on the CubeIDE. That assumes that I understand fully all the things I have to change to suit my board.

The setting numbers related to the config options can be found in the comments, it should not be too hard to figure out which to change,

[gharbarka]

Sorry for the late reply but I had issues with my stlink dongle and also needed to think up a robust way to install the 4 programming pins on the second board which, unlike the first, did not have the tracks already edged out.
Anyway I have now programmed the second board and thankfully the changes in the settings have now remained intact for at least one day. Also I have not yet noticed any "failed to save" errors on this board. Fingers crossed.

[terjeio]

Is the the second board still keeping the settings intact?

[gharbarka]

I have not been using the system for the past 2 weeks since I currently have the mechanics disassembled in order to rebuild my CNC to a more robust setup.

However I was using the system regularly before that and am glad to report that I have had no more issues with data loss. I did get a couple of times the message that the board failed to communicate briefly but there was no apparent negative effect on operation.

While on the subject, at the moment when the system halts after a limit switch gets triggered I have to switch off the power to the stepper and manually reach for the ball screw to move that axis in order to toggle back the limit switch. Only then I am allowed to clear the error and resume operation. This is not easy for me as one of the ball screws is not easily accessible.

Since the machine should know in which direction it was moving when the limit switch was triggered is it at all possible to allow jogging after such an incident ONLY in the OPPOSITE direction to toggle that limit switch?

Cheers.