Oops, I “tidied-away” the global variable when cleaning up. You’re right, the EEPROM location should only be touched when it changes, Axis shouldn’t need to touch the EEPROM.
I’ll put the global back in, and change over to the ‘B99 1’ approach.
Here’s the B99 version, using a global so Axis::computePID() checks the global variable FAKE_SERVO_STATE instead of reading EEPROM.
I’ve changed the logic so that ‘B99 ON’ enters FAKE_SERVO mode, ‘B99 anything-else’ exits back to normal motor drive.
Playing around I find that after running a moderately complex cut file in FAKE_SERVO mode with the chains off, the LRZ encoder values had only changed by 0.01mm after the run. The motors clatter, but don’t seem to have moved.
1 Like
What’s the LRZ encoder values? Sorry, just not familiar with LRZ term.
But, it seems in fake_servo mode, after the first Axis::computePID is calculated, the encoders are set to where they need to be at the end of the PID loop, thereby eliminating (or maybe minimizing because the motors clatter) the amount of PWM writes.
What would happen if in Motor:write you add a test for FAKE_SERVO_STATE? Would that even eliminate the chatter?
What if
Sorry, I meant Left, Right and Z encoders.
It might, but unplugging the motor power has less effect on the code base for the same result. I was just interested to see that, at least with no load on the sprockets, the clatter didn’t result in movement.
Google didn’t come up with that when I searched LRZ… but got it.
Understood about the unplugging. I do most of my development in the house and remote control my sled (no router is running) and being able to switch from fake_servo to not_fake_servo remotely would be handy.
1 Like
Added a check in MOTOR::write() to leave motors untouched during FAKE_SERVO. Tested by changing into FS mode during a cut and worked as expected.
1 Like
It’s been less than a week, and a user has gotten into “FAKE_SERVO” mode without realizing it.
I though that requiring a meta key to turn the function on, and printing the state would be enough to avoid inadvertent entry and indicate the change, but I may be wrong.
One option would be to put up a message box on entering the mode, with a note about how to get back out. That’s complicated by the fact that the firmware controls the text of the message but cannot know the key used to trigger the state. Too, having that message box appear isn’t needed for the intended user of “FAKE_SERVO” mode, only for explorers.
Another option would be to add a switch to the GC settings to enable the FS option. That would further protect against inadvertent activation through GC.
Other options? Is a ‘fix’ necessary?
How did the user get into that mode? I had to manually send a command and it seems unlikely that he did the same command. To do so in ground control you’d have to create a macro with that in it.
A terminal program could do it, though ‘cmd’-f or ‘ctrl’-f aren’t common keystrokes to send.
I’m missing something… how does ‘cmd’-f or ‘ctrl’-f send “B99 ON”?
GC PR#801 ’ add Run/Pause/Stop/FAKE_SERVO hotkeys’
- Assign a character to disable FAKE_SERVO mode, press that key along with ‘ctrl’ or ‘alt’ or ‘cmd’ to enable FAKE_SERVO. Defaulted to ‘f’ for off.
Oh… didn’t realize that was there. I think if having the ability to use a meta key to turn fake_servo off and on is desired, then I think having a switch to enable it would be a good solution to the problem.
I can add a switch to GC pretty easily, and default it to ‘inactive’. Will that interfere with your usage?
No, I use WC so it won’t affect me. WC doesn’t have hotkey support (not even sure it would be possible in a browser).