On Thu, 09 Sep 2010 07:39 -0500, "Stuart Stevenson" <[email protected]>
wrote:
> Gentlemen,
> I have a prox for tool change zero return (to home the chain of pots)
> and
> a prox to count the pots during chain motion
> The chain moves slow - between 1 and 2 pots per second
> The chain matrix carries 30 pots
> This is a random tool changer - the pot swings down and a transfer arm
> swaps the tools between the spindle and the tool change pot
> I want to reset the count to 1 every time the zero return dog passes
> the
> prox
> The following code resets the count as I wish
> I have an edge component set up to trigger on the falling edge of the
> pot count prox signal
> The following code counts two every time the pot count dog passes the
> prox
Use halscope to observe the input from the prox. Zoom in enough to
clearly
see every single servo cycle. (set the horizontal scale to 1 or
2mS/div)
Maybe it is generating a double pulse? or a pulse with a glitch on the
leading edge?
Use halscope to observe the output of the edge component. Maybe it is
broken and is triggering on both edges? Maybe it is broken and is
making
a two-cycle long pulse?
Use halscope to see exactly when and by how much the count advances.
You can trigger on the count itself, so it should be easy to see the
event. If the count is only used internally in your component, and
isn't visible to halscope, then at least temporarily make it a pin.
Does it advance by two during one servo cycle? Or does it advance
by one in one cycle, and advance again on the next cycle?
>
> if (PotZero) {
> toolpotcount = 1;
> } else if (PotCount) {
> toolpotcount = toolpotcount + 1;
> }
That code seems sort of OK to me. "Sort of" meaning, I can't tell
why it would count twice. There is another possible problem with
it though:
Suppose the Count signal and the Zero signal arrive in the same
servo cycle. In the cycle when both signals arrive, the first
conditional is true, and the second one is skipped. Result = 1, OK.
Now suppose the Count signal arrives one (or more) cycles before the
Zero signal. In the cycle where the count signal arrives, the second
conditional is true and you get an increment. A few milliseconds
later the zero signal arrives, the first conditional is true, and the
result is 1. Still OK.
Now suppose the Count signal arrives one (or more) cycle _after_ the
Zero signal. In the cycle where the Zero signal arrives, the first
conditional is true and the result is one. But a cycle or two later,
the Count signal arrives, the second conditional is true, and the
counter increments. Result = 2 which is wrong.
If the zero and count edges happen very close together, it will be
impossible to guarantee correct operation. I'd look at both inputs
with a scope (hal or real storage scope) while running the chain
around many times. If there is a clear and repeatable interval
between the two edges, then you can code accordingly. But if they
are too close together to reliably ensure that one always comes
first, then I'd consider using a rising edge to count, and a
falling edge to reset, or something along those lines. You want
the count to happen first, followed by the reset.
Personally, if I was writing C code anyway for this component, I'd
incorporate the edge detection in the component to avoid having a
couple other components and signals in my HAL config. Something
like this:
static int oldPotZero, oldPotCount;
// detect rising edge of count
if ( PotCount && ! oldPotCount ) {
toolpotcount = toolpotcount + 1;
}
//detect falling edge of zero
if ( ! PotZero && oldPotZero ) {
toolpotcount = 1;
}
// remember current state of inputs for next time
oldPotCount = PotCount;
oldPotZero = PotZero;
> I have removed all other logic from my component - this is the entire
> logic in the file at this time
Can you post the complete file somewhere? (pastebin.ca, etc) I'm
interested in seeing the variable declarations, etc, as well as the
logic itself.
> What am I missing? (except for intelligence) :)
> I trigger the pot with pliers and get the same results whether I
> trigger
> quickly or hold the pot on.
> thanks
> Stuart
>
Hope this helps,
John Kasunich
--
John Kasunich
[email protected]
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
