iLogic Rule Trouble with CC Parts

[jtylerbc]

I'm running into some trouble with what (I think) should be a pretty simple and straightforward rule.  On our steel fabrication drawings, we add an "(SK) to the end of the description for any plate, tube, etc. that has a dimensioned drawing view (a "sketch" of the part).  For example, a 5x5 plate that has a detailed drawing view would have a description something like this:

PL 5" x 5" (SK)

The "SK" note itself is a custom iProperty embedded in the description, so that the Description property is actually an expression like:

=PL <WIDTH> X <LENGTH> <SK>

I have a series of iLogic rules in the part that detects most cases when the note is going to be needed, based on our standards and the features used in the model.  For cases that rule doesn't catch, I am trying to develop a rule in the drawing which will fill out the SK property for any part which has a view in that drawing.  It is this final-catch rule that I'm having an issue with.

The issue is essentially that the rule fails and gives an error message of "Object reference not set to an instance of an object." if any of the parts in the drawing come from Content Center (usually frame generator steel shapes).  Can anyone give me some idea of what the problem could be?  Code is below.

' This rule adds the SK mark for all parts referenced by a view in this drawing.

oDoc = ThisDoc.Document

For Each oView In oDoc.ActiveSheet.DrawingViews
	' Retrieve the name of the model referenced by the view.
	ModelDoc = ActiveSheet.View(oView.Name).ModelDocument
	
	If ModelDoc.DocumentType = kPartDocumentObject Then
		' Fill in the SK property for the referenced model
		iProperties.Value(ModelDoc.displayname, "Custom", "SK") = "(SK)"
	End If

Next

iLogicVb.UpdateWhenDone = True

[Anonymous]

Maybe you could try something like this to get all the referenced parts:

Dim oDrawDoc As DrawingDocument, oDoc As Document
oDrawDoc = ThisDoc.Document

For Each oDoc In oDrawDoc.AllReferencedDocuments
	If oDoc.DocumentType = kPartDocumentObject Then
		'do some stuff
	End If
Next

Good luck! 

[jtylerbc]

Jasper,

That's almost exactly the original version of my code (my posted version is the second attempt).  The way you have it written using "AllReferencedDocuments", if there is a view of an assembly on the drawing, all parts included in that assembly get the SK mark.

This result is incorrect for what I am trying to do.  Only the parts that are referenced by a view on the drawing should get the mark.

My first version of the rule used that technique, and populated a huge assembly with unwanted SK marks.  I spent half a day cleaning it up.

[Anonymous]

Hmm... last thing I can think of is inserting a check of the location of the part file, before attempting to change an iProperty.

First, I would try changing this

ModelDoc = ActiveSheet.View(oView.Name).ModelDocument

 to this

ModelDoc = oView.ModelDocument

 That should work, and it's a little shorter, which is always a good thing 😉

Next, you could try using PartDocument.GetLocationFoundIn() to get the type of location:

Dim strLocName, strLocType As String
oPartDoc.GetLocationFoundIn(strLocName, strLocType)

If Not strLocType = kLibraryLocation Then
     'Not a CC file!
End If

 Both string arguments are output strings. The value of the second string comes from the LocationTypeEnum enumerator. Keep in mind, I haven't tested this. You should try it on a small assembly first 😉

[jtylerbc]

Checking the part file location won't help.  The CC files in question are steel shapes, often (but not always) placed by Frame Generator.  So, they are all placed "As Custom", rather than being in the library folders. 

Also, just to clarify, I don't want the rule to skip the CC files.  I want to fix the fact that the rule doesn't work on them.  If skipping them were OK, I could just work around the problem with "Try / Catch", which I've done in a couple of cases. 

[Anonymous]

Okay, final try:

Dim oDrawDoc As DrawingDocument
oDrawDoc = ThisDoc.Document

Dim oDoc As Document, oView As DrawingView
Dim oPropSet As PropertySet, oProp As Inventor.Property

