Question on Custom Punch with iFeature & Drawing Notation

[arkelec]

I have 2 questions relating to the thread title:

First Q:

I've created a Plunge Tap punch, which used iFeature for thread diameter and thickness.

It works OK, but I have to select the thread dia AND the material thickness.

This means that I need a row in the iFeature table for every combination of thread dia & thickness & the PunchId column requires a unique reference.

It's not a problem in itself, but PunchId is used in the drawing notation format.

I would like to just show the thread size in the notation.   The available data fields for punch notation do not facilitate this, unless the PunchId value reflects it.

Is there a work-around for this issue, or is it down to either:

• a different punch file for each thread size
• accept that notation will have some surplus text

Second Q:

If a punch does not use the iFeature, it seems to pick up the thickness value from the host sheet metal part file into which it is used.  I assume that there is no way to use the iFeature whilst retaining it's ability to read the thickness value from elsewhere?

[marcin_otręba]

hi,

i checked and it works fine with ifeature as well. When thickness parameter exist in part in wchich you place ifeature it uses it.

If you still will have problems you can alwas give one biggest value of thread length to ifeature instead of parametric thickness value.

[arkelec]

Thanks for replying @marcin_otręba.

I tried several times with different files & could not get a satisfactory result to Q2.

Also, to solve Q1, I went with separate  files as I couldn't get this to work either.

[WCrihfield]

When you specify the thickness parameter within the iFeature, are you using a number or the actual parameter name "Thickness" directly?  If I put the name "Thickness" (without the quotes) in as the thickness value, it always identifies the identically named Parameter in the target model file and uses its value.

[WCrihfield]

As far as having a unique identifier for every variation, one thing I use to do is edit the table in Excel and use a Concat() function, with nested If...Then statements, within that first column's cells that gathered data from all the other cells in that row for use in the name.  You can use something similar to create 'smart' title's & descriptions too.

[marcin_otręba]

Hi,

If you make table like this:

it will work,

if you want to show it on the drawing use thread/holde dimmension:

[arkelec]

I did. But one way or another, they all fail if the thickness of the part is changed and/or the thread size is changed.
I probably missed a step somewhere, but this hole (pun intended) affair caused me all sorts of headaches.

It would be nice to see where I have gone wrong, but it's not critical. Attached is the ipt file from which the ide files have been derived (the ide files are on the next reply), as well as the plunge profile data (should anyone want to have a look).

[arkelec]

I tried to attach the ide files, but got this message:

I tired zipping them.

[WCrihfield]

I see now.  There appears to be more than one problem.

• First of all, I saw that within the sketch of the initial Cut feature to create the larger hole, the diameter dimension's value was "d3=Flare_OD + (Thickness*2ul)".  Instead of having this equation within the sketch dimension (which will show up in a Model Parameter), you should have this equation directly within the UserParameter named "Flare_OD". Then have that sketch dimension be "d3 = Flare_OD".
• The "Flare_OD" UserParameter, instead of having a simple numerical value (8.25 mm), it should have an equation similar to this:  "8.25mm+(Thickness*2)", or similar.
  • I assume the 8.25 mm value you currently have for the value of Flare_OD is supposed to be a constant, to always ensure the flare is this certain amount larger than the ThreadSize value?

Without the ThreadFeature, there would be no errors at this point.  But the ThreadFeature has to fit the physical feature made by the cut and revolve features.  This is where the second half of the problem is.

Thread features can be difficult to work with, since they have to fit a specifically sized model, and are driven by the external Thread.xls file.  The values within this feature can only be matching available values found within that Excel file, so you can't directly substitute a Parameter name in for a value, and have it recognize it as the value you want, unless done so by code.  So this thread feature is the main culprit, because it is not updating when you change the value of the ThreadSize parameter.

You may have to have some code to accompany the iFeature, to help the thread feature update according to the size you want.