On 11/19/2018 04:38 AM, Gene Heskett wrote:
On Monday 19 November 2018 05:06:29 Nicklas SB Karlsson
wrote:
What did you want to discuss with the addf function?
I used it and think it works but what's more?
We need a utility that detects out of order addf's, each
of which then
causes a one thread execution delay in the data traveling
that path.
WOW! This would be like a program that detects improper
word order in the English language!
While theoretically POSSIBLE, I think it would be quite hard
to do. You could look at the net commands, and figure out
which pins are outputs and which are inputs, and then kind
of determine what the flow is SUPPOSED to be, and then see
if the addfs execute the hal components in the same order.
But, it isn't so simple! Some hal components are not in the
"critical path" and so the order is much less important.
AND, for instance, all of the Pico Systems devices have an
INTENTIONAL "violation" of this rule. The reason is that
when the command to come out of E-stop is given, the modules
are not SEEN to be out of E-stop until the next servo cycle
reads the inputs. This allows the E-stop software-side FF
to not get sent back to E-stop immediately. So, if you
"fix" the addf order, you will not be able to come out of
E-stop.
Finally, even if you were to find conflicts between net flow
and addf's, if you get the net wiring wrong, the proposed
tool would only make sure the addf's were consistent with that.
So, using the hal show, halmeter and halscope tools, plus
understanding what is going on in the HAL layer, is the only
real way to get it right (in my opinion).
Jon
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
