Skip to content
This repository has been archived by the owner on Jun 6, 2022. It is now read-only.

Implement position confidence model to enforce homing #8

Open
mrandt opened this issue Jul 11, 2015 · 3 comments
Open

Implement position confidence model to enforce homing #8

mrandt opened this issue Jul 11, 2015 · 3 comments

Comments

@mrandt
Copy link

mrandt commented Jul 11, 2015

I suggest to introduce some sort of position confidence management - could be very basic for now.

The application could keep an internal flag that stores if the current position is "valid". Flag should be enabled after the machine is homed and disabled again whenever TinyG is reset, connection is lost or motor power is disabled.

If software is not confident about the actual position, it should not allow any movements and request the user to home the machine first.

This would greatly reduce the risk of "banging the machine into the wall".

For experts, we could still keep an option to override so they can still crash their machines ;-)

@thethereza
Copy link

dunno. the tinyg keeps track of position and reinfoms the application when it restarts. one way would be to query the position and trust it if it isn't zero. but what if you shut it down while at zero?

@mrandt
Copy link
Author

mrandt commented Jul 13, 2015

There are many situations, where TinyG "virtual" position differs from "physical" machine position:

  • just switched on, machine could be anywhere
  • TinyG reset or emergency stop, machine could be anywhere
  • Motors powered off during longer standby, machine could have been moved manually
  • missed steps (current settings, mechanical resistance...) - however I would not deal with those in software...

My suggestion is simple: We should have a variable "positionValid" or similar somewhere in software, that can be queried from all movement functions.

While this flag is false, no machine movement (besides homing operation) shall be allowed. No jogging with keys, no defined locations, etc.

On software startup, flag should be initialized to false.

If machine is homed, this variable is set to true and normal operation can start.

If motors are powered off (standby) or connection to TinyG is lost (reset, emergency stop), variable is set to false again.

As a courtesy, the error message of any movement that is not allowed could ask you if you want to home - like "LitePlacer software is not confident of physical machine position. Please home machine first. Do you want to home now?"

@mrandt
Copy link
Author

mrandt commented Jul 16, 2015

OK, in SVN Release 18 Reza went one step towards this - the "Home" button indicates whether the machine has been homed or not (red if not homed, green after homing).

However, the status is currently not reset. I think, home status should turn red if TinyG connection is lost, TinyG is reset (Hardware switch or unexpectedly hit limit switch) or motor power is cut (checkbox or standby).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants