'Custom Properties - Model' - changing order of placed views?

[Nik_Barbour]

Hey all,

I was wondering if anyone could help me out with a regular issue I have as an Admin, with a problem experienced by my CAD users.

Within the drawing titleblock we have a 'Text' of type 'Custom Properties - Model' which pulls in a custom iprop from a model which is the models finished weight. This is a common way of autopopulating titlebox entries.

The problem is that the sheet populates the text with the info related to the first viewport placed upon the drawing.

Whilst fine when planned for properly, I quite often encounter upon large multisheet detail drawings, that a user when detailing an IAM, will have forgotten to put the IAM view down first, especially later in the drawing series where the IAM is not required and the user is detailing IPT's.

What I am looking for is a way to change which viewport the border properties are releated to idealy, so that if a user has forgotten to place the IAM but has placed 20 IPT's down, I could place an IAM outside of the maximum area, as the 21st object but fool Inventor into thinking this was the first viewport placed down, thus populating the border info correctly.

I don't know of a way to do this currently, either with current Inventor functionality, or by programatic approach - our current fix is to have the user create another drawing sheet, place the IAM outside the maximum area, copy all his IPT viewports across from the first sheet, then delete the first sheet.

Is it possible to change the object order of placed viewports with less disruption?

Thanks in advance for any help or advice.

[yannicknielsen]

Is it a custom iProperty created by ilogic?

A simple fix would be to make a similar ilogic code for parts, but make it create a custom iProperty with a slightly different name

[Nik_Barbour]

Thanks for the reply.

No, it is a custom iprop within our drawing border template.

I've had communications with Pierre Masson from Autodesk, re this matter the past couple of days and to quote one of his responses from an email

" I understand the need now. It's not that easy.

It's hardcoded in Inventor that if you use a custom Model Iproperty, it takes the first view placed."

I was hoping there may have been a vba workaround which might have fooled Inventor into knowing which was the first view placed, by manipulating the viewports object data.

Pierre is currently attempting a workaround via ilogic, where the user selects a view they wish to be the one used for iprop population. The ilogic then creates an additional drawing sheet, and moves all other viewports to this new sheet, then copies them back to the orig sheet. Thus making the selected viewport the first one placed.

But... trying to automate this is causing problems with projected views being broken and replaced with view arrows, and some dimensions getting corrupted in regards their spacing and placement.

Thanks again.

[yannicknielsen]

I'd imagine that it'd require some

If the file is .iam

then do this

Else if the file is .ipt

then do this

end if

[cwhetten]

This is an interesting question.  Please post back if you hear any more from the folks at Autodesk.

Cameron Whetten
Inventor 2014

[Nik_Barbour]

Update so far -

Pierre Masson wrote and provided the following ilogic code...

-------------------------------------------------

Dim oSSet As SelectSet = ThisDoc.Document.SelectSet
If oSSet.count = 0 Then
　　　 MessageBox.Show("You must select a drawing view first", "iLogic")
Exit Sub
End If

'Reference to the drawing view from the 1st selected object
Dim oView As DrawingView = trycast(oSSet.item(1), DrawingView)

If oView IsNot Nothing Then
　　　 Dim osheet, oNewSheet As Sheet
　　　 osheet = oView.Parent
　　　 Dim oDoc As DrawingDocument
　　　 oDoc = osheet.Parent
　　　
　　　 ' Wrapping activities in a transaction so the
　　　 ' entire process can be undone with a single undo operation.
　　　 Dim trans As Transaction
　　　 trans = ThisApplication.TransactionManager.StartTransaction(oDoc, "Move First View")
　　　
　　　 'add a new sheet and copy all drawing views there
　　　 oNewSheet = oDoc.Sheets.Add
　　　 Call oView.MoveTo(oNewSheet)
　　　
　　　 For Each oOtherView In osheet.DrawingViews
　　　 　　　 　　　 Call oOtherView.MoveTo(oNewSheet)　　　 　　　 　　　
　　　 Next
　　　
　　　 'Copy back the views to original sheet and delete the new sheet created
　　　 For Each oOtherView In oNewSheet.DrawingViews
　　　 　　　 Call oOtherView.MoveTo(osheet)
　　　 Next
　　　
　　　 Call oNewSheet.Delete
　　　 Call osheet.Update
　　　
　　　 trans.End

