{"action":"created","issue":{"url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3/issues/165","repository_url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3","labels_url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3/issues/165/labels{/name}","comments_url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3/issues/165/comments","events_url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3/issues/165/events","html_url":"https://github.com/openhardwarecoza/LaserWeb3/issues/165","id":184359083,"number":165,"title":"Jerky motion during raster engraving","user":{"login":"DarklyLabs","id":14358950,"avatar_url":"https://avatars.githubusercontent.com/u/14358950?v=3","gravatar_id":"","url":"https://api.github.com/users/DarklyLabs","html_url":"https://github.com/DarklyLabs","followers_url":"https://api.github.com/users/DarklyLabs/followers","following_url":"https://api.github.com/users/DarklyLabs/following{/other_user}","gists_url":"https://api.github.com/users/DarklyLabs/gists{/gist_id}","starred_url":"https://api.github.com/users/DarklyLabs/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DarklyLabs/subscriptions","organizations_url":"https://api.github.com/users/DarklyLabs/orgs","repos_url":"https://api.github.com/users/DarklyLabs/repos","events_url":"https://api.github.com/users/DarklyLabs/events{/privacy}","received_events_url":"https://api.github.com/users/DarklyLabs/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":50,"created_at":"2016-10-20T22:44:20Z","updated_at":"2016-10-26T18:53:35Z","closed_at":null,"body":"Raster g-code generated through Laserweb3 results in jerky motion when run on the Smoothieboard.\r\n\r\nWe are testing this via USB and have tried streaming the same G-Code via LW3 and Pronterface with the same results on the smoothie. We have also used our PCB and an original Smoothie PCB with the same results.\r\n\r\nWe are currently running the latest smoothie master firmware and the latest LW3 master."},"comment":{"url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3/issues/comments/256443266","html_url":"https://github.com/openhardwarecoza/LaserWeb3/issues/165#issuecomment-256443266","issue_url":"https://api.github.com/repos/openhardwarecoza/LaserWeb3/issues/165","id":256443266,"user":{"login":"chamnit","id":948029,"avatar_url":"https://avatars.githubusercontent.com/u/948029?v=3","gravatar_id":"","url":"https://api.github.com/users/chamnit","html_url":"https://github.com/chamnit","followers_url":"https://api.github.com/users/chamnit/followers","following_url":"https://api.github.com/users/chamnit/following{/other_user}","gists_url":"https://api.github.com/users/chamnit/gists{/gist_id}","starred_url":"https://api.github.com/users/chamnit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chamnit/subscriptions","organizations_url":"https://api.github.com/users/chamnit/orgs","repos_url":"https://api.github.com/users/chamnit/repos","events_url":"https://api.github.com/users/chamnit/events{/privacy}","received_events_url":"https://api.github.com/users/chamnit/received_events","type":"User","site_admin":false},"created_at":"2016-10-26T18:53:35Z","updated_at":"2016-10-26T18:53:35Z","body":"@iceman1979 : To add upon preventing the spread of false information. You are incorrect on how Grbl streaming works. Grbl sends an 'ok' response **after** it has parsed and interpreted the g-code line, **not** executing a motion. If it's a motion command, it's placed into the planner queue, which can be anywhere from 14 to 18 total queued motions. If this wasn't true, then Grbl would stutter like crazy and be unusable. The basis of how Grbl works is the same on Smoothie and Marlin, as they are both direct cousins of Grbl.\r\n\r\n@openhardwarecoza : Thanks for the v1.1 report! I'm happy to hear that users are liking it. I also plan on adding constant power/rate to account for acceleration phases into corners and such. \r\n\r\nAs for having an`F` command on every line, Grbl can handle it fine, but it does create a lot of unnecessary serial comm. With laser cutting and anything that has short line segments and fast tool paths, you want to reduce the serial stream as much as possible. This reduces latency and improves the high-end performance of the machine. Meaning that Grbl will move smoothly through the fast tool paths and not stutter when its motion buffers are starved from the lack of throughput. \r\n\r\nI know that UGS, one of the highest performing Grbl senders, applies a filter to gets rid of spaces, capitalizes all letters, and removes comments automatically before sending to Grbl. This helps with removing unnecessary characters being sent to Grbl."}}
{"actor":{"display_login":"chamnit"}}