{"action":"created","issue":{"url":"https://api.github.com/repos/KevinOConnor/klipper/issues/799","repository_url":"https://api.github.com/repos/KevinOConnor/klipper","labels_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/799/labels{/name}","comments_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/799/comments","events_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/799/events","html_url":"https://github.com/KevinOConnor/klipper/issues/799","id":372039603,"node_id":"MDU6SXNzdWUzNzIwMzk2MDM=","number":799,"title":"klipper and machinekit","user":{"login":"mngr0","id":30530048,"node_id":"MDQ6VXNlcjMwNTMwMDQ4","avatar_url":"https://avatars2.githubusercontent.com/u/30530048?v=4","gravatar_id":"","url":"https://api.github.com/users/mngr0","html_url":"https://github.com/mngr0","followers_url":"https://api.github.com/users/mngr0/followers","following_url":"https://api.github.com/users/mngr0/following{/other_user}","gists_url":"https://api.github.com/users/mngr0/gists{/gist_id}","starred_url":"https://api.github.com/users/mngr0/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mngr0/subscriptions","organizations_url":"https://api.github.com/users/mngr0/orgs","repos_url":"https://api.github.com/users/mngr0/repos","events_url":"https://api.github.com/users/mngr0/events{/privacy}","received_events_url":"https://api.github.com/users/mngr0/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-10-19T17:02:02Z","updated_at":"2018-11-30T18:37:18Z","closed_at":"2018-10-31T15:16:53Z","author_association":"NONE","body":"<!-- Klipper do something undesirable? YOU MUST ATTACH THE KLIPPER LOG FILE.\r\nSee: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md -->\r\nHi,\r\nI am thinking about a little project, and I would like to hear the opinion of some experienced klipper user.\r\n\r\nI would like to \"port\" the software you have made for the MCUs for machinekit.\r\nMachinekit uses HAL modules, and it's possible to make one that receives the commanded position from the trajectory planner and send that (or the commanded velocity) to the MCU.\r\nThis will allow to use all the machinekit hal stack, with all its features, and without being forced in the hardware selection.\r\n\r\nVarious attempts in this direction have already been done (  [PiCNC](https://github.com/kinsamanka/PICnc-V2), [hal2arduino](https://openbuilds.com/projectresources/hal2arduino.124/updates)  ), but they are no longer mantained.\r\n\r\nWhat do you think about it? \r\n(If you have a forum or a more suitable place for this topic I will move there)\r\n\r\nI have read your protocol.md and mcu_commands.md and the protocol seems clear, but I had trouble in finding an implementation of it, particularly on the MCU side"},"comment":{"url":"https://api.github.com/repos/KevinOConnor/klipper/issues/comments/443297874","html_url":"https://github.com/KevinOConnor/klipper/issues/799#issuecomment-443297874","issue_url":"https://api.github.com/repos/KevinOConnor/klipper/issues/799","id":443297874,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MzI5Nzg3NA==","user":{"login":"KevinOConnor","id":3004890,"node_id":"MDQ6VXNlcjMwMDQ4OTA=","avatar_url":"https://avatars3.githubusercontent.com/u/3004890?v=4","gravatar_id":"","url":"https://api.github.com/users/KevinOConnor","html_url":"https://github.com/KevinOConnor","followers_url":"https://api.github.com/users/KevinOConnor/followers","following_url":"https://api.github.com/users/KevinOConnor/following{/other_user}","gists_url":"https://api.github.com/users/KevinOConnor/gists{/gist_id}","starred_url":"https://api.github.com/users/KevinOConnor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/KevinOConnor/subscriptions","organizations_url":"https://api.github.com/users/KevinOConnor/orgs","repos_url":"https://api.github.com/users/KevinOConnor/repos","events_url":"https://api.github.com/users/KevinOConnor/events{/privacy}","received_events_url":"https://api.github.com/users/KevinOConnor/received_events","type":"User","site_admin":false},"created_at":"2018-11-30T18:37:18Z","updated_at":"2018-11-30T18:37:18Z","author_association":"OWNER","body":"> But my concern is about things like encoders, how could klipper manage them?\r\nThe couple encoder+motor is very common and it might deserve a dedicated piece of code in the MCU firmware. But what for a different use of encoders?\r\n>\r\n> A \"similar\" problem is probing, moving an axis until something happen, like homing.\r\nI looked how klipper manages homing, correct me if I am wrong, it moves little by little until the switch is pressed.\r\n> \r\n> More in general, any queue-buster event that could interrupt or modify the event scheduled for the MCU.\r\n\r\nFor these types of \"queue buster\" situations, we generally add code to the micro-controller so that it can respond to the event with low latency.  An example of this is the homing/endstop code - during homing, the host sends the necessary homing movement to the micro-controller (using the regular kinematic movement system) and instructs the micro-controller endstop code to halt a set of steppers when the endstop switch triggers.  So, the endstop code in the micro-controller knows how to handle that particular \"queue busting\" event.  Another example is the micro-controller thermocouple code - it is configured to regularly query the thermocouple chips and it is configured what the valid temperature range is.  Should the temperature exceed the configured range then the thermocouple code knows how to shutdown the heaters even without host intervention.\r\n\r\nIn contrast, when external events don't require a fast response, we typically perform the logic in the host code.  An example of this is the PID temperature control loop.  In this situation, the mirco-controller is configured to take measurements every 300ms and forward them to the host.  The host uses that info to calculate updated heating parameters and schedules the corresponding heating pin changes to take effect just after the next measurement (that is ~300ms in the future).\r\n\r\nI suspect motor encoders would follow a similar mechanism - code in the micro-controller to respond to encoder feedback quickly along with code in the host to configure and monitor it.\r\n\r\n> Klipper does not use a real time kernel, and the protocol to send commands to the MCU includes the clock time of execution.\r\ndid you add the clock time because of the lack of real time kernel?\r\nIf Klipper started using a rt kernel (somehow), would be possible to simplify the serial protocol?\r\nIn particular would it be possible to send them without the time clock?\r\n\r\nThe scheduling of events with precise timing is a key feature of Klipper.  It was an initial design goal and it is working well.  That capability is key to Klipper's ability to utilize low cost micro-controllers, deploy multiple micro-controller as a single logical unit, obtain high performance, and have portable code across both micro-controllers and host hardware.\r\n\r\nUtilizing a real-time kernel helps to reduce latency in software running on general purpose computers, but it would not reduce the latency/jitter associated with transmission of commands to a micro-controller.  Thus a real-time kernel would not provide any particular benefit in the Klipper architecture.  (That is, a real-time kernel only really helps if everything - including the motion planner - runs as a real-time process on a single cpu.)\r\n\r\n-Kevin"}}
{"actor":{"display_login":"KevinOConnor"}}