{"action":"created","issue":{"url":"https://api.github.com/repos/KevinOConnor/klipper/issues/1052","repository_url":"https://api.github.com/repos/KevinOConnor/klipper","labels_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/1052/labels{/name}","comments_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/1052/comments","events_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/1052/events","html_url":"https://github.com/KevinOConnor/klipper/issues/1052","id":394716851,"node_id":"MDU6SXNzdWUzOTQ3MTY4NTE=","number":1052,"title":"filament selection: Multi toolhead machine? or extending existing beyond XYZE?","user":{"login":"trevjonez","id":5386503,"node_id":"MDQ6VXNlcjUzODY1MDM=","avatar_url":"https://avatars2.githubusercontent.com/u/5386503?v=4","gravatar_id":"","url":"https://api.github.com/users/trevjonez","html_url":"https://github.com/trevjonez","followers_url":"https://api.github.com/users/trevjonez/followers","following_url":"https://api.github.com/users/trevjonez/following{/other_user}","gists_url":"https://api.github.com/users/trevjonez/gists{/gist_id}","starred_url":"https://api.github.com/users/trevjonez/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/trevjonez/subscriptions","organizations_url":"https://api.github.com/users/trevjonez/orgs","repos_url":"https://api.github.com/users/trevjonez/repos","events_url":"https://api.github.com/users/trevjonez/events{/privacy}","received_events_url":"https://api.github.com/users/trevjonez/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-12-28T20:49:37Z","updated_at":"2019-01-02T18:09:51Z","closed_at":null,"author_association":"NONE","body":"So now that I can at least get force move to make the mmu2 perform basic moves I want to start laying out more robust ways of control than depending on diagnostic options such as force_move.py.\r\n\r\nSo far all current approaches have failed at even getting basic homing behaviors to work due to the hard constraint of homing.\r\n\r\nany thoughts on how to best keep code reuse high and add the ability to extend the axis set beyond the typical XYZE?\r\n\r\ncurrent attempt has a config that looks like this:\r\n```\r\n[...]\r\n[printer]\r\nkinematics: selector\r\nmax_velocity: 200\r\nmax_accel: 1250\r\nmax_z_velocity: 12\r\nmax_z_accel: 200\r\n\r\n[kinematics]\r\ntoolhead: cartesian\r\nfilament: ips\r\n```\r\n\r\nselector kinematics being a composite root for the kinematics that then loads up and delegates to the toolhead and filament objects.\r\n\r\nI am sure I could keep blindly hacking but I would rather see if anyone else has gone into this sort of thought flow first?\r\n\r\nas for the actual components and naming scheme. you can pretty easily see it by skimming through the [assembly guide here. ](https://manual.prusa3d.com/Guide/2.+Pulley+body+assembly/755?lang=en)\r\n\r\nbasically we have the idler drum/tumbler that would home and have a preset list of positions at specific angles from home. then similarly the selector axis would have a preset list of positions at specific distances from home. and finally a pulley axis would behave as an extension of an extruder axi. if the user were to take time to calibrate the pulley step distances to match that of a correctly calibrated extruder it could in effect be used in tandem to drive and retract filament during filament changes.\r\n\r\nthen to make things slightly more interesting the selector axis might be constrained by filament making homing impossible at which point a user should be able to inform the host which slot is currently selected thus making the act of finding home unnecessary as the location is known."},"comment":{"url":"https://api.github.com/repos/KevinOConnor/klipper/issues/comments/450938053","html_url":"https://github.com/KevinOConnor/klipper/issues/1052#issuecomment-450938053","issue_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/1052","id":450938053,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MDkzODA1Mw==","user":{"login":"trevjonez","id":5386503,"node_id":"MDQ6VXNlcjUzODY1MDM=","avatar_url":"https://avatars2.githubusercontent.com/u/5386503?v=4","gravatar_id":"","url":"https://api.github.com/users/trevjonez","html_url":"https://github.com/trevjonez","followers_url":"https://api.github.com/users/trevjonez/followers","following_url":"https://api.github.com/users/trevjonez/following{/other_user}","gists_url":"https://api.github.com/users/trevjonez/gists{/gist_id}","starred_url":"https://api.github.com/users/trevjonez/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/trevjonez/subscriptions","organizations_url":"https://api.github.com/users/trevjonez/orgs","repos_url":"https://api.github.com/users/trevjonez/repos","events_url":"https://api.github.com/users/trevjonez/events{/privacy}","received_events_url":"https://api.github.com/users/trevjonez/received_events","type":"User","site_admin":false},"created_at":"2019-01-02T18:09:51Z","updated_at":"2019-01-02T18:09:51Z","author_association":"NONE","body":"yea I think that would be the ideal solution. my current deal was just me trying to short circuit getting into the existing homing flow. I think the [filament_selector] config is probably the best route to take. I just wonder what the best way to attach it to the toolhead flow is.\r\n\r\nI think my next best bet will be to literally draw out the bigger code flow on paper so I can better understand the relationships.\r\n\r\nThen as always I want to make sure to keep the filament_selector extensible so that it can be extended for things like the mmu1 (many extruders feeding a many to one ptfe reducer.) or the s3l3ctor which is sort of a mix of mmu1 and mmu2 where you have two steppers for idler and pulley feeding a similar many to one reducer.\r\n\r\n"}}
{"actor":{"display_login":"trevjonez"}}