#7 Hard coded thread data definitions?

[Goatofmendez]

Are all the thread definitions hard coded? It would be handy if they were gathered into the program from a text file. Then to create a slightly off or non standard thread you could either edit the thread data for that thread or create a new one based on an existing thread definition.

thanks

[stephanbrunker]

The answer is: not really. I based the app on a bunch of tables at: http://www.emuge-franken-bg.com/attachments/article/97/15%20Gewindetabellen.pdf

but instead of hard coding all the tables, whenever possible I converted the data into formulas whenever possible so you can create virtually every Thread in spec but with the possibility to choose diameter and pitch at will. So you can create a M9.5 x 0.8 or something else simply by typing it into the appropiate fields - the values entered by the dropdown are only presets. Only where is was simply impossible (like the pipe threads where the diameter value has nothing to do with the actual diameter), I hardcoded the values.

You can see that if the text fields are locked or not.

More or less, the thread spec defines the relation between flank angle, amount of play, tolerances and form of the thread ground, so you don't want to change that relationship. But it all comes down only to the values of the G78 macro which means depth and pitch.

So, I think that my app should provide a convinient way to make threads after the specs and for all the special cases, you have to calculate your geometry anyway and then you already have your values for the G78.

But after all, I made it Open Source here in the "Code" section, so you can look into how the calculations are made and can create a kind of pull request (it is only a SVN repo and not a Git) and if it makes sense, I'm going to merge it into the code. That is my way of handling foreign apps where I think an addition will help, but normally, my contributions are ignored. For my own app, I won't deny contributions if they don't interfere with the existing behaviour. It is written in Basic, so everyone should be able to read the code and add new modules ...

I have to look into the behaviour if out of spec tool tips are only warned at or not allowed, change that to a warning and allow is simple.

But be careful: I think fiddling with the flank angle doesn't make sense. And the relationship between diameter, pitch and tolerances for outer/inner diameter and flank diameter are mostly cubic formulas, so any correction module has to integrate the correction factor into these cubic formulas.

[Goatofmendez]

Hi thanks for the reply - what Basic is it written in? E.g which editor and
version are you using? The files look like the old Visual Studio VB5 style.

Thanks

Steve

----------------------------------------------------------------------------

When I came here 17 years ago, you all laughed at me. Well, you're not
laughing now, are you!

Nigel Farage MEP - [Addressing the European Parliament June 28th 2016]

From: stephanbrunker [mailto:stephanbrunker@users.sf.net]
Sent: 21 December 2017 21:08
To: [mach3threadinghelper:tickets]
Subject: [mach3threadinghelper:tickets] #7 Hard coded thread data
definitions?

The answer is: not really. I based the app on a bunch of tables at:
http://www.emuge-franken-bg.com/attachments/article/97/15%20Gewindetabellen.
pdf

but instead of hard coding all the tables, whenever possible I converted the
data into formulas whenever possible so you can create virtually every
Thread in spec but with the possibility to choose diameter and pitch at
will. So you can create a M9.5 x 0.8 or something else simply by typing it
into the appropiate fields - the values entered by the dropdown are only
presets. Only where is was simply impossible (like the pipe threads where
the diameter value has nothing to do with the actual diameter), I hardcoded
the values.

You can see that if the text fields are locked or not.

More or less, the thread spec defines the relation between flank angle,
amount of play, tolerances and form of the thread ground, so you don't want
to change that relationship. But it all comes down only to the values of the
G78 macro which means depth and pitch.

So, I think that my app should provide a convinient way to make threads
after the specs and for all the special cases, you have to calculate your
geometry anyway and then you already have your values for the G78.

But after all, I made it Open Source here in the "Code" section, so you can
look into how the calculations are made and can create a kind of pull
request (it is only a SVN repo and not a Git) and if it makes sense, I'm
going to merge it into the code. That is my way of handling foreign apps
where I think an addition will help, but normally, my contributions are
ignored. For my own app, I won't deny contributions if they don't interfere
with the existing behaviour. It is written in Basic, so everyone should be
able to read the code and add new modules ...

---

[tickets:#7] https://sourceforge.net/p/mach3threadinghelper/tickets/7/
Hard coded thread data definitions?

Status: open
Milestone: 1.0
Created: Thu Dec 21, 2017 07:25 PM UTC by Goatofmendez
Last Updated: Thu Dec 21, 2017 07:25 PM UTC
Owner: nobody

Are all the thread definitions hard coded? It would be handy if they were
gathered into the program from a text file. Then to create a slightly off or
non standard thread you could either edit the thread data for that thread or
create a new one based on an existing thread definition.

thanks

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/mach3threadinghelper/tickets/7/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[stephanbrunker]

Its written with Freebasic, available here on Sourceforge. FB uses the QuickBasic Syntax, but has a complete set of Windows header files for the GUI programming and supports Oop and other features of an up-to-date programming language.