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. 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. (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) Jeff ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
