How to Handle Parameter Conflicts with Firmware

1

When Ground Control connects with the Firmware, it requests the Firmware to report all the machine parameter values. When this happens, sometimes the Firmware has a different value than what is in Ground Control. When that happens, Ground Control needs to decide which value to use, and then set that value in both Ground Control and the Firmware, to ensure consistency. Right now, that functionality does not work.

My questions are:

  • When there is a difference between the Firmware value and the Ground Control value, which value should be kept?
  • Why?
  • Are there any situations in which we would want a different answer? e.g. we prefer the Firmware value in one context, and the Ground Control value in the other.

Thanks,

1 Like
2

just guessing - if you have multiple pc’s and multiple Maslows. Hacker space / schools/ heavy testers - I’m the latter.

Thank you

1 Like
3

I would say you need to report that there is a difference and ask the user.
There is no one right answer.

David Lang

1 Like
4

Thanks for the input. It makes sense.

Based on the input from @dlang, the solution is to create something to query the user for which is preferred: the value from Firmware, or the value from GC.

5

Shouldn’t the values match in the first place? Is the ‘scenario’ that you ran the “Holey Calibration .py”, edited your GC.ini and fire up GC where Eprom meets .ini?

Or is it also like?: You changed settings in GC that are written to the .ini and (for some reason) not stored in the Mega.

The questions to ask would be:

  • did you edit the .ini
  • did you change settings in GC the last time you ran it

For both the answer would be to overwrite the Eprom with the .ini, just guessing here.

1 Like
6

but if you managed to loose your .ini and GC created a new one with defaults,
you don’t want to overwrite the correct firmware data with the bad .ini data.

If you have access to more than one maslow, you want to use the firmware data,
not the .ini data

in both of these cases, you want to overwrite the .ini data with the firmware
data.

in the two cases you give, you want to overwrite the firmware data with the .ini
data.

that’s why I say there is no one right answer, when they conflict, the user
should be asked which to use (possibly listing the possible causes and saying
which is the correct answer for that cause)

This topic isn’t dealing with ‘my system broke’ but the more general ‘what is
the right thing to do when there is a conflict’ to define the action going going
forward.

David Lang

1 Like
7

Isn’t this difference solved the moment we find out how it accrues? Why are they not in sync, looks for me the way to move.

8

No. Not directly.

I was doing work to run calibrations, so I had made modifications to parameters in GC, via the GC GUI in the Holey Calibration process. Also, I was making modifications to the Firmware and re-programming the Arduino. I was not doing anything out of the ordinary, like modifying text files outside of GC. I am honestly not sure what specifically caused the two do be misaligned. Re-programming the Arduino is a red-flag. Another possible cause is a GC crash; if something goes wrong that causes GC to crash, it might not correctly update the *.ini file.

What I do know is there were differences in the parameter values, and GC did not correct them. Instead, GC kept its values and the Firmware kept its values. It is very misleading.

1 Like
9

I guess i was silenced, but will continue to read with great interest.

10

right, but we have to ask the user, we can’t say “this is what should happen
every time if they differ”

the initial post in this thread was asking which should win if they differ so
that GC could be configured to resolve the conflict automatically.

David Lang

1 Like
11

I’m not trying to silence you, just explain the part that you missed.

David Lang

1 Like
12

Does someone already have a list of parameters (guess that covers all values) on what are in the Eprom and what in the .ini and what are in both? (it would take me ages to put that together) I can see the workaround, a solution it seems not. What kind of users are you asking needs to be considered. The only case i can think of that the user changes a value in the Mega is that he has a command in a macro or in a.nc file and how many users that do that are we counting.

Happy to be not silenced and thankful for reminders going off-topic.

13

This is the code which manages how GC responds to these conflicts. I think the root-cause of why the conflict happened is more difficult to quarantine.

This kind of thing is in the code. For example, when GC connects to the Firmware, GC sends a “$$” command, which causes the Firmware to loop through a list of parameters, and report them back. That list of parameters has to be defined somewhere in the code.

1 Like
14

Abort -Retry -Fail

15

I think you need the following - Pop up dialog -

Hmm something seems wrong here, your .ini and rom are out of whack!

Do you want to use default settings? Y/N

Y write a default file, wipe eeprom, sync

N - leave the eeprom " please replace or repair your .ini file, you will remain out of sync"

Exit

16

I think you need the following - Pop up dialog -

Hmm something seems wrong here, your .ini and rom are out of whack!

Do you want to use default settings? Y/N

not default settings, they may be highly customized.

Do you want to use your Computer .ini settings, your Rom settings, Default settings or eXit and fix the problem yourself? C/R/D/X

Y write a default file, wipe eeprom, sync

N - leave the eeprom " please replace or repair your .ini file, you will remain out of sync"

if you use the ROM settings, you should update the .ini file with the data from
the ROM, not leave it broken (unless you want to add an “Ignore and continue”
option)

David Lang