{"action":"created","issue":{"url":"https://api.github.com/repos/MarlinFirmware/MarlinDev/issues/285","labels_url":"https://api.github.com/repos/MarlinFirmware/MarlinDev/issues/285/labels{/name}","comments_url":"https://api.github.com/repos/MarlinFirmware/MarlinDev/issues/285/comments","events_url":"https://api.github.com/repos/MarlinFirmware/MarlinDev/issues/285/events","html_url":"https://github.com/MarlinFirmware/MarlinDev/issues/285","id":118279426,"number":285,"title":"Hardware Endstops","user":{"login":"AnHardt","id":211931,"avatar_url":"https://avatars.githubusercontent.com/u/211931?v=3","gravatar_id":"","url":"https://api.github.com/users/AnHardt","html_url":"https://github.com/AnHardt","followers_url":"https://api.github.com/users/AnHardt/followers","following_url":"https://api.github.com/users/AnHardt/following{/other_user}","gists_url":"https://api.github.com/users/AnHardt/gists{/gist_id}","starred_url":"https://api.github.com/users/AnHardt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AnHardt/subscriptions","organizations_url":"https://api.github.com/users/AnHardt/orgs","repos_url":"https://api.github.com/users/AnHardt/repos","events_url":"https://api.github.com/users/AnHardt/events{/privacy}","received_events_url":"https://api.github.com/users/AnHardt/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":78,"created_at":"2015-11-22T18:23:04Z","updated_at":"2015-12-01T16:49:07Z","closed_at":null,"body":"Hardware Endstops\r\n\r\nA small collection of problems with hardware endstops. I'm not sure i'v got all of them.\r\nSorry. I was to lazy to search for all the original issues. Some of the below questions are constructed.\r\n\r\n\r\n* 1 Question: I have a probe that is always triggered when not deployed (like a allenkey) and a z-max endstop. __Before__ homing i can't go in -z direction. What to do?\r\nWorkaround: Home the machine.\r\n\r\n* 2 Question: I have a probe that is always triggered when not deployed (like a allenkey) and a z-max endstop. __After__ homing i can't go in -z direction. What to do?\r\nWorkaround: Set `#define ENDSTOPS_ONLY_FOR_HOMING`\r\n\r\n* 3 Question: I have a probe that is always triggered when not deployed (like a allenkey) and a z-min endstop. I can't go in -z direction and I can't home. What to do?\r\nWorkaround: Don't use this configuration.\r\n\r\nReason: The z-min probe acts as a z-min endstop - always when the endstops are checked.\r\nSolution: Add a new variable `bool z_probe_is_ready = false`. Don't test the z-min-probe-switch when false. Set and reset the variable during deploing/undeploing the probe. Make all this configurable with `//#define Z_MIN_PROBE_IS_TRIGGERED_WHEN_INACTIVE`. Connect your probe to a probe-pin, not the z-min-endstop-pin.\r\n\r\n* 4 Question: I set hardware endstops to on with M120. After G28, G29 or any other g-code using the probe this is forgotten.\r\nWorkaround: Use M120 after using the probe.\r\nReason: The endstop-state is not remembered. After using the probe the state is set depending on `ENDSTOPS_ONLY_FOR_HOMING` only.\r\nSolution: Remember the previous state when switching to \"on\" for a wanted endstop move, like it is done for the feedrate in `setup_for_endstop_move()`. Restore the previous state in `clean_up_after_endstop_move()`. Disable M120 before homing and give a warning - that's dangerous.\r\n\r\n* 5 Question: On my delta the coordinate system is messed up when the probe triggers somewhere between starting G29 and the first probe.\r\nWorkaround: Set up your machine so that the probe is not triggered before.\r\nReason: When on a delta a endstop / probe is triggered unexpected no correction can be made.\r\nSolution: Make software endstops work and narrow down the time the hardware endstops are active to the absolute minimum (`run_z_probe()`, `homeaxis()`). The right reaction on an unexpected hardware endstop hit is to stop the current and all further moves.\r\n\r\n* 6 Question: On my delta machine the coordinate system is messed up randomly.\r\nWorkaround: Set `ENDSTOPS_ONLY_FOR_HOMING`. \r\nReason: Noise on the endstop/probe inputs.\r\nSolution: Fix the endstops, their wiring, ... . Fix software endstops. The right reaction would be to stop the print, instead of making random looking moves.\r\n\r\n* 7 Question: When i print the layers shift in some direction. Somewhen later a hardware endstop is hit. Thereafter the layers are shifted a lot in an other direction. The part is a mess but print continues.\r\nWorkaround: You are loosing steps in one direction. If you see the layer shifting, stop the print and try to work against loosing steps.\r\nSolution: If a hardware endstop was hit after the machine was homed, something catastrophic has happened before. The software endstops should have prevented that the hardware endstops could have been hit. Even without software endstops the next move will never end where it is expected to. Stop the machine when a hardware endstop hit was detected after homing.\r\n\r\n* 8 Question: I homed my machine, send a `G1 X10`, `G1 X0`. I get a message that the endstop was triggered.\r\nWorkaround: Set `#define ENDSTOPS_ONLY_FOR_HOMING`\r\nReason: The x-min-position is set while the switch is triggered. Returning to there will trigger the switch again.\r\nSolution: Back up from the switch before the min-position is set. For example by `X_HOME_BUMP_MM`.\r\n\r\n* 9 Question: When i move around i can hit my hardware endstops and get messages. What to do?\r\nAnswer: Home your machine before moving around.\r\nQuestion: If that does not help?\r\nAnswer: Activate software endstops.\r\nQuestion: Even that has not helped. The next move after a endstop hit is strange.\r\nAnswer: You have a delta machine. Software endstops are more or less unimplemented there.\r\nWorkaround: Don't move to a impossible place.\r\nSolution: Implement proper software endstops for deltas.\r\n\r\n* 10 Question: What is the action to do if a hardware-endstop-hit is detected before homing?\r\nWorkaround: Homing should always be the first move.\r\nSolution: I don't know. The minimum is to stop the actual move. I guess the strongest is to clean the planner buffer, to prevent further already buffered moves from hitting the other side, where potentially no endstop is.\r\n\r\n* 11 Question: I can't move an axis in any direction. What to do?\r\nWorkaround: Test your endstops with M119. Maybe both endstops of that axis are triggered at the same time. Configure your endstos correct.\r\nSolution: Send a warning during boot/selftest. Triggered endstops at both ends, at the same time, indicate an error.\r\n\r\n* 12 Question: I can't move an axis towards an endstop.\r\nWorkaround: Test your endstop and configure it correct.\r\nSolution: During boot/selftest, if an endstop is triggered but not both, back up slowly `?_HOME_BUMP_MM`. If the endstop then is not free, throw an error.\r\n\r\n* 13 Question: When a hardware endstop is triggered and the hardware endstops are tested i can move away from them. The move is not stopped. I expected they'd stick on them.\r\nAnswer: Thats a feature, not a bug. The endstops are not tested when the move is away from them.\r\nQuestion: But isn't testing the direction slower than the actual test of the endstop?\r\nAnswer: Maybe we should test the endstop first and make the decision what to do with that information later.\r\nQuestion: But wouldn't sticking be a simple method to stop any pending moves until we actively free the endstop?\r\nSolution: To be discussed."},"comment":{"url":"https://api.github.com/repos/MarlinFirmware/MarlinDev/issues/comments/161028155","html_url":"https://github.com/MarlinFirmware/MarlinDev/issues/285#issuecomment-161028155","issue_url":"https://api.github.com/repos/MarlinFirmware/MarlinDev/issues/285","id":161028155,"user":{"login":"Roxy-3DPrintBoard","id":8404322,"avatar_url":"https://avatars.githubusercontent.com/u/8404322?v=3","gravatar_id":"","url":"https://api.github.com/users/Roxy-3DPrintBoard","html_url":"https://github.com/Roxy-3DPrintBoard","followers_url":"https://api.github.com/users/Roxy-3DPrintBoard/followers","following_url":"https://api.github.com/users/Roxy-3DPrintBoard/following{/other_user}","gists_url":"https://api.github.com/users/Roxy-3DPrintBoard/gists{/gist_id}","starred_url":"https://api.github.com/users/Roxy-3DPrintBoard/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Roxy-3DPrintBoard/subscriptions","organizations_url":"https://api.github.com/users/Roxy-3DPrintBoard/orgs","repos_url":"https://api.github.com/users/Roxy-3DPrintBoard/repos","events_url":"https://api.github.com/users/Roxy-3DPrintBoard/events{/privacy}","received_events_url":"https://api.github.com/users/Roxy-3DPrintBoard/received_events","type":"User","site_admin":false},"created_at":"2015-12-01T16:49:07Z","updated_at":"2015-12-01T16:49:07Z","body":"What if the Z_PROBE_END_SCRIPT was moved to the end of the stow() function?   And after that, we always set z_probe_is_active to false?    Even the 'E' parameter is handled in that case????   \r\n\r\nAt that point, the use of the Z_PROBE_END_SCRIPT is symmetric with every GCode (or MCode) using it.    \r\n\r\nOr am I missing something?\r\n"}}