What's wrong with CC "Other" parts?

[PremTM]

Hi! 

I've been exploring Content Center file creation lately and I've come across a certain error, which (as far as I've been able to find out for myself) appears only when you publish a fastener to the "Other" file folder and only once per file created.

Error text: Unable to successfully update the member part file. Problem occurred when setting thread data.

When does it appear: Upon inserting the file from Content Center - that is, you place the part from CC, select its key parameters and then when you click anywhere in the 3d space you get an error.

Other misbehaviour: Auto drop does not work for those files.

I've uploaded a custom library with 3 variations of a simple custom screw only differing with folder structer choice while authoring them. One has been placed in "Other" folder, second one in "Hex screwes" and last one in "Round head screwes" folders. I never uploaded a library before, so I'm hoping there's nothing special about it, if it fails to work let me know.

Also attached are: the original .ipt file of the screw, an .ipt file with a simple plate with a matching hole.

Here's the kicker: that error appears only once per library file created. If you proceed to insert that screw from CC it may not appear. In that case simply author and publish the My_Screw.ipt file to Fasteners -> Screw -> Other library folder. Also, even though the error appears and auto drop doesn't work, everything seems to work fine afterwards. I've found this error through googling to have appeared for someone after library migration to newer version and some windows update related issue in v2015 I think, which was paired with assigning the thread a "fine" class, which doesn't happen in this case.

So, can you reproduce the issue as well? Do you know what may be the root cause for this behaviour? Let me know if you happen to have some spare time on your hands. 🙂

EDIT:

I wish I could upload the custom library, but I'm gettin an error stating that its content type does no match its file extension for some reason...sorry about that. 

[PremTM]

Hi! 

I've been exploring Content Center file creation lately and I've come across a certain error, which (as far as I've been able to find out for myself) appears only when you publish a fastener to the "Other" file folder and only once per file created.

Error text: Unable to successfully update the member part file. Problem occurred when setting thread data.

When does it appear: Upon inserting the file from Content Center - that is, you place the part from CC, select its key parameters and then when you click anywhere in the 3d space you get an error.

Other misbehaviour: Auto drop does not work for those files.

I've uploaded a custom library with 3 variations of a simple custom screw only differing with folder structer choice while authoring them. One has been placed in "Other" folder, second one in "Hex screwes" and last one in "Round head screwes" folders. I never uploaded a library before, so I'm hoping there's nothing special about it, if it fails to work let me know.

Also attached are: the original .ipt file of the screw, an .ipt file with a simple plate with a matching hole.

Here's the kicker: that error appears only once per library file created. If you proceed to insert that screw from CC it may not appear. In that case simply author and publish the My_Screw.ipt file to Fasteners -> Screw -> Other library folder. Also, even though the error appears and auto drop doesn't work, everything seems to work fine afterwards. I've found this error through googling to have appeared for someone after library migration to newer version and some windows update related issue in v2015 I think, which was paired with assigning the thread a "fine" class, which doesn't happen in this case.

So, can you reproduce the issue as well? Do you know what may be the root cause for this behaviour? Let me know if you happen to have some spare time on your hands. 🙂

EDIT:

I wish I could upload the custom library, but I'm gettin an error stating that its content type does no match its file extension for some reason...sorry about that. 

[Mark.Lancaster]

@PremTM 

I'm a little confused here..  I don't see in your part, an iPart table structure to adjust to different fastener sizes and length..   So how do you expect autodrop to work if it can't detect the different fastener sizes and lengths that you are going to permit?   Or did you think it did it automatically by just modeling one variation of it?   Update:  Or perhaps you added that stuff to the related family table but you should also publish from an iPart table structure part file.

 Also how do you put this hardware into your part in real life when you there's no such feature in the model to "screw" the fastener into your plate ?  Or are you just keeping it simplified?   And finally when dealing with fasteners I've had better success with autodrop and bolted connection by taking a provided content center fasteners that's already there and "tweaking" it to meet your requirements.

In addition when posting (and sharing files) make sure to include what Inventor version you are using..  In your case its Inventor 2019 RTM..   You are using a version that's not the latest and I would recommend that you upgrade to the latest 2019 version

[Mark.Lancaster]

@PremTM 

I'm a little confused here..  I don't see in your part, an iPart table structure to adjust to different fastener sizes and length..   So how do you expect autodrop to work if it can't detect the different fastener sizes and lengths that you are going to permit?   Or did you think it did it automatically by just modeling one variation of it?   Update:  Or perhaps you added that stuff to the related family table but you should also publish from an iPart table structure part file.

 Also how do you put this hardware into your part in real life when you there's no such feature in the model to "screw" the fastener into your plate ?  Or are you just keeping it simplified?   And finally when dealing with fasteners I've had better success with autodrop and bolted connection by taking a provided content center fasteners that's already there and "tweaking" it to meet your requirements.

In addition when posting (and sharing files) make sure to include what Inventor version you are using..  In your case its Inventor 2019 RTM..   You are using a version that's not the latest and I would recommend that you upgrade to the latest 2019 version

[PremTM]

Hi Mark.

I'm keeping it quite simple here. There's no need for multiple possibilities to pick from. As long as there's a single item that matches an existing hole the autodrop tool will work just fine.

All I'm doing here to test it is:

1. Create a custom test library

2. Create a simple custom screw in one .ipt file

3. Create a simple plate with a hole matching the screw (same nominal diameter, matching thread)

4. Author the screw as part of Fasteners -> Screwes -> "Other" OR "Hex head screwes" OR "Round head screwes" (3 separate authors)

4. Publish all those instances

In the end I have a custom library with 3 separate instances of the same screw in 3 different family tables (it could be 3 completely different screws, doesn't matter). Now, inserting instances published as parts of Hex head and Round head screw families into an assembly with provided plate already grounded works fine - auto drop works, the screw gets placed and constrained correctly. But the screw published as part of "Other" family table causes a thread error, diables auto drop but in the end can be placed in the 3d space, only THEN constrained and there doesn't seem to be anything else wrong with it. 

I'm just trying to figure out what is wrong with publishing fasteners as part of "Other" family. All the neccessary thread parameters are the same, the original part is the same, yet this one family yields unexpected behaviour.

[PremTM]

Hi Mark.

I'm keeping it quite simple here. There's no need for multiple possibilities to pick from. As long as there's a single item that matches an existing hole the autodrop tool will work just fine.

All I'm doing here to test it is:

1. Create a custom test library

2. Create a simple custom screw in one .ipt file

3. Create a simple plate with a hole matching the screw (same nominal diameter, matching thread)

4. Author the screw as part of Fasteners -> Screwes -> "Other" OR "Hex head screwes" OR "Round head screwes" (3 separate authors)

4. Publish all those instances

In the end I have a custom library with 3 separate instances of the same screw in 3 different family tables (it could be 3 completely different screws, doesn't matter). Now, inserting instances published as parts of Hex head and Round head screw families into an assembly with provided plate already grounded works fine - auto drop works, the screw gets placed and constrained correctly. But the screw published as part of "Other" family table causes a thread error, diables auto drop but in the end can be placed in the 3d space, only THEN constrained and there doesn't seem to be anything else wrong with it. 

I'm just trying to figure out what is wrong with publishing fasteners as part of "Other" family. All the neccessary thread parameters are the same, the original part is the same, yet this one family yields unexpected behaviour.

[jan_priban]

Hi PremTM,

I can tell why it happens while I do not know why. When you open family table of your published screw,

you will see there are errors in Thread Designation cell + other

even thought mapping during Authorization/Publish looks OK

I think all your 3 families (published into various 3 bolt categories) shows such error. I think you published all of them with the same folder/file name, which means 1 place from first family show Thread error but create instance anyway. Place from 2nd/3rd family founds already existing folder/file name and place it from cache = taking already created IPT with already set thread - set by family template (original My_Screw.ipt). When there is an error for Thread setting during creating instance from CC, thread from template is used. Template in this case is your My_Screw.ipt 

But what I do not understand 100%: When I made data correction using CC editor for the cells Thread Class, Thread Designation, I am still getting Thread Error when creating instance from CC (by Place from CC or Open from CC). I would suppose smooth placing, when data corrected manually

I need to show your finding to development. Thank you for reporting this.

Regards

Jan Priban

[jan_priban]

Hi PremTM,

I can tell why it happens while I do not know why. When you open family table of your published screw,

you will see there are errors in Thread Designation cell + other

even thought mapping during Authorization/Publish looks OK

I think all your 3 families (published into various 3 bolt categories) shows such error. I think you published all of them with the same folder/file name, which means 1 place from first family show Thread error but create instance anyway. Place from 2nd/3rd family founds already existing folder/file name and place it from cache = taking already created IPT with already set thread - set by family template (original My_Screw.ipt). When there is an error for Thread setting during creating instance from CC, thread from template is used. Template in this case is your My_Screw.ipt 

But what I do not understand 100%: When I made data correction using CC editor for the cells Thread Class, Thread Designation, I am still getting Thread Error when creating instance from CC (by Place from CC or Open from CC). I would suppose smooth placing, when data corrected manually

I need to show your finding to development. Thank you for reporting this.

Regards

Jan Priban

[PremTM]

Hello jan.priban

Thank you for taking a look into this issue. You were right, all of the family tables have been populated with wrong data.

I'm not sure why though. I'm following a Mastering Inventor book on this one and among steps undertaken in order to generate this CC part is populating the required fields of the familty table with data, which in turn is being pulled directly from features (such as thread) present in the .ipt file. Do you know why in the end the table is being populated with wrong data? I mean, there's hardly any room for error, I've tried this a few times, using both ANSI templates and ISO templates and results are the same.

Best regards,

Tom

[PremTM]

Hello jan.priban

Thank you for taking a look into this issue. You were right, all of the family tables have been populated with wrong data.

I'm not sure why though. I'm following a Mastering Inventor book on this one and among steps undertaken in order to generate this CC part is populating the required fields of the familty table with data, which in turn is being pulled directly from features (such as thread) present in the .ipt file. Do you know why in the end the table is being populated with wrong data? I mean, there's hardly any room for error, I've tried this a few times, using both ANSI templates and ISO templates and results are the same.

Best regards,

Tom

[PremTM · Accepted solution]

I'm sorry for the double post, but I've sat down to try and crack it once again.

Here's another route I've chosen this time and it (almost) works:

1. Create a custom CC library and copy a full category structure of an item you want to add to that library.

2. Create your fastener in .ipt file

3. Make your fastener .ipt file an iPart factory, even if it is supposed to have just 1 item in it. You have to add required thread parameters to the iPart table (in case of round head screw for example that'd be: class, designation and type)

4. Authorize the iPart factory (Manage -> Author ->Component). Choose iMates, link to all required cells, finish.

5. Publish iPart.

Now about that "almost" part...This route changes the family table contents. In the case of round head screw (which i'm testing now) there seems to be no way of adding a thread pitch to the parameter list. There's no option of adding it to the iPart table and it's gone from the family table parameters when you author the iPart. 

The upside is that it properly links all the parameters, the thread error upon placing the part in assembly is gone and auto drop works just fine with one exception - it doesn't recognize the pitch so it allows for mating with a hole having all the right parameters except for wrong pitch. 

Sadly i don't know how to add and properly link pitch in this case. I'm guessing there may also be a problem with "Authorize a component"/"publish" tool in case of normal part files, it just won't link the proper thread parameters to family table for some reason and due to that thread error occurs later on.

[PremTM · Accepted solution]

I'm sorry for the double post, but I've sat down to try and crack it once again.

Here's another route I've chosen this time and it (almost) works:

1. Create a custom CC library and copy a full category structure of an item you want to add to that library.

2. Create your fastener in .ipt file

3. Make your fastener .ipt file an iPart factory, even if it is supposed to have just 1 item in it. You have to add required thread parameters to the iPart table (in case of round head screw for example that'd be: class, designation and type)

4. Authorize the iPart factory (Manage -> Author ->Component). Choose iMates, link to all required cells, finish.

5. Publish iPart.

Now about that "almost" part...This route changes the family table contents. In the case of round head screw (which i'm testing now) there seems to be no way of adding a thread pitch to the parameter list. There's no option of adding it to the iPart table and it's gone from the family table parameters when you author the iPart. 

The upside is that it properly links all the parameters, the thread error upon placing the part in assembly is gone and auto drop works just fine with one exception - it doesn't recognize the pitch so it allows for mating with a hole having all the right parameters except for wrong pitch. 

Sadly i don't know how to add and properly link pitch in this case. I'm guessing there may also be a problem with "Authorize a component"/"publish" tool in case of normal part files, it just won't link the proper thread parameters to family table for some reason and due to that thread error occurs later on.

[jan_priban · Accepted solution]

Hello,

 sorry I did not mention before - publish iPart is much better way than publish plane part. So let talk about iPart. When you specify variables/parameters ( they alternate ) in iPart table, see plese there is tab Thread. There you can specify thread properties like Designation, Class, Pitch. So recommended steps

1. Verify iPart table work for all (most) rows, all (most) iPart member can be set up (mainly thread)

2. Authorize and Publish part - map thread properties

3. Verify family table using CC Editor - focus on thread properties

4. Create instance - place from CC, Open from CC

Hope it is clear now

Thank you for participation and please let us know how you iPart/CC_family works.

regards

Jan Priban

CC family tableParameters (user defined)iPart table

[jan_priban · Accepted solution]

Hello,

 sorry I did not mention before - publish iPart is much better way than publish plane part. So let talk about iPart. When you specify variables/parameters ( they alternate ) in iPart table, see plese there is tab Thread. There you can specify thread properties like Designation, Class, Pitch. So recommended steps

1. Verify iPart table work for all (most) rows, all (most) iPart member can be set up (mainly thread)

2. Authorize and Publish part - map thread properties

3. Verify family table using CC Editor - focus on thread properties

4. Create instance - place from CC, Open from CC

Hope it is clear now

Thank you for participation and please let us know how you iPart/CC_family works.

regards

Jan Priban

CC family tableParameters (user defined)iPart table

[PremTM]

That's exactly what I did, but now that I've repeated it and made a proper iPart factory with several members I've realised it just pushes the pitch into thread designation, so in essence for threaded iParts it's sort of hidden and driven by changes made to thread designation. Don't know why it has to differ but it's OK, it works.

Thanks for your input,

Cheers!

[PremTM]

That's exactly what I did, but now that I've repeated it and made a proper iPart factory with several members I've realised it just pushes the pitch into thread designation, so in essence for threaded iParts it's sort of hidden and driven by changes made to thread designation. Don't know why it has to differ but it's OK, it works.

Thanks for your input,

Cheers!