On Saturday 26 January 2013 09:25:57 John Kasunich did opine:
Message additions Copyright Saturday 26 January 2013 by Gene Heskett
> On Fri, Jan 25, 2013, at 08:06 PM, Michael Haberler wrote:
> > In the current code, the only components which start RT threads are
> > motion (motmod) and threads the only components which stop threads
> > are hal_lib and motmod
> >
> > they differ as follows:
> >
> > - unloading 'motmod' stops all threads
> > - unloading 'hal_lib' stops all threads
> > - unloading 'threads' does _not_ stop threads
> >
> > so using the latter you can have RT threads running without either
> > motmod or threads loaded
>
> To a certain extent I see HAL as a generic platform
> for building realtime control systems, one of which
> happens to be LinuxCNC.
>
> Any generic control system needs one or more
> threads of execution, and the "threads" component
> is just a hack to provide a way to create them when
> using HAL for something other than LinuxCNC. The
> threads created by that component can have any
> name(s) and reloading the component is allowed
> so that you can create multiple threads incrementally
> instead of being stuck with whatever you first
> created.
>
> I sometimes use HAL interactively, literally
> building a control system one piece at a time,
> and I designed it to support that use case.
>
> Ideally the "threads" component wouldn't exist,
> and halcmd would simply offer a "newthread"
> command, along with "delthread". But there are
> (or at least were) complications with doing that,
> and the "threads" component was the lazy way out.
>
> If your "HAL daemon" approach would allow a
> "newthread" command to work, I think that would
> be the best overall approach. But that is only
> my opinion.
>
> Motmod creating threads is another hack. Since
> LinuxCNC is the most common application that
> uses HAL, and since most LinuxCNC users don't
> really care about the messy details, motmod creates
> the threads it needs automatically. The threads that
> motmod creates are always named the same ("base"
> and "servo") because that makes things simpler for
> LinuxCNC.
>
> If we had a "HAL daemon" with a newthread command,
> we would probably still want motmod to invoke the
> command "under the hood" instead of making the
> average LinuxCNC user explicitly think about threads.
>
> > Intuitively I would say if I look at halcmd comp output
> > and see neither threads or motmod loaded but thread
> > functions actually called and maybe hardware moving
> > that is confusing.
>
> I think that is only because of the way threads are
> created today. In my mental model of HAL, pins
> and parameters belong to components, just like pins
> of integrated circuits on a PC board belong to the
> parts that are soldered to the board.
>
> On a PC board, signals (nets or traces in PC board
> design terminology) are a different class of things.
> They don't inherently belong to any of the parts on
> the board, instead they belong to the board itself
> and connect the parts. Likewise, HAL signals to
> belong to HAL itself, not any of the loaded components.
>
> I see threads as more like signals than pins. Threads
> should exist as part of HAL itself, not belonging to any
> one component, and they shouldn't stop and go away
> until you shut down HAL.
>
> > It really rests on a definition, namely whether threads
> > are 'owned' by a module, and if so, which one(s);
> > meaning unloading that module stops threads, or
> > not. HAL does stop threads on exit, which suggests
> > threads are 'owned' by HAL; in which case motmod
> > is inconsistent with that definition.
>
> The intent is that threads are owned by HAL. Motmod
> is inconsistent with that definition because the distinction
> doesn't matter to most people who use motmod. The
> goal, especially when HAL first came out, was to make
> the transition from the old way to the HAL way transparent
> to the average user.
>
> > Barring other suggestions, I will change threads to
> > conform with motmod - that is, stop threads on unload,
> > which I think is safe. I know barely anybody uses the
> > threads module so that's likely safe but I'm raising it
> > more to clarify semantics than to cry wolf.
>
> I wouldn't say "barely anybody" uses threads. It isn't
> used by people who are running a finished LinuxCNC
> configuration. But it is used by people who are doing
> other things with HAL, and I'm pretty sure it is used
> under the hood by the configuration wizards. For
> example, stepconf lets you actually run an axis. I think
> it uses threads to create the threads it needs to do that.
> It could certainly use a "newthread" command instead,
> if such a thing existed.
John, I can think of at least one situation where this could be handy.
>From some very limited experiments here, it would seem to be beneficial to
have the encoder component running at a faster rate, and something like a
hal command "newthread encoder conf_rate 2000000" to get a 5 kilohertz rate
encoder thread would seem to be advantageous. It seems to work better at a
2 khz servo rate, but I haven't actually tried it any faster. I should,
and report back, and will when I get this new screw working.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
You will have a long and boring life.
I was taught to respect my elders, but its getting
harder and harder to find any...
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
