TouchDRO Build 2024-03-11 (Beta)

Curiosity got the better of me…

Set it up from a new mill configuration on my other v2 adapter & Lenovo tablet with the same result. Of course my lathe now thinks it’s a mill…

Soooo, unless I’m missing something, it appears v3.24.03 build 2004-03-11(beta) breaks touchprobe functionality on (at least two) v2 Glass adapters. Anyone else verify?
 
I have had no trouble with the touch probe functionality, but I did set it up recently (ie was not set up on an older version of SW. I am using an NC switch
 
I have had no trouble with the touch probe functionality, but I did set it up recently (ie was not set up on an older version of SW. I am using an NC switch
Hmmm… Are you running the v3.24.03 build 2004-03-11 (beta) release indicated above? This is not the released version normally available (which works fine). You would need access to the beta track to have it. To see the version, touch the menu bars in upper left and it will show the version.

Also are you on the v2 glass adapter? https://www.touchdro.com/store/diy-dro-glass-scale-adapter-v2.html

I’m guessing the new TDA-400/420 hardware works fine as that’s likely what this beta was primarily developed on.

cheers, Louis
 
Yes,I am a beta tester, so running the latest plus release bi am using a Shahe adaptor with glass scales. I only recently switched to the glass scales and added the touch probe at the same time. The only issue I had was I initially had the probe contacts incorrectly connected (+ to probe or probe to gnd), and switching them sorted the problem
 
This one - yes? https://www.touchdro.com/store/diy-dro-shahe-scale-adapter-v2.html

So different hardware, maybe firmware(?) than mine. Perhaps useful info for Yuriy.

Just for fun you might see what happens if you enable “inverted“ in the probe settings. Does the behavior stay the same or does it start to behave as I’ve described.

thanks!, Louis


***Still hoping someone running the beta on a V2-glass adapter will weigh in…
 
Hi Yuriy,

Have you had a chance to look at this issue?

I’m pretty confident my most basic testing (test lead between the board’s probe input pin and ground pin) on both my v2 glass adapters shows an issue with this beta. Not sure why Schtimpy’s v2 shahe adapter behaves differently (properly) unless there’s something different in the probe interface hardware/firmware/api between these two products.

to reiterate: The touch probe function in v3.24.03 build 2004-03-11 (beta) on both my v2 glass adapter boards behaves as you would expect for the probe input being inverted regardless of the “invert” setting in the UI . Open (high) = no-touch , short (low) = touch. Warns on short (low), Captures open (high) to short (low) transitions

In order to be able to keep working with this beta, I added an inverter to the output of my “bright light” probe interface (now touch low) and things are working for the time being. Now when this all gets sorted and working as it should, I will be dependent on the invert setting in the UI.

I’m good for the present and will stop pestering you with this. No one chimed in to guide me in observing the p channel data. I’d be happy to have you guide me if the result would be helpful. Let be know if I can help further.

Regards, Louis
 
Louis,
The "Inverted" flag was not working in "3-11". I fixed it and pushed the new build to Beta yesterday.
As far as the probe staying latched, I have no clue what is happening. I can't reproduce it with any of my adapters (I went back to MSP430 based stuff, and the probe still works).

I'm also still not sure why the probe comes in inverted to the app in the first place. That is not supposed to be happening. In the firmware the probe is detected during boot and whatever the state it's in will be off, and the opposite state will be on. This way, NO and NC probes still send p1 when on and p0 when off.

Terminal app is discussed on this page: https://www.touchdro.com/resources/troubleshooting/troubleshoting.html (half-way down). If you get to it, I'm curious to see what you get in the stream.

Regards
Yuriy
 
Hi Yuriy,

I sent you some captures via email (yuriy at touchdro dot com)

Let me know what you think.

-- Louis
 
Hi Yuriy,

I sent you some captures via email (yuriy at touchdro dot com)

Let me know what you think.

-- Louis
Louis,
I looked at your captures, and they don't look right. When the probe is in "off" state (regardless of whether it's NO or NC) you should be not getting "p1". Most firmware will send only about 10 "p0" data points and then stops sending probe data until it's triggered again. When the probe is triggered, the firmware will send "p1" for as long as the probe is triggered, then a few "p0" and stop sending probe data again. The "Inverted" switch in the app is not a good workaround in this case. There are important timing implications, so having this backwards will cause all sorts of issues.
Most importantly, off-to-on transition has the highest priority. When the probe triggers, the firmware grabs the counter values within 2-4 microseconds; during on-to-off transition it doesn't, so the delay can be 40 milliseconds in the worst case scenario (4 factors of magnitude slower), which will destroy any hope for probe accuracy or repeatability.
Second, when the probe is off and is "spamming" the app with "p1" data, which takes extra processing (drains the batter faster on the tablet), etc.

The expected behavior for any ESP32-based TouchDRO adapter should be:
when the probe is not triggered (regardless of NC or NO), you should see a few "p0"s in the data stream
when the probe is triggered, you should see "p1" until the moment when the probe returns to the default state.

A few other things:
On most TouchDRO adapters probe input is pulled up to 5V via a weak pull-up resistor. If the probe you are using behaves as a basic switch, it should be connected between the signal pin and the ground. Vcc is only used for "fancier" probes that have internal circuit, etc.
In most cases, build-in LEDs can cause issues, but Drewtronics probes (at least the three that I touched) seem to work OK with the LED. May be I just go lucky and the combination of tolerances on the Schmitt trigger IC on my board and the voltage drop on the LED just worked somehow.
With every TouchDRO adapter that I ever sold/made, the stuff should be plugged in before the adapter is powered up. The firmware does all sorts of checks and self-configuration during boot. This is VERY important.

Regards
Yuriy
 
Louis,
I looked at your captures, and they don't look right. When the probe is in "off" state (regardless of whether it's NO or NC) you should be not getting "p1". Most firmware will send only about 10 "p0" data points and then stops sending probe data until it's triggered again. When the probe is triggered, the firmware will send "p1" for as long as the probe is triggered, then a few "p0" and stop sending probe data again. The "Inverted" switch in the app is not a good workaround in this case. There are important timing implications, so having this backwards will cause all sorts of issues.
Most importantly, off-to-on transition has the highest priority. When the probe triggers, the firmware grabs the counter values within 2-4 microseconds; during on-to-off transition it doesn't, so the delay can be 40 milliseconds in the worst case scenario (4 factors of magnitude slower), which will destroy any hope for probe accuracy or repeatability.
Second, when the probe is off and is "spamming" the app with "p1" data, which takes extra processing (drains the batter faster on the tablet), etc.

The expected behavior for any ESP32-based TouchDRO adapter should be:
when the probe is not triggered (regardless of NC or NO), you should see a few "p0"s in the data stream
when the probe is triggered, you should see "p1" until the moment when the probe returns to the default state.

A few other things:
On most TouchDRO adapters probe input is pulled up to 5V via a weak pull-up resistor. If the probe you are using behaves as a basic switch, it should be connected between the signal pin and the ground. Vcc is only used for "fancier" probes that have internal circuit, etc.
In most cases, build-in LEDs can cause issues, but Drewtronics probes (at least the three that I touched) seem to work OK with the LED. May be I just go lucky and the combination of tolerances on the Schmitt trigger IC on my board and the voltage drop on the LED just worked somehow.
With every TouchDRO adapter that I ever sold/made, the stuff should be plugged in before the adapter is powered up. The firmware does all sorts of checks and self-configuration during boot. This is VERY important.

Regards
Yuriy
Hi, Yuriy, glad you’re feeling up to posting again.

A question regarding powering up: while I have always followed this procedure it can be a pain since I have backup batteries installed in both adapters so have to open the case to unplug the battery - is disconnecting the battery necessary?

Thanks & best regards, Charlie
 
Back
Top