Chris Morley wrote: > >>> 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.
I'm afraid I didn't read the first email in all that much detail, but I have to agree with Jeff here. > 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. 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. > 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. > 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) 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 - 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. 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. (tact filter on) > This should create some discussion! Yep. Regards, John Kasunich ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
