{"action":"created","issue":{"url":"https://api.github.com/repos/machinekit/machinekit/issues/687","repository_url":"https://api.github.com/repos/machinekit/machinekit","labels_url":"https://api.github.com/repos/machinekit/machinekit/issues/687/labels{/name}","comments_url":"https://api.github.com/repos/machinekit/machinekit/issues/687/comments","events_url":"https://api.github.com/repos/machinekit/machinekit/issues/687/events","html_url":"https://github.com/machinekit/machinekit/issues/687","id":88631802,"number":687,"title":"external synchronisation of HAL threads not possible","user":{"login":"mhaberler","id":901479,"avatar_url":"https://avatars.githubusercontent.com/u/901479?v=3","gravatar_id":"","url":"https://api.github.com/users/mhaberler","html_url":"https://github.com/mhaberler","followers_url":"https://api.github.com/users/mhaberler/followers","following_url":"https://api.github.com/users/mhaberler/following{/other_user}","gists_url":"https://api.github.com/users/mhaberler/gists{/gist_id}","starred_url":"https://api.github.com/users/mhaberler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mhaberler/subscriptions","organizations_url":"https://api.github.com/users/mhaberler/orgs","repos_url":"https://api.github.com/users/mhaberler/repos","events_url":"https://api.github.com/users/mhaberler/events{/privacy}","received_events_url":"https://api.github.com/users/mhaberler/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/machinekit/machinekit/labels/problem","name":"problem","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":29,"created_at":"2015-06-16T06:18:41Z","updated_at":"2016-05-24T23:00:58Z","closed_at":null,"body":"this thread is about collecting clue on externally clocking HAL threads.\r\n\r\nThere is huge upside in having support for this, as it would allow hardware to sample positions in next-to-exact time and then trigger the servo thread to go about its job, which in essence takes out host thread jitter completely as far as position sampling noise goes.\r\n\r\nThe requirement for RT thread now changes from \"thread must commence execution at an exact point in time\" to \"thread must complete function chain within servo cycle\", which is a major relaxation.\r\n\r\nNote this is what the external phase locked loop scheme tries to achieve, but potentially better and easier (no PLL catch/locking issues): external hardware (Mesanet firmware, PRU..) could run a \"base thread\" and interrupt the host at a submultiple of the \"hardware base rate\". \r\n\r\nTo see what the PLL scheme is already able to achieve, I blatantly steal two screenshots by Peter Wallace:\r\n\r\nPID error including feedback noise (top signal, white) without PLL:\r\n\r\n![feedback noise (top signal) without PLL:](http://freeby.mesanet.com/nodpll.png \"feedback noise (top signal) without PLL\")\r\n\r\nPID error including feedback noise (top signal, white) WITH PLL:\r\n\r\n![feedback noise (top signal) WITH PLL:](http://freeby.mesanet.com/dpll.png \"feedback noise (top signal) WITH PLL\")\r\n\r\nrelated topics: \r\n\r\n[synchronizing HAL threads to an external clock](https://groups.google.com/forum/#!topic/machinekit/drU1p_GNZ3E)\r\n\r\n[RTDM GPIO driver to support external clocking on ARM/Xenomai](https://github.com/mhaberler/gpio-irq-rtdm)\r\n\r\n[HAL triggers branch to eventually support external clocking ](https://github.com/mhaberler/machinekit/tree/hal-triggers)\r\n\r\nrelated links and threads on the Xenomai list about RTDM-native which (ideally) would enable this scheme also for RT-PREEMPT and possibly vanilla kernels:\r\n\r\nhttp://www.osadl.org/RTDM-native.howto-rtdm-native.0.html\r\nhttps://git.xenomai.org/rtdm-native.git/\r\nhttps://www.mail-archive.com/xenomai@xenomai.org/msg09182.html\r\nhttps://www.mail-archive.com/xenomai@xenomai.org/msg09162.html\r\nhttps://www.mail-archive.com/xenomai@xenomai.org/msg09117.html\r\n\r\n[Xenomai RTDM driver which could be recycled for Mesanet cards for handling IRQ's and interworking with HAL triggers](https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/sja1000/rtcan_peak_pci.c)"},"comment":{"url":"https://api.github.com/repos/machinekit/machinekit/issues/comments/221427469","html_url":"https://github.com/machinekit/machinekit/issues/687#issuecomment-221427469","issue_url":"https://api.github.com/repos/machinekit/machinekit/issues/687","id":221427469,"user":{"login":"cdsteinkuehler","id":1993109,"avatar_url":"https://avatars.githubusercontent.com/u/1993109?v=3","gravatar_id":"","url":"https://api.github.com/users/cdsteinkuehler","html_url":"https://github.com/cdsteinkuehler","followers_url":"https://api.github.com/users/cdsteinkuehler/followers","following_url":"https://api.github.com/users/cdsteinkuehler/following{/other_user}","gists_url":"https://api.github.com/users/cdsteinkuehler/gists{/gist_id}","starred_url":"https://api.github.com/users/cdsteinkuehler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cdsteinkuehler/subscriptions","organizations_url":"https://api.github.com/users/cdsteinkuehler/orgs","repos_url":"https://api.github.com/users/cdsteinkuehler/repos","events_url":"https://api.github.com/users/cdsteinkuehler/events{/privacy}","received_events_url":"https://api.github.com/users/cdsteinkuehler/received_events","type":"User","site_admin":false},"created_at":"2016-05-24T23:00:58Z","updated_at":"2016-05-24T23:00:58Z","body":"On 5/24/2016 5:17 PM, Michael Haberler wrote:\n> @cdsteinkuehler <https://github.com/cdsteinkuehler> so far understood (hey, \n> that's straight from #687 <https://github.com/machinekit/machinekit/issues/687> ;)\n> \n> the one thing I have never been able to answer for myself is: does the point in \n> them when the HAL thread gets around to update commanded values to the firmware \n> have ANY impact on results? it might be an academic question, and is really mere \n> curiosity on my behalf\n\nYes!\n\n> my working assumption is - once the HAL thread updates commanding values (pos, \n> vel..), they take effect immediately as I view the firmware as a very fast \n> running thread(s) controlled via shared memory\n\nYep.\n\n> background of the question - there is a primary source of jitter and that is the \n> event chain from sampling to host thread reaction (the one we are about to take out)\n> \n> there /might/ be a secondary source of jitter based on the time when new target \n> values are applied\n> \n> if this is so, that secondary jitter might be eliminated by latching values at \n> the end of the period, just before sampling the new values\n\nYou will reduce the impact of thread jitter by queuing the\ncalculations and applying the updated commanded values at the start of\nthe next period, but that will introduce a delay in the feedback loop\nthat the controller will need to account for.  Ultimately, this will\napproximately halve the effective servo thread period.\n\nAlternately, you could calculate updated values based on the current\ntime (so amplifying any changes since it has less than a full servo\nperiod time to be effective), which is likely an easier solution.  As\nlong as the absolute IRQ latency is substantially less than the servo\nperiod, this should work *VERY* well.\n\n-- \nCharles Steinkuehler\ncharles@steinkuehler.net\n\n"}}
{"actor":{"display_login":"cdsteinkuehler"}}