{"action":"created","issue":{"url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/11098","repository_url":"https://api.github.com/repos/MarlinFirmware/Marlin","labels_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/11098/labels{/name}","comments_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/11098/comments","events_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/11098/events","html_url":"https://github.com/MarlinFirmware/Marlin/pull/11098","id":335138773,"node_id":"MDExOlB1bGxSZXF1ZXN0MTk2OTI1MzI5","number":11098,"title":"[2.0.x] Misc fixes to endstops and Planner and Stepper","user":{"login":"ejtagle","id":831601,"node_id":"MDQ6VXNlcjgzMTYwMQ==","avatar_url":"https://avatars2.githubusercontent.com/u/831601?v=4","gravatar_id":"","url":"https://api.github.com/users/ejtagle","html_url":"https://github.com/ejtagle","followers_url":"https://api.github.com/users/ejtagle/followers","following_url":"https://api.github.com/users/ejtagle/following{/other_user}","gists_url":"https://api.github.com/users/ejtagle/gists{/gist_id}","starred_url":"https://api.github.com/users/ejtagle/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ejtagle/subscriptions","organizations_url":"https://api.github.com/users/ejtagle/orgs","repos_url":"https://api.github.com/users/ejtagle/repos","events_url":"https://api.github.com/users/ejtagle/events{/privacy}","received_events_url":"https://api.github.com/users/ejtagle/received_events","type":"User","site_admin":false},"labels":[{"id":196934261,"node_id":"MDU6TGFiZWwxOTY5MzQyNjE=","url":"https://api.github.com/repos/MarlinFirmware/Marlin/labels/PR:%20Bug%20Fix","name":"PR: Bug Fix","color":"bfe5bf","default":false},{"id":92052497,"node_id":"MDU6TGFiZWw5MjA1MjQ5Nw==","url":"https://api.github.com/repos/MarlinFirmware/Marlin/labels/PR:%20Improvement","name":"PR: Improvement","color":"c2e0c6","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":32,"created_at":"2018-06-23T23:39:41Z","updated_at":"2018-06-26T22:20:05Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/MarlinFirmware/Marlin/pulls/11098","html_url":"https://github.com/MarlinFirmware/Marlin/pull/11098","diff_url":"https://github.com/MarlinFirmware/Marlin/pull/11098.diff","patch_url":"https://github.com/MarlinFirmware/Marlin/pull/11098.patch"},"body":"-When ENDSTOP_FILTER is enabled, the endstops are always polled. But, there was a problem there, as when the motors do not move, the endstop switches reading was skipped. So, i removed that condition, but just for the endstop line read. This seems to solve #11056 and several homing issues.\r\n\r\n-I initially implemented the ability to alter a running block , but found a much more bigger problem there: \r\n1) SBI and CBI macros are not atomic. so we CAN´T use CBI and SBI in block_t:flags from the ISR and main thread at the same time !!! ... This is a VERY BIG mistake, as the main thread could be removing the BUSY bit from the block, while trying to set any other bit, if it happens the Stepper ISR executes in the middle of the read-modify-write operation! - So, as this is not acceptable at all, the BUSY bit was removed and a different approach is used.\r\n2) There were several unhandled race conditions between the Stepper ISR and the Planner. Specifically, the most dangerous one is when, at the planner, we set the RECALCULATE flag, but at that point the block could already be BUSY just because the Stepper ISR took it from the movement queue - Results are that we end up partially updating the entry and exit speeds of the block, but not updating the block parameters that are used by the stepper ISR. The net result is that the planner considers the block joined with the next, when it wasn´t, and that causes the next block to start at maximum speed - Leading to lost steps. That is what I suspect is happening with Pronterface and the Jog problem\r\n\r\nSo the solution was to detect the busy block by comparing `Stepper::current_block` with the one we want, to, after setting RECALCULATE for a block (that should prevent the ISR to start executing the block if it hasn´t already) check if the block is busy, and if it is, do not touch it at all.\r\n\r\n-As @p3p found, correct the LPC1768 Serial priority. This seems to partially fix issues in #11047 \r\n\r\n-Add a configuration to let user set the time between signal direction change to motor drivers and the next step pulse\r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/comments/400481508","html_url":"https://github.com/MarlinFirmware/Marlin/pull/11098#issuecomment-400481508","issue_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/11098","id":400481508,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMDQ4MTUwOA==","user":{"login":"p3p","id":24342,"node_id":"MDQ6VXNlcjI0MzQy","avatar_url":"https://avatars1.githubusercontent.com/u/24342?v=4","gravatar_id":"","url":"https://api.github.com/users/p3p","html_url":"https://github.com/p3p","followers_url":"https://api.github.com/users/p3p/followers","following_url":"https://api.github.com/users/p3p/following{/other_user}","gists_url":"https://api.github.com/users/p3p/gists{/gist_id}","starred_url":"https://api.github.com/users/p3p/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/p3p/subscriptions","organizations_url":"https://api.github.com/users/p3p/orgs","repos_url":"https://api.github.com/users/p3p/repos","events_url":"https://api.github.com/users/p3p/events{/privacy}","received_events_url":"https://api.github.com/users/p3p/received_events","type":"User","site_admin":false},"created_at":"2018-06-26T22:20:05Z","updated_at":"2018-06-26T22:20:05Z","author_association":"MEMBER","body":"@ejtagle sounds like the research into the issue is going well, I'm curious about something kind of related, on the graph that follows you can see some noise caused by the interplay between step frequencies on the constant velocity areas (mostly expected), but the acceleration ramps seem to be badly effected by this, sometimes doubling the set maximum (2000) for short periods, is this unavoidable? \r\n\r\nData was collected with ADAPTIVE_STEP_SMOOTHING, but no other new motion features, purple lines indicate Marlin moving to the next block. \r\n\r\n![high-acceleration2](https://user-images.githubusercontent.com/24342/41942454-6c56f326-7997-11e8-8a8e-5dc325c2214a.png)\r\n"}}
{"actor":{"display_login":"p3p"}}