TouchDRO Build 2023-01-12 RC is Published

ycroosh

ycroosh

Active User
H-M Supporter - Commercial Member
Joined
Apr 4, 2013
Messages
884
Hi folks,
Yesterday I published a new TouchDRO build to the close and open testing tracks. The one in the closed track has already been approved by Google; the open track one is still in review and will likely be approved shortly.
This build is a "Release Candidate". If no further bugs are found, it will be promoted to production in about a month.

In addition to publishing this to the Google Play Store, I'm working on publishing this to the Kindle App Store as well. The app is 100% kindle compatible, so I just need to jump through some hoops to get it listed (create promo graphics, etc.). I might set a test track for it, or just go for a production release. Since there are no existing users that would be automatically upgraded, I'm a lot less worried about it (upgrade path is the last remaining thing that I'm still testing heavily).


There are two bug fixes in this build:
  1. The timeout in the calibration wizard was too short (10 seconds), and when the adapter is in idle state, it sends one readout per second. Since the wizard needs 10 samples, it would error out. The timeout is now increased to 12 seconds.
  2. Automatic sub-datum selection was not working correctly with low sub-datum density. It's now fixed.

There is another bug report that is not addressed that is related to 2D and 3D sub-datums. The behavior is as follows:
  1. Create a 3D sub-datum
  2. Create a 2D sub-datum
  3. Switch to 3D mode
  4. Activate 3D sub-datum (the one that has Z axis offset)
  5. Activate 2D sub-datum
The expected behavior is that the Z axis readout is not changed when the 2D sub-datum is selected, but the actual behavior is that the Z readout changes.

This is, strictly speaking, not a "bug". I.e. the app behaves as designed. The reason the Z axis changes is that the 3D sub-datum (which was affecting Z axis readout) is de-activated, so the Z offset is cleared. A few people got confused by this, and I see their point. The problem is that changing this behavior is a HUGE change in how the app works and would take a pretty major change. I will keep this on the bug list, but for now there is no plan to fix it. I.e. it might just end up being a "documented quirk".

Lastly, on touchdro.com, the first item in the "Resources" menu is the "TouchDRO V3 Release Status" page that has all of the info on how to get access to Beta testing (open and closed track).
 
That's great! Interesting to hear about the Kindle store. I've been using TouchDRO on a Kindle via a sideloaded Play Store, which is quite easy to do, but having it directly available would certainly be more convenient for many.
 
Maybe i'm just not looking in the right place, but is there a way to maximise the numerical portion of the display in the new app?
 
Question on lathe TPI calculation?

I used a hall effect pickup 4 pulse per rev, then switched to a quadrature encoder using only single output, the tpi display jumps around, I am set for 25.4tpi which is 1 mm. I would think using 10 rotations then get Z travel to compute would give a more accurate readout. It jumps around as if using a avg rpm calculation. I don't think rpm is a good way of calculating TPI if that is what is used. The TPI i think is a useful feature. Calculating the surface speed using rpm and diameter would be useful as well for home machinist. All other features have been great from what I have tested. Lathe mode only.
 
Revilo said:
Maybe i'm just not looking in the right place, but is there a way to maximise the numerical portion of the display in the new app?
Click to expand...
What do you mean by "maximize the numerical portion of the display"?
 
Hard_ware said:
Question on lathe TPI calculation?

I used a hall effect pickup 4 pulse per rev, then switched to a quadrature encoder using only single output, the tpi display jumps around, I am set for 25.4tpi which is 1 mm. I would think using 10 rotations then get Z travel to compute would give a more accurate readout. It jumps around as if using a avg rpm calculation. I don't think rpm is a good way of calculating TPI if that is what is used. The TPI i think is a useful feature. Calculating the surface speed using rpm and diameter would be useful as well for home machinist. All other features have been great from what I have tested. Lathe mode only.
Click to expand...
Yeah, it's not very stable. I have to use RPM, since that's what the tachometer is sending to the app (well, pulses per second...).
 
You must log in or register to reply here.
Back
Top