> > 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.
> The developers will NOT change any realtime driver (such that pin names
> change) within any major release series (like 2.1.x, 2.2.x, 2.3.x, etc).
> And when we make changes between major releases, we document them.
> Using stepconf generated signal names to try to hide component name
> changes just screws over everyone who doesn't use stepconf.
I didn't say that anyone would change drivers between major releases.
I was meaning after major releases.
I don't understand how hiding component name changes screws over
everyone else. signal names created by stepconf are only used by
machine configuration that used stepconf to create them.
> > 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!
> I strongly disagree with naming _signals_ after things like parallel
> port pins. Of course anyone is welcome to name signals whatever makes
> sense to them, but IMHO it makes far more sense to name a signal based
> on what it _does_, not where it goes. Names like "X-hi-limit" and
> "Z-step" are much nicer than "pp2digitalin2". If you want to know what
> pin "Z-step" is connected to, do a "show sig", and it will show you
> every pin connected to that signal, including the parport pin.
That is a good naming convention.
> > He doesn't have to search for anything he just writes the comand
> > in the custom HAL file.
> > 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.
> (tact filter off)
I certainly hope that your not actually mad me for voicing an opinion.
I wrote this email so people could give me their opinion.
If I offended somehow I'm sorry.
> In my mind the proper way would be to start with the files that stepconf
> generated, and then exercise the brain cells and make the changes needed
> directly in the hal and/or ini files. Stepconf is training wheels -
But that is not how most people do things. They start with some easy
way (stepconf for instance) then when they want more they add a little to
the generated config. then they add more etc.
The jump from generated conf to super advanced config is to much of a jump.
I read about it all the time. A new giy has to learn linux, ubuntu, HAL, ini,
Pyvcp classicladder etc. It a lot all at once.
> when you want to do something beyond what it does, you should take off
> the wheels.
> In fact, I think of ClassicLadder as a bit of a dividing line. If you
> are integrating a machine that is complex enough to want ClassicLadder,
> you should take the training wheels off and understand your config at
> the hal file level.
To each their own John. We give them options they choose how they
want to do it.
>A _major_ advantage of doing that is that you can
> add comments into your hal and/or ini files to explain what you are
> doing - unless something has changed recently, stepconf kills comments.
The user is free to comment the custom HAL file-it is never over written.
> (tact filter on)
Anyways I added the code cause I was there anyways it semed like a good
idea, it was easy and we had time to remove it before it releases.
I sent the email because I wasn't trying to hide what I did nor push an
Cheers Chris Morley
Easily add maps and directions to your online party invites. Click to learn how.