> Subject: Re: A found problem and I ramble...
>
> On Sat, Jan 03, 2009 at 08:59:51AM +0000, Chris Morley wrote:
> > filename =
> > os.path.expanduser("~/emc2/configs/common/configurable_options/ladder/TEMP.clp")
>
> the global variable "distdir" is the path to configs/common, but it's
> correct for both run-installed and run-in-place systems.
Ya I knew you must have had a way to find configs in both
systems. I will fix that soon.
> > I added widgets/code to allow loading two more parports (figure a pci card
> > prob has 2)
> > The pins of these are not configureable (right now) they are just connected
> > to
> > signals that follow a naming convention. The user can manually connect to
> > them
> > in the custom hal file.
>
> It's fine if you want to let the user specify more than one port, but I
> don't understand the value in preconnecting the pins to signals that go
> nowhere. If the user is such a drooler that he can't write a full "net"
> command in his custom.hal, he's not going to be able to write half of
> one either.
It's a philosophy. To use buzz words: encapsulation and standardization .
all IMHO:
Encapsulation:
After making a custom hal file the user should be able to use that file
on any new versions of stepconf with the minimum of changes and
certainly with out modifying the machine named hal file.
If the user uses steconf's standard signal names then the developers
can change any realtime driver all they want and as long as stepconf
still supplies the same signal names the users custom hal file wil still
work. Now granted the parport driver is not likely to change but
the principal is the same and should be applied to all signals that
stepconfig creates.
Standardization:
In the longer run standardization of signal names helps everyone.
when helping people with extending options/debugging instead
of saying
"figure out what signal is connected to parport 2 input 2 and connect
it to widget x"
we can say:
"since you used stepconf from emc 2.3.x connect signal pp2digitalin2
to widget x"
what seems like a small difference is a lot bigger to a newbe!
He doesn't have to search for anything he just writes the comand
in the custom HAL file.
looking forward: to more complicated configuration programs,
if we start the standard signal names now we can rely on them being
there later. Easier to combine options if the signal names are always
the same.
And finally say I user wants to change the estop chain and the
option he wants is not in stepconf. In my mind the proper way
would be to unlink and relink the signals in the custom hal file.
If you use standard signal names then this technique will work
no matter how it was hooked up or what version of stepconf
was used, the user just needs to know the signal names.
The signal names should be written in the readme that stepconf
creates.
Of course If everyone thinks I'm a nut then it's easy to remove
the creation of signal names from stepconf.
This should create some discussion!
Cheers
Chris Morley
_________________________________________________________________
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
http://www.microsoft.com/windows/windowslive/photos.aspx------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
