How to name member Files ? ( CacheFileName)

[Anonymous]

Is it possible to give the IPTs which I adopted names ?

Can I use the cacheFileName Rule for such a prozedure ?

We want the parts to be copied and saved in every parametric

version with the same name.

Thank you / Regards

Timo

[JackGregory]

I am confused by your questions a bit, so let's break the sentences down.

The IPT files which are adopted don't change their names.  They become "factories" for IPT files which ETO generates.

The CacheFileName Rule is not a Parameter, and this is deliberate.  It can be overridden, but I am not convinced that is the right thing here.  The cache file name uses a "signature" which allows ETO to differentiate between all parts with differing parameters produced from a given adopted part.  If you override this rule, and don't use the signature, you are essentially telling ETO you know better about how the naming defines the part, and this is not trivial.

Given this, I don't understand the sentence: "We want the parts to be copied and saved in every parametric version with the same name."  Perhaps you could illustrate the goal with an example?

[Anonymous]

Thank you Jack ,

The goal is to have eventually after deintnetification a drawing which refers to a model which I can easily exchange by an other model.

The drawing thereby still refers to the IAM build with factory parts . After change of parameters the model will not find the factory parts again.

This we want to change.   We will accept that the factory part within member files will be overwritten each time I change parameters . But it will have the same name

Let me explain:

1st we produce a Rev0 model and drawing with all the components , member Files , which we have at that moment .

2nd we manually modify the drawing with customer requirements ( Title Block , technical project specific information etc. )

3rd we get models from our subsupliers which we place in the ETO model . The drawing will be modified manually .

4th the customer requires some modification affecting the ETO model . If we did not deintentify we can reconfigure the ETO model but the drawing will loose its reference cause the assembly and the member files have different names. We would need to generate a new drawing with ETO but then the manuall modifications are gone.  So the idea is to have all the parts always given the same name independently what configuaration they have, and then just let the Old manually modified drawing refer to the newly configured assembly. Probably some dimensions will be gone but this will be ok !

Hope you understand my explanation sorry but my English has still capability to improve.

Thank you / Regards

Timo

[JackGregory]

The cache file name is a "key" to the parameter VALUES in the part/assembly.  All of the parameters being used are "in" the signature.  If the name does not change, then ETO will not recognize that any change needs to be made and will the use file as-is, not overwrite it.  I think I understand what you are trying to do, but as I am not the expert in this area, I will ask some colleagues to reply if there is a solution.

[Anonymous · Accepted solution]

Add below rule in your part file IKS.

Rule cacheFileName As String = OutputLocation + partFileName + ".ipt"

This will add the Intent generated part in the specified OutputLocation insted of the "Member Files" folder.

[Anonymous]

Thank you Santosh for your answer.

Works perfect for now !

I just need to change my coding and check if the drawing

will do what I expect .

Thank you

Timo

[Anonymous]

@ Santosh:

I modified my code accordingly but I have been happy about the solution to early. Now if I modify my assembly with the assembly parameters the single parts get reused. But the parts are not fitting as they are not calculated again and not being refreshed. The assembly just uses the parts which are available even if parameters have changed. How can I tell ETO to always refresh and overwrite every single part once a assembly parameter has changed ? I know I will have always to wait for all the parts being calculated again but I can not see another solution and therefore admit to wait a bit longer .

Thank you / Regards

Timo

[JackGregory]

I was writing a note about how this would not work when your response came in.  Here is what is going on:

1. Intent detects a change in a "signature" parameter.

2. It creates a signature file name that contains a "key" that will only match a file with all signature parameter values that match the desired state.  This is what you are breaking with the change.

3. Intent looks for a file in the cache that already has all the values being requested in all signature parameters.

4. If it finds an existing file that matches the signature name, it is used.  This is what you are seeing.

5. If it doesn't, it saves it and uses that.

So, the problem is that in addition to changing the name to what you want, you also have to break the built-in behavior of using it if it exists.  This logic is deep inside %%IvAdoptedPart, and it is possible for you to override this as well, but I am not recommending it at this time.  I definitely would caution against changing low-level Autodesk mixins, and instead build a new Design which incorporates what you want from the existing mixins and overrides thereon.  Not for the faint of heart, but it is hard from this distance to advise in more detail.

[Anonymous]

Thank you Jack for your realistic view and answer!

---

@JackGregory wrote:

I definitely would caution against changing low-level Autodesk mixins, and instead build a new Design which incorporates what you want from the existing mixins and overrides thereon.  Not for the faint of heart, but it is hard from this distance to advise in more detail.

---

So if I understand you right there it is NOT ONLY an issue of making my own signature  e.g. based on the system time ? This does not seem to be low Level ! Would't that indicate enough to have Intent facing the fact that there DID something change,  and that Intent does NOT use the existing part ?