For Each oView In oDrawDoc.ActiveSheet.DrawingViews
	oDoc = oView.ReferencedDocumentDescriptor.ReferencedDocument
	
	If oDoc.DocumentType = kPartDocumentObject Then
		oPropSet = oDoc.PropertySets("Inventor User Defined Properties")
		Try
			oProp = oPropSet("SK")
		Catch
			oProp = oPropSet.Add("","SK")
		End Try
		oProp.Value = "(SK)"
	End If
Next

 This worked like a charm for me, including custom CC files. I haven't been able to find the ModelDocument property in any documentation, so I replaced it with DrawingView.ReferencedDocumentDescriptor.ReferencedDocument, which returns the document associated with the view. After the part document check is passed, a reference to the 'Inventor User Defined Properties' property set is defined, which are the custom iProperties. Next, the code attempts to set a reference to a property called 'SK'. If this fails, the property is added to the propertyset, with a zero-string value. Finally, the property value is set to '(SK)'.

Hope this helps!

[Vladimir.Ananyev]

If you need to identify Content Center components this post could help you.

All they have specific PropertySet and properties (FamilyId, MemberId).

Getting data from Content Center

http://modthemachine.typepad.com/my_weblog/2012/02/getting-data-from-content-center.html

cheers

[jtylerbc]

Some additional information - this may be more related to Frame Generator than to the Content Center itself.  Although I have heard reports from some of my other users that may contradict this, what I have personally observed is that manually placed CC steel shapes do not set off the error.  Components created by the Frame Generator do.

Does Frame Generator do something odd to iProperties that I need to get around somehow?

[Vladimir.Ananyev]

DocumentInterests object could be used to identify FG documents.

This method is described here: 

Identify parts created by Frame Generator with DocumentInterests object

http://adndevblog.typepad.com/manufacturing/2012/08/identify-parts-created-by-frame-generator-with-d...

[jtylerbc]

---

@Vladimir.Ananyev wrote:

DocumentInterests object could be used to identify FG documents.

This method is described here: 

Identify parts created by Frame Generator with DocumentInterests object

http://adndevblog.typepad.com/manufacturing/2012/08/identify-parts-created-by-frame-generator-with-d...

---

Once I have identified them, what would I do with them then to fix the original problem?  Again, note that I'm not trying to skip the FG parts to avoid the error message.  I'm trying to fix the rule so that it works properly on FG parts.

[adam.nagy · Accepted solution]

Hi John,

I'm actually surprised that the 3 input parameter version of iProperties.Value() works for any of the part documents for you from inside your rule residing in a drawing, since the function help says when you hover above it in the iLogic function tree: "Get or Set iProperties values in components from an assembly level rule. Use the component name."

Instead, you could use the Inventor API. This seems to work fine for me even for a frame generator part.

oDoc = ThisDoc.Document

For Each oView In oDoc.ActiveSheet.DrawingViews
	' Retrieve the name of the model referenced by the view.
	ModelDoc = ActiveSheet.View(oView.Name).ModelDocument
	
	'MsgBox(ModelDoc.displayName)
	If ModelDoc.DocumentType = kPartDocumentObject Then
		' Fill in the SK property for the referenced model
		'iProperties.Value(ModelDoc.displayname, "Custom", "SK") = "(SK)"
		ModelDoc.PropertySets("{D5CDD505-2E9C-101B-9397-08002B2CF9AE}")("SK").Expression = "(SK)"
	End If
Next

iLogicVb.UpdateWhenDone = True

Cheers,

[jtylerbc]

Adam,

That sounds promising, but running it gives me an error:

Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))

Any idea what's going on with that?

[jtylerbc]

Okay, some strangeness here - the trouble I had with Adam's revised rule seems to have been related to copying and pasting it off the forums.  One of my coworkers was helping me troubleshoot this, and he copied the "{D5CDD505-2E9C-101B-9397-08002B2CF9AE}" in directly from the programming help files, and now everything seems to be working.

Thanks for the help - as simple of a thing as this sounds like, it's actually going to save us a ton of time vs. entering these manually.