Else
　　　 MessageBox.Show("The selected object is not a drawing view", "iLogic")
End If

-------------------------------------------------

To use this, on an IDW with multiple viewports placed, select the viewport you wish to be the first placed (thus populating the 'Custom Properties - Model' info on the drawing border. Run the above rule.

The ilogic will create another temporary drawing sheet and copy all but the selected view to this new sheet, then copy them all back to the original sheet.

On simple drawings this will work, moving views which have projected views off them results in the projected view alignments being broken and replaced with view indicator arrows (selective selection of master views and projected views in one selection isn't possible, the ilogic performs a 'for each' approach).

Also some views once returned to the original sheet had dimension placement moved and thus required extensive re-work to correct.

Summary - manually creating an additional sheet, and manually and selectively moving grouped sets of projected views is quicker and more reliable than using the above automated approach.

Pierre's next suggestion I found rather interesting, but unfortunately flawed with further testing.

To quote Pierre

"I'm thinking about another possible workflow :

• Create a custom symbol with the Model property Netweight in it
• Attach it to the view you want
• Change the title block name to have a unique title block and remove the already existing NetWeight field
• Place the symbol in the title block. Make the leader line on an invisible layer.

See the drawing attached. The leader is on the DIM Layer. The symbol is called NetWeight."

What he suggested was to remove the text populated by 'NetWeight' from the border and instead replace it with an Inventor symbol. This symbol is text again which has the 'Custom Properties - model' 'NetWeight' link but because it is a symbol instead of working off the first placed viewport, it gives the property of whatever the notes leader is attached to (the leader can be made invisible remember).

Downside- after a brief test, I found this technique only works for part files. If you place an IAM viewport and attach the leader, it gives the weight of the part the leader attaches to, not the assy.

So to-date we are left with having to use our existing work around mentioned previously, which is add an extra sheet, move all other views than the one desired to be first manually and carefully in respect to projected views off viewports, then move them all back. - Unless someone can jump in with an idea or some code.

My next steps with this - The company I work for are an Autodesk Enterprise Priority Support customer, so we have regular monthly meets with our assigned Autodesk SAM (Support Account Manager) which are globally attended by my company's CADadmins via Webex, and only last month Autodesk were asking us about potential future development plans we might find benefical. I know its only a minor itch that we have lived with for 10 years now, but I'm tempted to push this forwards.

[nmunro]

It would probably be more efficient to approach it something along the lines of:

Add a textbox to your border definition with some default, known text string. Do not extract the model property information to the textbox.

Write a routine using iLogic or incorporating it in an add-in to find the textbox in the border on the drawing and replace the default text with a string including the extracted model property information. The routine would have to ask the user to select the view for the model definition. You could then attach an attribute to the textbox to provide a key so the textbox can be found when you decide to check for changes to the model property value, perhaps each time the drawing is opened or saved.

Edit:

Simplifying the above, place a reference to a custom drawing property (or unused standard drawing property) in the title block definition. Use the above approach but copy the model property value to the selected drawing property.

Neil

[Nik_Barbour]

I appreciate the suggestion, but these wouldn't update dynamically if the model changes.
They would require the user to run a program or rule.

It seems it's not currently possible to change the object order of the viewports programmatically, so I have logged this as a wish item with Autodesk as a possible future development.

[nmunro]

It would be very easy to include automatic updates to the property value. Yes, it would be nice if it was a built in function but you may be waiting a while before it is included.

[jcox150]

First... if you're detailing a .iam, why would you then detail an .ipt on the same dwg? that just creates all kinds of room for errors. thats why they have detail views, section views and representation views... that would solve your problem.

[Nik_Barbour]

We typically produce 10 sheets or thereabouts for an assembly drawing. We are typically detailing welded fabrications. So sheet 1 thro 4 will be various views of the iam file (ballooned / weld spec'd and sectioned for clarity), but then we require a seperate detail view of each individual ipt of which the assy comprises, so each item of the iam is detailed as a seperate ipt over sheets 5 thro 10 on the idw.

The shapes we create are highly toleranced, and couldn't satisfactorily be dimensionally represented detailing only the iam views.

This is a standard practice for any complex multibody iam. I have used the same practice at various other companies, and for other component types.

[Scott_Stubbington]

Hello,

If you create a new drawing with the pertinent view created to flush the property values through to the Titleblock, could you then copy the existing sheets from the incorrect drawing to the new drawing and save over the top of the existing drawing?

Random thought. 🙂

Scott

[Nik_Barbour]

Yeah - we use a similar method to fix them currently when done incorrectly, but we create an extra sheet, move the first view to populate, then bulk move all other sheet views (so projections are maintained), delete the old sheet, then move the new sheet to the old sheets location.
If you look back in the thread (post 6) there is an ilogic rule which attempted to automate this, but it broke projections in its automated approach. Thanks for the suggestion though.

[jcox150]

Yes, I understand the need to detail ipts. But you can do the same thing directly through the iam using view representation, which will keep the Integrity of the bom and resolve any other issues that you are having with linking to the iams iproperties. I know old habits die hard.. Just a thought.

[Curtis_Waguespack]

Hi Nik_Barbou,

I just skimmed this thread, so I might have missed something important, but it sounds like that if you use the Weldment drawing tools to detail the parts, it might be helpful. Please have a look at the beginning of the article at this link that reviews the weldment model state tab tools to see if that helps. Just ignore the frame generator information if that part is not applicable to your situation.

http://inventortrenches.blogspot.com/2011/03/detailing-frame-generator-weldment.html

Please disregard if this doens't help.

Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[Nik_Barbour]

Thanks - it is a good suggestion, and I do appreciate it.
The assemblys we are working with consist of hundreds of plates though, so it would be a not inconsiderable effort to create a view rep for each plate.
We do currently use view reps for sub-assembly representation, where a handful of the plates require pre-assembly, prior to main.
Thanks again though.

[Nik_Barbour]

Hey Curtis,
Although not a solution for this problem as you stated, that is really interesting and definitely useful.
I had no idea that was an option in weldments (although it makes sense of the bom change warning now).

Thanks - I will definitely use that in the future for other smaller projects.

[jcox150]

maybe this has already been suggested... but havce you just used the "Document Settins" "Drawing" and changing the custom iproperties source? seems to resolve it pretty easily... of course you have to "update copied properties" in the Manage tab after...

just a thought..

[Nik_Barbour]

Hey jcox,

Tried your suggestion but I couldn't get it to work, I don't know if I'm missing something.

I created a sample case for testing as described here...

Firstly I drew 2 component .ipt files.

One called SQUARE.IPT, with 5 of our companys standard 'Custom iprop' values, and also 3 unique 'custom iprop' values named A,B & C.

Secondly one called CIRCLE.IPT, again with the same 5 standard company 'custom iprops', and again 3 unique 'custom iprop' values this time named D,E & F.

These are shown in the clips below.

I then created a new drawing sheet .idw file. The first item view placed was square.ipt, the second placed was circle.ipt.

The border populates with the info for the first placed view square.ipt. In particular - border box 'estimated weight' which is populated by the 'custom iprop' 'NetWeight' from the first placed view (square.ipt) so it equals 10.

I then went into 'Tools' 'Document Settings' 'Drawing' and under 'properties in drawing' I added an 'additional custom model iproperty source' where I browsed circle.ipt. (This is whatI understood your suggestion to be)

The estimated weight figure did not change to circle.ipt netweight value. The reason I believe being that these are (as the title describes) additional iprop sources, not replacement iprop sources.

I believe this was confirmed when I edited the title block to look at the model iproperties now available to the border since adding the additional iprops source. (see clip below)

What appears to have happened is that, unique custom iprops are added to the cumulative custom iprop list, but where a non-unique cutom iprop is encountered, the first placed item still has precedence. Therefore the first placed custom iprop netweight value of 10, still overides the second placed item (the value of which is 20).

Is the the same workflow that you followed? Did you get a different outcome to the above example?