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
