TouchDRO Build 2024-03-11 (Beta)

ycroosh

Active User
H-M Supporter - Commercial Member
Joined
Apr 4, 2013
Messages
661
Hi Folks,
A few days ago I published a new build of TouchDRO to the Beta track. Most of the changes are under the hood; the visible changes are:
1. Fix for the touch probe debouncing bug that was causing TDA-420 touch probe to be latches in triggered state
2. Handling for the new communication protocol features. Namely, TDA-4xx and TKD-4x adapters output the native time stamp. TouchDRO can now use it to better calculate the feed rate, chip load, TPI, etc. This also makes motion detection in various TouchDRO plus functions faster and more reliable.
3. In the Plus version, the sub-datum list now has navigation buttons to select next, previous, first, last sub-datum coordinates. Long-pressing next or previous button will turn on auto mode. In Auto mode, moving the quill down and up will move to the next sub-datum
4. Guides are now treated as 1-dimensional sub-datum coordinates throughout the app (i.e. they show up in the sub-datum list, can be toggled and deleted from there, etc.).

I also fully revamped the way the position data is routed through the app's "guts". The main reason was to better handle 2-way communications with the new adapters. The data is not displayed yet (had to hide that functionality, since I didn't have time to test it as good as I wanted too). A side benefit should be a little bit lower latency (on my tablets I get on average 20-35 ms faster "scale to glass" refresh rate with optical scales.

Looking forward to your feedback.
Regards
Yuriy
 
****Edited 4/15/24**** I misspoke about my interface requiring the "inverted" setting in the probe UI, an error that caused much confusion in the later troubleshooting steps. It behaves just as any "normally closed" probe and doesn't use the inverted setting. Sorry 'bout that. :(

While I'm here I'll spoil the story and say the issue turned out to be the firmware in my two very early boards and nothing to do with this beta release other than a change in how the probe code dealt with the erroneous probe (p) channel data caused by the underlying adapter firmware issue.

In spite of the spoiler you might want to keep reading as in amongst my flailings there is some interesting information on how the TouchDRO probe interface works and on troubleshooting with a serial (bluetooth) terminal.

Cheers, Louis
*************************


Hi Yuriy, Since this got pushed to my pad I can't use my touchprobe. I have a custom interface for my Drewtronics Probe (10mA current limiting diode and a window comparator) differentiating touch/no-touch/disconnected states and allowing the LED to function properly!
It requires the "inverted" probe setting in order for it to function properly. Since this update this setting does not seem to work. With "inverted" either enabled or disabled I still get a probe touching warning when it's not touching and no warning when it is.

Please help, Louis

v3.24.03 build 2004-03-11
 
Last edited:
Louis,
I'll take a look at it later today. That said, I use Drewtronics probe without any extra circuitry, It works as expected (LED turns on when the probe is triggered, etc.).
Regards
Yuriy
 
Isn't it pretty dim? Blue LED Vf around 3V; Drewtronics series resistor is 10K; V2 probe input pull-up 4.7K(?) to 5V gives an LED If of only ~140uA. Am I missing something?

What really pushed me to the more elaborate interface was this statement from the V2 interface documentation which I accepted without much (any) thought:

"IMPORTANT:If the probe has an LED, it has to be reverse-biased (backward), or the input won't work. To test this, connect the probe to Vcc and Ground. If the LED lights up (either when the probe is touching, or not touching), reverse the leads."


I love your probe UI (except that maybe the default for absolute/incremental should be a setting so I don't have to remember to select incremental every time to avoid wiping my absolute datum.)

I hope it's an easy fix so I can get probing again.

Thanks, Louis
 
Hi Yuriy,

I hope you’re feeling better from your adventure in Covid.

Wondering if there is a way for me to revert to the previous version? I get that forward progress to the benefit of all (and recovering your heath!) is more important than clean-up for the fringe, but if it’s possible for me to go back a release to recover lost probe functionality it would help.

If reverting isn‘t straight forward and a fix might be a while yet, please let me know. Perhaps my adding an inversion to the output of my probe circuit so as not to count on a feature no one else seems to use would be most expedient.

Please take care of yourself.

Cheers, Louis
 
Hi Yuriy,

I hope you’re feeling better from your adventure in Covid.

Wondering if there is a way for me to revert to the previous version? I get that forward progress to the benefit of all (and recovering your heath!) is more important than clean-up for the fringe, but if it’s possible for me to go back a release to recover lost probe functionality it would help.

If reverting isn‘t straight forward and a fix might be a while yet, please let me know. Perhaps my adding an inversion to the output of my probe circuit so as not to count on a feature no one else seems to use would be most expedient.

Please take care of yourself.

Cheers, Louis
Hi Louis,
I'm still not 100% on my feet, but getting better :(
You can't revert, but you can switch to the production track, which has last buld. That said, I suspect it's something with your setup. Specifically, I don't fully understand why you are inverting the probe in the app. Have you checked the data stream (via a terminal app) and verified that the "p" axis is indeed coming in inverted?
That aside, the blue LED in Drewtronics probes has forward voltage drop around 2V. 5V input should register that as "low". In my garage I can clearly see when the LED is on or off. It's not super bright, but bright enough.

Regards
Yuriy
 
Hi Yuriy,

Ok, There's actually something else going on here. I had misremembered my circuit and it is touch high (open-collector) and does not require inversion. For grins, I connected the probe directly to the v2 glass adapter probe input and the mis-behavior is the same. (I do like my brighter LED :)

With v3.24.03 build 2004-03-11 the probe UI gives a probe touching warning when it's not and no warning when it is. It does capture transitions - just the wrong ones (touch to no-touch). The input inversion setting doesn't change this behavior either way.

By way of troubleshooting I see how go back to the released version but there is a warning about loosing my settings/setups which I'd rather not - yet.

I am an experienced electrical engineer and quite familiar with the use of terminal emulators for viewing data streams, however other than TouchDRO, I am not of the Android world so have no clue how to look at data streams in that environment. Perhaps in the interest of not distracting Yuriy (yet) someone else could jump in here and guide me to capturing the info he suggested in the previous post.

Thanks, Louis
 
Is the probe connected to the TouchDRO board when you plug the board into power? I was having a similar issue, and had to make sure the probe was NOT connected to the TDRO board when I powered it on. Once the board powered up, I could connect the probe, and it behaved properly.
 
Yuriy,

Taking the probe out of it for the moment and using test clips to connect probe input to ground (or not) I tried all the sequencing variations I could think of between powering board with probe input open or ground, starting app (from quit), disable/enable probe in UI and connecting Bluetooth all with the same results as described before. Behaves as you would expect for probe input being inverted regardless of the “inverted” UI setting. Open (high) = no-touch , short (low) = touch. Warns on short (low), Captures open (high) to short (low) transitions.

I have a second v2-glass board & tablet on my lathe (no probe implemented) I could try it on but I’d have to move the lathe to get into it’s enclosure and though on (vending machine) casters, given the present state of my shop, making room to move the sucker is non-trivial. I’d do it if you can’t replicate the issue on your v2 board.

Lemme know…
 
Last edited:
Just to be clear, all was well right up until v3.24.03 build 2004-03-11 was pushed and then it wasn’t. Given the timing I wouldn’t think the issue is unique to my specific board so not sure why others on the beta track haven’t seen this unless those with probes are all on the new hardware? Anyway, let me know if I can do anything more on my end.

cheers, Louis

***edited ‘cause the first try went out prematurely and sounded grumpier than intended :)
 
Last edited:
Back
Top