Greetings -----Original Message----- From: Jeff Epler [mailto:jep...@unpythonic.net] I have written 'anonymous net' support in branch jepler/anonymous-net
Here's how I describe the new functionality: halcmd: allow net command to create anonymous nets Anonymous nets are named 'n$0', 'n$1', and so forth. This usage is not ambiguous, because until now it was an error if the first argument of net had the same name as a signal. However, any hal file that explicitly uses signals with names starting 'n$' will need to be rewritten to use a different prefix before it can use anonymous nets. ------------------------------------------------ I think this will contribute greatly to the maintainability of HAL files, especially for complex systems with multiple HAL files for operator controls and tool changers. It has always been a problem to me knowing if something lexically remote and unexpected (an input pin of course) is hooked onto a given signal name because of their global nature. One can of course inspect the running system but how much better it is to be able to desk check things too. I am however worried about the disambiguation. I assume you mean: This usage is not ambiguous, because until now it was an error if the first argument of net had the same name as a *pin*. While the system will easily know this, the human reader will not easily discern the situation. Many comps have pins that are seldom used so the human reader will not instantly recognise if an anon-signal construct is intended or not. Is there any reason not to make this explicit by a command like anet (standing for automatic/anon net) which will only have a list of pins (conventionally or perhaps mandatorily) starting with the output pin? John Prentice ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users