Touch probe not working on my new TDA-420

[buffdan]

Love my new TDA-420.. Sure works great..

I bought a cheapola touch probe (same as Mark Presling uses) from ALIexpress
It comes with USB plug cable, with 3 open wires
I referenced 4- pin mini din configuration to make sure I was wiring to correct pins, and reference from touchDRO for appropriate pinout for Auxiliary connector 1. (Left most connector facing rear)
The probe 3 wires are: Red- 5V, Black - 0V, Yellow- "signal"
The led lights on the probe come on, and switch red/green when pressing the stylus.
I measured the yellow signal wire to ground, and it goes from 5v, then .2 volts when pressing the probe..
I configured in touchDRO to use electronic edge finder, and tried both NO, NC toggle.
However, touchDRO isn't seeing the "signal" from the touch probe.
Here's how I wired it:

TouchDRO aux connector1:
Pin1 - Black wire from probe (0V)
Pin2 - Red wire from probe (5v)
Pin3 - Yellow wire from probe (signal)

Any thoughts other than a defective touch probe?

thanks.
Dan

 

[ycroosh]

Dan,
This is a bug in the app. Another customer reported it last week, and I was able to repro it. I'm testing the fix tonight, and will have it in Beta tomorrow or on Sunday.

Regards
Yuriy

 

[buffdan]

Ahhhh, thanks Yuriy .
Another example of fantastic support..!

 

[ycroosh]

Ahhhh, thanks Yuriy .
Another example of fantastic support..!

Well, I will take your kind interpretation.
To me this is another example of tunnel vision on my part. I tested the heck out of this functionality using a "worst case" probe that has horrible jitter. Really proud of how well I tuned the debouncing between the firmware and the app. The problem is that when the probe just works, the debounce code latches it in "on" state until you restart the app
Anyway, the fix is working, but I need to rest everything with an old adapter.
One unexpected side effect of offering a DIY option is that I have no idea what people are using in "the wild", so now I have to test everything agains the new stuff, the old stuff, and the crazy stuff.

Regards
Yuriy

 

[SouthernChap]

Well, I will take your kind interpretation.
To me this is another example of tunnel vision on my part. I tested the heck out of this functionality using a "worst case" probe that has horrible jitter. Really proud of how well I tuned the debouncing between the firmware and the app. The problem is that when the probe just works, the debounce code latches it in "on" state until you restart the app
Anyway, the fix is working, but I need to rest everything with an old adapter.
One unexpected side effect of offering a DIY option is that I have no idea what people are using in "the wild", so now I have to test everything agains the new stuff, the old stuff, and the crazy stuff.

Regards
Yuriy

Well at least you didn't just deploy a fix to a medium size enterprise's Web application that seemingly elegantly handles null values in the response from an old, rather unpredictable, suboptimally written, 3rd party SOAP service, but actually doesn't do enough to validate the response before using it to update a few fields in a table that are vital to that enterprise's stock system.

You also didn't compound the problem, by doing some refactoring to tidy the code; refactoring that makes doing a diff on the code's previous and deployed commits, overly hard to read and thus hard to work out the specific changes that you need to roll back, whilst maintaining the actual fix.

Ask me how I know the above is worse than the mistake you made.

Als, ask me why I'm writing this post on a Saturday morning whilst taking a break from staring at an IDE for the past 2 hours rather than happily tinkering in my workshop

I'd recommend forgiving yourself.

I've forgiven me (and I think my team lead has too).

 

[buffdan]

nothing to forgive really. cant anticipate, test every possible scenario, otherwise you'd release nothing, and have this wonderful product just for your own use..