On Mon, Aug 17, 2015, at 07:04 PM, Jeff Epler wrote: > Let's say you were trying to use this feature in your carousel code. In > the demo, it would have to read hal[locksw.over] which is an output pin > of a named wcomp instance to determine that the car is locked.. > > In a real machine, it would have to read e.g., hal[hm2_5i20.0.gpio.23.in] > instead. > > So if you wrote carousel using this feature, anybody adapting it to real > iron will have to go edit the toolchanger subroutine to make it work > with their specific hardware. This is bad. > > Happily, the way you did write it, all that is required is to change the > "net" line so that "car-locked" is linked to the right pin. This is > good.
That's simply a matter of using the "net" namespace (and a consistent net name) instead of the "pin" namespace. You could leave that decision up to the integrator, or you could enforce the policy by allowing the #<_hal[name]> expressions to access only the net namespace. (As mentioned in an earlier message, I don't know how the existing code handles the three namespaces and the fact that a name can exist in more than one.) > It's not ideal that you then have to refer to this as "M66 P1" (since > car-locked is linked to motion.digital-in-01); it would be nice if there > could be "human names" for I/O pins in gcode, but when those names are > *pin names of another component* it breaks a key part of how HAL is > intendended to be adaptable. > > But the code we have now is just not a good design or a good foundation > for making something better. > > > > Considering the panel / conversational / wizard situation, something > similar exists. Suppose you cut so many threads of just a few kinds > that you get tired of poking the screen to select the thread pitch. > Instead, you wire up a physical N-position switch. I would like > LinuxCNC to accomodate this by changing nets in hal files. But instead, > with the current design you have to go edit the O-word subroutine that > implements the thread cycle so that it reads from the processed output > of the N-position switch instead of from the VCP. Again, could be managed by reading a net instead of a pin. > > (Alternately, thread pitch shouldn't be in HAL at all but should be > internal to the panel, which would read the values of its own controls > and craft an O-call with the right numeric value in the parameter; but > AFAIK panels are too primitive to do this sort of mdi command crafting > and so we come by another road to this ill-considered feature) That is a separate discussion, and I don't have an opinion. > > Jeff > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
