Using ilogic in content center parts

[asiteur]

Hi guys,

For a customer I am creating content center families and so far I have done that by using only 'basic' part functionality to ensure its working.

However, now I sort of see myself forced to embed some iLogic into it to handle the suppression of features in rather complicated situations.

As I figured it is some sort of iPart, I didn't really dare to use iLogic so far.

Does anyone have experience using iLogic in CC families? Does it work well? Any limitations?

I did some preliminary checks and it seems to work fine, but I can't afford finding out during the final tests that the two don't work together...

[Mark.Lancaster]

@asiteur

I would recommend that you don't do that..  Content center information was developed so many years ago before even iLogic came to the market.  I don't have any experience in it because I would never suggest doing it due to how true content center parts work.  Anyhow my 2 cents.. 

[jtylerbc]

I do it without any real problems, but the iLogic code in mine doesn't control the model in any way.  It is a rule in our structural steel parts that replaces Frame Generator's built-in member length tracking with a measured extents of the final part.  It's far more reliable than FG, and gives the same resulting final length regardless of how the part was actually created (trim/notch order, etc.).

We did have some difficulties with the way the code was originally written - it would work on test parts that had already been placed, but would break when the code was actually placed in the CC family template.  This was several years ago, so I don't remember the details of exactly what was wrong with it.  The fix was either a minor rewrite in code, changing the Event Triggers to not use the "New Document" trigger, or both. 

In short, there may be some quirks to it here and there, but it's definitely possible to use at least some iLogic in Content Center parts.

[bradeneuropeArthur]

As already said, also my opinion is to don't do it.
I logic is not meant for that.
And content center is also not meant for that.

Before you run into bigger problems later, over think it again.

The better way is to use external coding like an add in to achieve what you need.

[asiteur]

Thank you all for your advise.

I've been trying to find a solution without iLogic and I think I found one.

Nevertheless if I have some spare time I will try to see what iLogic does to CC parts in the long term.

[MechMachineMan]

My assumption would be that it would start throwing errors very quick seeing as STANDARD content center parts are always put in a protected location.

The only 2 ways I could see it working are:

1. The parts are only ever placed as custom content.

2. The iLogic rule actually initializes and works in a new instance of inventor, then moves files into the library location over existing files before closing the new working copy of inventor. Although, with the _ApplicationModifiable call, it might be possible to do this inside the same instance of inventor.

[jtylerbc]

---

@MechMachineMan wrote:

1. The parts are only ever placed as custom content.

---

I would add to this the fact that my example of successfully using iLogic in Content Center is based entirely on structural steel parts, which place as custom by default.  I agree completely that placing parts that contain iLogic as "Standard" will result in a ton of errors and probably will not give you the results you're looking for.  Of course, as with my structural steel, if this is something that needs to be placed as custom anyway then the issue takes care of itself.

@asiteur, have you considered whether or not this really even needs to be done in Content Center?  Perhaps just a custom iPart would be a better solution?

[Anonymous]

I did it recently and I think it works. As mentioned earlier the way the code is written has a lot to say and the way the triggers are set up also is important. Could you provide an example of what would you like to achive?

[bradeneuropeArthur]

Hi,

Still my advice is to don't do it regarding the future of Inventor.

When you need to migrate the CC families and parts from release to release than you may have a problem.

But I am not sure about the mechanism you use.

• Are you putting I-logic code into all the CC templates in the hidden files on C:\Progamdata... So this means you have build in code that will/can automatically be vanished with a migration.

• Are you using code in the CC parts (Members) then you need to be aware that with the migration process these can directly be updated an remove the i-logic code.

• Or is this a coding that is running only for the CC parts (Members) within Inventor.

I would b e very very carefull with it.

Regards,

[Anonymous]

I tend to agree for the sacke of as few headakes ass possible, keep ilogic away from CC.  As I am not fully aware of the challenges down the road, some of which were mentioned, I can try explain the method I used:

1. Create a part with user paramters carefully defined.

2. Create ipart with one row.

3. Create ilogic rule, that will go  through an array and select the appropriate standard length based on the users input.

feks the user enter a value A the ilogic calculates the total length B and picks the closest standard length C that is appropriate. The description of the part will be defined at the end besed on standard length.

4. Ipart gets published. The custom row is defined for user input.

5. Variants of the part are added as per standard, and  columns, as designation and file name adjusted as needed. 

6. User picks the family, then member, then the user is propted to enter a value. Value entered, the ilogic code picks the closest standard length and adds am appropriate description.

The trouble is, upon placing part into assembly everything seams to work fine. Opening the part from content center returns a bunch of errors regarding null reference. Once the errors is are cleared the part loads correctly. Something is fishy thats for sure. If this would be done outside CC it would be no problem.

iLogicVb.UpdateWhenDone = True
ThisApplication.ActiveView.Update()
ThisApplication.[_LibraryDocumentModifiable] = True

MultiValue.SetList("THR_L", 10, 12, 14, 16, 18, 20, 22, 25, 28, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 95, 100, 110, 120, 130, 140, 150)

Parameter("MTP") = 3
Parameter("L_") = PL_thk +(2*m_)+h_+ MTP

Select Case L_
	
Case <= 10
		THR_L = 10
	Case 10 To 12
		THR_L = 12
	Case 13 To 14
		THR_L = 14
	Case 15 To 16
		THR_L = 16
	Case 17 To 18
		THR_L = 18
	Case 19 To 20
		THR_L = 20
	Case 21 To 22
		THR_L = 22
	Case 23 To 25
		THR_L = 25
	Case 26 To 28
		THR_L = 28
	Case 27 To 30
		THR_L = 30
	Case 31 To 35
		THR_L = 35
	Case 36 To 40
		THR_L = 40
	Case 41 To 45
		THR_L = 45
	Case 46 To 50
		THR_L = 50
	Case 51 To 55
		THR_L = 55
	Case 56 To 60
		THR_L = 60
	Case 61 To 65
		THR_L = 65
	Case 66 To 70
		THR_L = 70
	Case 71 To 75
		THR_L = 75
	Case 76 To 80
		THR_L = 80
	Case 81 To 85
		THR_L = 85
	Case 86 To 90
		THR_L = 90
	Case 91 To 100
		THR_L = 100
	Case 101 To 110
		THR_L = 110
	Case 111 To 120
		THR_L = 120
	Case 121 To 130
		THR_L = 130
	Case 131 To 140
		THR_L = 140
	Case 141 To 150
		THR_L = 150

End Select
'' set description at part level
iProperties.Value("Project", "Description") = Parameter("DESCRIPTION_TXT") &"M"& Parameter("d1_") &"x"& Parameter("THR_L") &" "&"W/2xNUT, 1xWASHER"

iLogicVb.UpdateWhenDone = True
ThisApplication.ActiveView.Update() '' update

[Anonymous]

1. CC part placed in Assembly as standard , no errors description is correct.

2. Open part from CC as Custom, opens correctly renames the file via Vault  naming scheme, description is correct and ilogic rule is available in new part. Part can be used to update family template if necessary changes are required.

One thing to mention, the part number is configured such: <part number>=<member name>-<user entered value>. 

Rule is triggered upon iproperty change and any parameter change.

Any input would be greatly appreciated.