{"action":"created","issue":{"url":"https://api.github.com/repos/MaikStohn/UP3D/issues/18","repository_url":"https://api.github.com/repos/MaikStohn/UP3D","labels_url":"https://api.github.com/repos/MaikStohn/UP3D/issues/18/labels{/name}","comments_url":"https://api.github.com/repos/MaikStohn/UP3D/issues/18/comments","events_url":"https://api.github.com/repos/MaikStohn/UP3D/issues/18/events","html_url":"https://github.com/MaikStohn/UP3D/issues/18","id":152012638,"number":18,"title":"Hardware or Transcoder X/Y lean issue on cylinders","user":{"login":"adrianbear","id":6194143,"avatar_url":"https://avatars.githubusercontent.com/u/6194143?v=3","gravatar_id":"","url":"https://api.github.com/users/adrianbear","html_url":"https://github.com/adrianbear","followers_url":"https://api.github.com/users/adrianbear/followers","following_url":"https://api.github.com/users/adrianbear/following{/other_user}","gists_url":"https://api.github.com/users/adrianbear/gists{/gist_id}","starred_url":"https://api.github.com/users/adrianbear/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adrianbear/subscriptions","organizations_url":"https://api.github.com/users/adrianbear/orgs","repos_url":"https://api.github.com/users/adrianbear/repos","events_url":"https://api.github.com/users/adrianbear/events{/privacy}","received_events_url":"https://api.github.com/users/adrianbear/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/MaikStohn/UP3D/labels/bug","name":"bug","color":"fc2929"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":20,"created_at":"2016-04-30T06:02:46Z","updated_at":"2016-05-04T20:37:05Z","closed_at":null,"body":"Hi Maik,\r\nI think there is a bug in versions 4.1 and 4.2 of the transcoder when printing cylinders (or lots of angles)\r\n\r\nI've been calibrating my printer with some custom thin wall models (just squares) I made up and everything has appeared to be fine.\r\nI then upgraded from version 4.1 to 4.2. Assuming nothing related to transcoding had changed that would effect my calibrations, I started printing an S-plug. It printed the disk and disk with S hole perfectly, but the S on the top of the disk printed with a lean. See here for images =>\r\n![1_print with 4 1](https://cloud.githubusercontent.com/assets/6194143/14934146/c4d5e1ba-0ee6-11e6-892c-e41a09fd4f8c.jpg)\r\n\r\nThinking this might be a bug in 4.2, I downgraded to 4.1 and found the issue was still there and appeared across the entire print. This made me think maybe something was wrong with my hardware. So I printed it from the UP software and it came out perfectly, printed again from transcoder 4.2 and it leans again. See here => \r\n![2_splugs printed with various transcoder versions and upsoftware](https://cloud.githubusercontent.com/assets/6194143/14934168/1ef3bf6e-0ee7-11e6-9eda-12f968d32d2f.jpg)\r\n\r\nI then printed my boxes and squares again with version 4.2 and they came out fine, so I printed the s-plug again but nope still has a lean. see here => \r\n![3_splugs and boxes printed with 4 2](https://cloud.githubusercontent.com/assets/6194143/14934173/5aa7fe1c-0ee7-11e6-8056-639c0514c56b.jpg)\r\n\r\nSo at this point I \"think\" there is no issue with the hardware but with printing circles from the transcoder, so I crafted a basic cylinder to test with. Results can be seen here =>\r\n![4_cylinders printed with various versions and up software](https://cloud.githubusercontent.com/assets/6194143/14934184/8b5ce57c-0ee7-11e6-9d02-61e557eadade.jpg)\r\n\r\nA Cylinder printed with version 4.2 has a lean \r\nA Cylinder printed with UP software is perfectly upright\r\nA Cylinder printed with 3.0 is perfectly upright\r\nThe same g-code used again with version 4.2 again has a lean.\r\n\r\nThis zip contains my gcode, umc code and the STL I used.\r\n[Cylinder UMC GCODE and STL.zip](https://github.com/MaikStohn/UP3D/files/243474/Cylinder.UMC.GCODE.and.STL.zip)\r\n\r\nI am happy to be corrected and have it proven that my printer has a slip of some sort, but this looks like a bug in the latest transcoder versions to me (at least 4.1 and 4.2).\r\nThe other thought that has crossed my mind is maybe there is some \"hack checking\" going on from inside the UP firmware on the printer itself. I sure hope this is not the case....\r\n\r\nThanks\r\nAdrian"},"comment":{"url":"https://api.github.com/repos/MaikStohn/UP3D/issues/comments/216995111","html_url":"https://github.com/MaikStohn/UP3D/issues/18#issuecomment-216995111","issue_url":"https://api.github.com/repos/MaikStohn/UP3D/issues/18","id":216995111,"user":{"login":"kscheff","id":8903302,"avatar_url":"https://avatars.githubusercontent.com/u/8903302?v=3","gravatar_id":"","url":"https://api.github.com/users/kscheff","html_url":"https://github.com/kscheff","followers_url":"https://api.github.com/users/kscheff/followers","following_url":"https://api.github.com/users/kscheff/following{/other_user}","gists_url":"https://api.github.com/users/kscheff/gists{/gist_id}","starred_url":"https://api.github.com/users/kscheff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kscheff/subscriptions","organizations_url":"https://api.github.com/users/kscheff/orgs","repos_url":"https://api.github.com/users/kscheff/repos","events_url":"https://api.github.com/users/kscheff/events{/privacy}","received_events_url":"https://api.github.com/users/kscheff/received_events","type":"User","site_admin":false},"created_at":"2016-05-04T20:37:04Z","updated_at":"2016-05-04T20:37:04Z","body":"@MaikStohn\n\nYes, that is an interesting subject here.\n\nSo far I cannot make much sense from the data I get with my simple test cube 10x10x10 sliced by UP in fine/normal/fast mode.\nAs noted I have captured the data and feed through convg for further analysis.\n\nFirst I like to understand the fundamentals on the UP UMC code side:\n\nCMD 4 is the main command for moving and extrusion right?\n\nMy first focus would be on the question why CMD 4 has a repeat factor p1 so prominently placed?\nThe p1 multiplier only results in a linear move in the same direction with the same acceleration.\nI can only guess what the reason for this factor is:\n\nThe motor drivers are usually controlled by a timer interrupt and use a discrete frequency, right?\nIt might be that the main motor driver control interrupt does not handle any acceleration, it might be driven\nby a fixed but controllable frequency. By using the p1 factor one can assume that this mechanism is used\nto produce discrete acceleration steps for the motor driver. The machine heads weight and thus the dynamic of the\nsystem is then the result of these discrete stepped acceleration approach….\n\nI have not much insight in Marlin or other firmware, how they handle acceleration, but from looking into grbl they only care\nabout the max acceleration handled by the firmware/hardware. How this is translated into real stepper motor controller commands\nis a layer below grbl.\n\nSo one way of handling this would be to use each segment from the motion planner and break it up into a number of segments to smooth\nacceleration (p1). How many number of segments would be required depends on the maximum tolerable acceleration steps of the UP mini.\n\nCan we see that UP uses P1 > 1 in its output file? And if so, what is the max acceleration or step size here in the different modes.\n I might check this later on, this would need to be probed, dumped inside convg.\n\n… so that was going through my head driving on the autobahn the last two hours….\n\nBest regards\nKai\n\n\n> Am 04.05.2016 um 19:57 schrieb Maik Stohn <notifications@github.com>:\n> \n> I'm thinking a lot about this acceleration thing over the last days,\n> \n> maybe @kscheff <https://github.com/kscheff> or somebody else could assist me with this.\n> \n> What I found out about the internal UP CPU handling acceleration / moves is the following:\n> \n> CMD 4 (extrusion move): p1,p2,p3,p4,p5,p6,p7,p8 (16 bit values)\n> p1 = how often this (block) is executed\n> p2 = the frequency/time for every execution\n> X:p3,Y:p4,A:p5 = steps512 per execution (512 is to have a fraction)\n> X:p6,Y:p7,A:p8 = steps512 added to (p3,p4,p5) per execution (512 is to have a fraction)\n> \n> Example: \n> p1=5 ==> do 5 times\n> p2=10000 ==> 10000 (time for block relative to 50MHz CPU frequency)\n> p3,p4,p5 all 0 --> no starting speed for (X,Y,A)\n> p6=1,p7=2,p8=0 --> every block execution speed will be increased by this value\n> ==>\n> execute 0:\n> speedX=0,speedY=0,speedA=0\n> +1,+2,+0\n> execute 1:\n> speedX=1,speedY=2,speedA=0\n> +1,+2,+0\n> execute 2:\n> speedX=2,speedY=4,speedA=0\n> +1,+2,+0\n> execute 3:\n> speedX=3,speedY=6,speedA=0\n> +1,+2,+0\n> execute 4:\n> speedX=4,speedY=8,speedA=0\n> +1,+2,+0 (??? not sure if this happens)\n> \n> p3,p4,p5,p6,p7,p8 can be positive and negative (16 bit integer)\n> \n> 512,1024,... is 1 step\n> \n> fractional parts are calculated during this block, but discarded after block finished\n> \n> they use \"floor\" to always round down (which is horribly wrong for negative numbers...)\n> \n> Maik\n> \n> —\n> You are receiving this because you were mentioned.\n> Reply to this email directly or view it on GitHub <https://github.com/MaikStohn/UP3D/issues/18#issuecomment-216948643>\n\n"}}