{"action":"created","issue":{"url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/9205","repository_url":"https://api.github.com/repos/MarlinFirmware/Marlin","labels_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/9205/labels{/name}","comments_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/9205/comments","events_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/9205/events","html_url":"https://github.com/MarlinFirmware/Marlin/issues/9205","id":288974208,"number":9205,"title":"final_rate is often not reached","user":{"login":"Sebastianv650","id":10776877,"avatar_url":"https://avatars3.githubusercontent.com/u/10776877?v=4","gravatar_id":"","url":"https://api.github.com/users/Sebastianv650","html_url":"https://github.com/Sebastianv650","followers_url":"https://api.github.com/users/Sebastianv650/followers","following_url":"https://api.github.com/users/Sebastianv650/following{/other_user}","gists_url":"https://api.github.com/users/Sebastianv650/gists{/gist_id}","starred_url":"https://api.github.com/users/Sebastianv650/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Sebastianv650/subscriptions","organizations_url":"https://api.github.com/users/Sebastianv650/orgs","repos_url":"https://api.github.com/users/Sebastianv650/repos","events_url":"https://api.github.com/users/Sebastianv650/events{/privacy}","received_events_url":"https://api.github.com/users/Sebastianv650/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2018-01-16T16:37:50Z","updated_at":"2018-02-19T16:09:19Z","closed_at":null,"author_association":"NONE","body":"This is a follow-up of #9174 where I fixed a part but not all of the issue. At the moment (and I guess since early grbl days), Marlin isn't reaching the final step rate at end of block in all cases. There are three things to mention:\r\n\r\n- A block with cruising state will not always reach final_rate. If that's the case or not depends on the nominal rate and the acceleration rate values. Some work, some don't.\r\nPossible fixes:\r\n  - Add some extra steps to the calculated amount of deceleration steps, amount would have to be checked by experiments.\r\n  - Find the point in the calculation where we need more precision or a bug is present and fix it.\r\n- A block with not cruising state will most likely never reach final_rate. This is due to the fact that only number of CEIL(acceleration_steps) is calculated, so deceleration will most likely has not enough steps.\r\nPossible fixes:\r\n  - FLOOR() should do the trick, if the calculation of intersection_distance is valid and calculation in stepper.cpp are at good precision.\r\n- If a deceleration goes along more than one block, final_rate will most likely never be reached. This time the problem is that the planner calculates the maximum allowed junction speed to reach final_rate, but due to precision limits (assumption as mentioned in first point) the deceleration never reaches final_rate. As we can't increase the amount of deceleration_steps with some magic number in this case (there is already only deceleration), the only possible fixes are:\r\n  - Lower the maximum allowed junction speed by some magic factor.\r\n  - Again, fixing the precision or a possible existing bug in stepper.cpp rate / time calculations.\r\n\r\nKeep in mind that until this is fixed:\r\n- Also acceleration should be affected by this in theory.\r\n- Never assume that final_rate is reached at end of block when you code something.\r\n\r\nI will do tests where we the timer / step rate calculations differ from ideal values next."},"comment":{"url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/comments/366737313","html_url":"https://github.com/MarlinFirmware/Marlin/issues/9205#issuecomment-366737313","issue_url":"https://api.github.com/repos/MarlinFirmware/Marlin/issues/9205","id":366737313,"user":{"login":"Sebastianv650","id":10776877,"avatar_url":"https://avatars3.githubusercontent.com/u/10776877?v=4","gravatar_id":"","url":"https://api.github.com/users/Sebastianv650","html_url":"https://github.com/Sebastianv650","followers_url":"https://api.github.com/users/Sebastianv650/followers","following_url":"https://api.github.com/users/Sebastianv650/following{/other_user}","gists_url":"https://api.github.com/users/Sebastianv650/gists{/gist_id}","starred_url":"https://api.github.com/users/Sebastianv650/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Sebastianv650/subscriptions","organizations_url":"https://api.github.com/users/Sebastianv650/orgs","repos_url":"https://api.github.com/users/Sebastianv650/repos","events_url":"https://api.github.com/users/Sebastianv650/events{/privacy}","received_events_url":"https://api.github.com/users/Sebastianv650/received_events","type":"User","site_admin":false},"created_at":"2018-02-19T16:09:19Z","updated_at":"2018-02-19T16:09:19Z","author_association":"NONE","body":"I mean the following: When we have a new block which is added to the buffer, we calculate a trapezoid assuming it's final speed will be 0. Then we add another block. Due to it's length, we can now say the final speed of our 1st block is for example 10mm/s as we could decelerate to 0 during the last segment. So we calculate the trapezoid again. Let's add another block, until we reach a length (I think the propper term would be nominal length) where we have enough length inside the buffer so we can decelerate from nominal speed to 0. This is the last time we need to recalculate the trapezoid for 1st block added, and for all next blocks until their nominal length is reached.\r\n\r\nWhen I remember correctly, current versions of GRBL don't do this any more. They only do reverse and forward planning, but the trapezoid is calculated \"on the fly\" just before it gets executed. Saves a lot of \"unnecessary\" calculations, but the system has to be fast enough to calculate the trapezoid in time without creating a jerky movement."}}
{"actor":{"display_login":"Sebastianv650"}}