> > 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 unwanted idea. Cheers Chris Morley _________________________________________________________________
------------------------------------------------------------------------------
_______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
