Charles,
On 1/16/2014 8:48 AM, Charles Steinkuehler wrote:
> I am reviewing the new configuration setup for 2.6 and trying to modify
> the BeagleBone ARM configurations to follow suit but I have a few questions:
>
> * How do I determine if a configuration should go into by_machine or
> by_interface, or am I to somehow create symlinks so it shows up in both?
I'm going to step back (and up onto the soap box) and ask the question
that seems (at least to me) to get skipped....
What are we trying to accomplish with the config dir structure?
My answer: Make it easy for an _end user_ to find the LCNC
config(s) he needs.
I tend to come at this from an end user point of view - I think about a
user that is new to LCNC and I imagine that it would be nice to be able
to easily find the stuff that pertains to what they have - while happily
ignoring the rest.
Today (anything pre UB), LCNC essentially assumes an x86 PC
architecture. If you want to run LCNC, you get a PC and pick some
interface hardware you like (EX: PP or Pico or mesa cards). Thus, it's
not a surprise that the LCNC configs are heavily PC oriented. That's
natural as that is has "has gone before". You don't get ARM or other
non-PC architectures until you have UB and machine kit stuff and what
gets developed on top of branches like those...
So, presuming that we are heading toward UB in the 2.6 release, this
creates what I see as the first goal for the config dir structure:
1) The structure needs to provide (at minimum) some organization that it
does not mix PC and non-PC architectures in a flat structure.
That's what I was doing when I did the ARM sub dir structure last
summer. I think we are there re this goal with either what Dewey has
done or what I did for the arm tree in machinekit - as long as we keep a
structure that separates PC and non-PC architectures.
My bias: I have little interest in the developer / programmer view of
file optimization in this case. I really don't care if files are in more
than one place, or they are in one place and found via simlinks etc. I
happen to think that the way LCNC pieces themselves go together is much
less important and should not drive the config dir structure.
The natural thing for a user to do is: Hum what am I using for a control
computer? Ah, a my buddy gave me a beagle bone (or RASPI or...) - ok,
let's look in the BB area. What have I got to hook stuff up to (i.e.
what's my hardware interface gadget)? I got a spiffy new K9 board
that plugs into a BB; OK, let's try the BB/K9 dir.... This just seems to
me to be the natural way people will look for configs (today).
I realize that what I just described is a bit more "system integrator"
oriented than I'd expect over the long haul. It certainly points out
that you still have to be a system integrator to figure out LCNC. But
that's just where we are in the market development for non-PC LCNC
controls. If/when there is significant market presence for (non-PC)
controls, it may merit some polishing re config dir structure. I feel we
can address that if/when it becomes a need.
Frankly any dir structure that separates, and thereby recognizes, that
the LCNC world is not all PCs will be a good improvement. If we get that
as a min, I'm (probably) happy for 2.6.
> * Most of my configurations will use the same interface, but may have
> different pinouts. For example, the same 3D printer machine could be
> controlled by virtual identical *.ini and *.hal files, with only a small
> *.hal file snippet changed to reflect the use of different I/O pins by
> various hardware (ie: BeBoPr board, BeBoPr+ or generic CNC board, K9
> board, etc). What is the recommended procedure for reflecting this in
> the configuration structure?
Just my 2cents: To me this is what an end user does not care about. They
don't really care about if pins are driven by GPIO or PRU code etc. Thus
this is a lower in the dir thing - i.e. it's a sub config choice for a
hdw interface.
To me the goal is for an end user (not a system integrator) to easily
find what they can use - which is not the same as easily find what they
can start from and then modify (they want to be users, not system
integrator programmers).
Dave
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
