Would anyone be against making FAKE_SERVO a firmware setting rather than a define directive? It would greatly assist in testing and troubleshooting firmware and eliminate the time to recompile and upload firmware.
To make sure someone doesn’t accidentally put it into fake servo mode, we can make it an integer and someone has to type in the correct number to put it into that mode. Some special number that answers the ultimate question of life, the universe, and everything…
I think it should be easily set, and I don’t see a good reason to make it
cryptic, instead make it so that when if fake servo mode it regularly outputs
a message (say ‘motors disabled, in fake mode’ or something like that)
One thing to be aware of is that by going into FAKE_SERVO mode, one loses the real chain position. Just means recalibrating the chains, but needs to be remembered. I use a second Mega and drive board, but then I’ve got a number of those on hand 
Most of my development isnt with an actual sled attached and sometimes I’ve got a real firmware installed. Just would be easier to flip a switch than to recompile/upload.
make it so that when you turn on fake mode, it reports the current chain lengths
so they can be changed back later (at least for the first cut, long term why not
save them when you go into fake mode and restore them when you go out of fake
make?)
David Lang
Are you thinking something in the Settings/Advanced list, or a Bxx directive?
It could be either. A b command would be pretty easy to implement (no changes to ground control if you require it to be macro). We could potentially save the current steps to eeprom before entering fake servo and restore it upon exiting fake servo.
But then again… do we need to save steps while in fake servo mode?
Better make as few changes as possible, just save/restore when changing modes. Instead of a Bxx command, maybe a $RST= something in systemExecuteCmdstring()?
Would be easy to save current steps upon entering and restore upon exit and block saving when in fake servo mode… I think it makes sense to save the state (whether fake servo or not) and easiest place to do that is as a firmware setting. If that’s the case, it would be easy and simple to add it to advanced settings of ground control and webcontrol.
That worries me, not sure what the hidden consequences might be.
I’d say use a separate location for saving the position when entering FS, leave the normal position handling alone, still operating. When leaving FS, restore the position from where FS stored it. FS is supposed to be as much like real as possible.
Note that adding position saving adds a testing burden to the change. If there is no expectation that the chains should maintain calibration, rigorous dynamic testing wouldn’t be needed.
Just ran a cut filke in FAKE_SERVO mode with motors attached. The motors move, because of the way FS “Adds up to 10% error just to simulate servo noise”. Even with the randomness removed, the motors are clearly not completely still.
I worry about reducing the usefulness of FS mode by trying to avoid chain recalibration. How about we just assume that the chains will need recal if FS mode has been entered/left? Maybe post an alert on exit to remind that they need recal?
If the motors move while in fake servo mode, then you should never run it in fake servo mode with a sled attached. Considering the users of fake servo, I don’t think a warning is needed… I think that would be expected if you ran the motors without a sled attached Let’s just make it a RST or B command to enter and leave the mode and save the setting in eeprom under settings… it doesn’t have to have a firmware key assigned, just put the variable at the end. I prefer the B command because it’s slightly easier to implement.
If we do that, we have to change the SETTINGSVERSION, and that means EEPROM settings would get set to defaults when the firmware is first used for all users whether they care about this or not. Can we avoid that by not saving the state of FAKE_SERVO under the official settings? Maybe poke a byte out at the end of EEPROM that only FS knows/cares about; if that byte gets trashed the board doesn’t go into FS mode.
Is there a free byte in between the structures? Is the eeprom perfectly packed or were the addresses picked provide some space where we can use one of the bytes. Not at a computer to try to do a sizeof
Settingsversion starts at 300 and is two bytes of data… steps start at 310.
Here’s a whack at it.
- $RST=F toggles the state
- the state is saved in EEPROM[4095], if not zero, FAKE_SERVO mode
- the state is shown in a line printed at startup and when changed
Does EEPROM[ FAKE_SERVO ] cause an EEPROM read to occur or does it use a cached value? I had some issues on the teensy where EEPROM activity would cause me problems with encoders.
I’m afraid it’s a read(). It only happens at first startup and when the command is sent, though.
FWIW, I’ve got a version that uses B99 instead of the $RST=F if that would be preferable. Should B99 toggle the state, or should it require an additional parameter - ‘B99 1’ for on, ‘B99 ~anything-else~’ for off?
It’s called continuously during a move isn’t it?
As for b command… I prefer a 1 to enable and anything else to disable.