I admit it is a sort of a work around but ...

Anyhow, the overall goal of having a drawing bases on revision 0, then drawing will be manually modified, and then Drawing is still being possible to use with a new configuration incorporating the manual mods, is still a fact for us.

So somehow we need to produce/ find  a solution. I am honest that I do not fully understand what I quoted above. Are you willing to support with a new design skript to override this functionality ? Or what can we do that the distance is not an issue anymore ? We can hardy send you our projects as we connected several SQL databases to it.

Is it possible to ORDER such a skript somewhere and pay for it ? Or would you suggest another procedure ? We would also welcome you here at our place anytime. Where abouts is your base ! My collegue is in Las Vegas this week .

Thank you / Regards

Timo

[Anonymous]

Sorry - I noticed that the signature is still there and changing after modification of the assembly design. So My work around does not seem to be one !

[JackGregory]

I am in Waltham, MA USA.  But by "distance" I meant distance in understanding from the actual application.  I still don't really understand enough about what you are trying to do to be able to advise you correctly in all cases.  This is true of anyone here, so you have to take advise here with some caution.

You can contact Autodesk Consulting for direct help with ETO applications.  There are also 3rd-party contractors that can help with ETO applications.  The first thing they will do is try to understand what you are trying to do.  So far, here is what I understand:

1. You want to have Inventor ETO always produce a same-named file for all updates, whether the file needs to be updated or not.

I am not addressing the drawing or de-intentify aspects of your statements, because I don't understand them.

Since ETO does not work like this as delivered, you are going to have to create your own Design which does what you want.  That will probably be a version of IvAdoptedPart with some overridden rules to:

1. Alter the name used to save the member files created by Intent.

2. Defeat the cache logic so that ETO always thinks a new file is needed.

I believe, but am not certain, that all of this can be done within the Intent language using IKS files.  You would generated an adopted set of IKS files, change the use of IvAdoptedPart to MyAdoptedPart (or whatever you decide to call it), and then it works in this odd way.  If you don't understand what I have described here, then I would encourage you to learn more and ask more questions, or if time if critical, hiring help would be the next step.

[Anonymous]

Thank you Jack for your patients !

Yes we need ETO to produce always the same file ! We want to override some functionality. The parts ( member files ) and the Assemblies need to have always the same name. Every time we would change the Assembly or Parts parameters the member files will be updated independently of their name.

We are having contracts with two 3rd party autodesk gold partners but the reason I put this thread here is, that they

can not help in this particular issue.

In order to provide more information about our situation and with respect to the time you might spend for this issue , would it be possible

to send you a power point presentation showing what we are doing ? I can not post it here due to our company regulations.

What I actually did already is to put following in the heading folder of Adopted Components :

Rule DisableMemberPartEditing? = False

Rule AutoSaveChanges? = True

The result is that the parts get updated but some parametric values are not transfered .

I admit this seems to be more a trial and Error sort of working but otherwise I am helpless.

I will go on learning and try to get some help. If you are willing to understand our situation let me know

so I can prepare the presentation.

Thank you / Regards

Timo

[Lesoux]

Do you have this issue in design process? I had similar issue when I tried to modify factory file after 3D model has been generated (I used my own cache file names). Only generation from scratch allowed me to implement some factory file modification. Not on a fly. Autodesk fixed this issue for our company specially. I don't know whether it was implemented in SP.

[Anonymous]

We have this issue during design process. After the model is prepared I don't want to change the name. The reason why we trying to do this is for having a drawing independently from the model due to the always same model and part names. But eventually we now stopped this path due to other upcoming problems with the filename. We still invenstigate how to solve our issue. Anyhow the parameter cacheFileName was working fine but I can not tell what is part of the SP. We use ETO 2012

Thank you / Regards

[Lesoux]

Unfortunately, it will not work with ETO 2012. As I said, we had the same issue on ETO 2013 R2. Actually, ETO 2014 has the same issue, just FYI, I tested it. We have worked with Autodesk directly to solve this problem and got patch (manual). Do you have subscription on ADN? I would recommend change ETO version at least on ETO 2013 R2. I have fight with ETO 2012 long time, believe me.

[Lesoux]

Please, see this link: http://images.autodesk.com/adsk/files/DL_22424851.htm

Seems like in ETO 2014 SP1 Autodesk fixed this issue by case from our company.

"DE1072: Fix problems when updating factory files when member file has a controlled name (ADN case 08282409)."

[JackGregory · Accepted solution]

Please note that one of the fixes changed the name of the critical parameter to EnablePartEditing?  and thus needs to be set to true.  It was DisableMemberPartEditing? in the 2012 release.  I believe this issue is resolved at the customer, but I wanted to clarify in this thread.