On Saturday 08 September 2018 23:54:33 Jon Elson wrote: > On 09/08/2018 07:27 PM, Chris Morley wrote: > > Jon > > > > I'm not sure where they are at with replacing NML, but that is not > > what I was talking of. > > > > They have split the cnc stack from the HAL stack > > > > HAL is what I am talking of, which would include the realtime code I > > suppose. > > Anybody, NOW, can download LinuxCNC and just USE the hal > components of their choice, without ever using the G-code > interpreter or trajectory planner. It has always been that > way, although NOT well publicized. > > But, yes, the LinuxCNC version of hal (I'm pretty sure) can > only run on a single core. I can see some real issues to > solve when different components are running on different > cores concurrently. That could get quite complicated. > Running different real time threads on different cores ought > to be safe to do, but I kind of doubt our rtapi can handle > that right now. > > Jon
I don't believe the kernel I'm using on the pi is either rtapi, or limited to a single core , at least not with an obvious isolcpu's kernel argument, just a fully preemptable version. A uname -a says: 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC 2016 armv7l I have it and its matching library pinned to prevent apt from upgrading it and spoiling my playground. But that has not prevented apt from keeping the rest of that jessie based install uptodate with jessie. So lets play what if in the wishfull thinking category: As for using more cores, in particular it might be desirable to setup, using "threads" as I am now, such that it might be possible to have each thread run on its own core, or have on a 4 core cpu, 4 named threads with 3 of them running at a slower rate as I am presently doing with a 200 hz thread rate for the slower stuff like the jog dials which I cannot turn at a 1 millisecond step rate anyway. Encoders are 100 ppt, quadrature, so a full turn is 400 edges to count, works well in a 200hz thread. Works well even if that thread is slowed to 100hz, but the pi is loafing in either case. For the same reason, this bed wear stuff doesn't need up to update the X offset values at a kilohertz rate since the fastest z speed is 45 ipm due to that Z motor being the slow one I took off the g0704's Z drive. I think having the ability to setup a 3rd and 4th thread, running at even slower rates might allow the stuff for x to run in a 2nd 200 hz thread and Z running in its own 200 hz thread could be usefull in unloading the 1 millisecond main thread. The pi is not being pushed to an overheat condition by what I am doing now, as the main 1khz thread seems to use only about 40% of that millisecond now according to htop. Latency jitter is excellent. My 2 cents. I see exciting times ahead in any event. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
