JointTransfer in COM API

[dirvine_behlen_ca]

I am puzzling a bit over the consequences of using JointTransfer objects with in COM API joints in Advance Steel. Take as an example, I have joint A which outputs a few shortenings and a couple of stiffeners. The stiffeners are identical in this case, although for the purposes of the job we were doing, they needed to get unique part marks. After numbering, the marks are unique as per requirement on this job. Then the joint gets updated (perhaps accidentally). The numbering on stiffener 1 got applied to both stiffeners. So, I made a change to the joint so that each of the stiffeners got joint transfer objects applied to them. I happened to use the same name for the joint transfers but it helped the result so that the output correctly brought over the properties from the previous versions of the created objects over to the new set of created objects.

However, applying the same principle to other joints has not given good results. I have a joint that creates two end plates. Ideally, I would like to create them both as Endplate model roles. I found that if I did this, I was getting part name clobbering after numbering followed by joint update. I changed to Endplate and a new model role End Plate 2 and this fixed that problem. I thought I would try adding joint transfers to the joint to see what would happen. So, the end plates and the gusset each get a unique joint transfer object. I find in this case that the part names no longer propagate. If the parts are numbered and the joint is updated, now the parts are no longer numbered. Note that both the JointTransfer and Role objects had (sim. for Role).

Dim jt As JointTransfer = ActiveJoint.CreateJointTransfer(name)
jt.Attribute(eAttributeCodes.kPlateCoating) = 1
jt.Attribute(eAttributeCodes.kPlateMaterial) = 1
jt.Attribute(eAttributeCodes.kPlateSinglePartNumber) = 1
jt.Attribute(eAttributeCodes.kPlateSinglePartPrefix) = 1
jt.Attribute(eAttributeCodes.kPlateRole) = 1
jt.Attribute(eAttributeCodes.kPlateAssembly) = 1
jt.Attribute(eAttributeCodes.kPlateNote) = 1
jt.Attribute(eAttributeCodes.kPlateDenotation) = 0
jt.Attribute(eAttributeCodes.kPlateItemNumber) = 1
jt.Attribute(eAttributeCodes.kPlateSinglePartDetailStyle) = 1
jt.Attribute(eAttributeCodes.kPlateStructuralMember) = 1
jt.Attribute(eAttributeCodes.kPlateMainPartDetailStyle) = 1
jt.Attribute(eAttributeCodes.kPlateMainPartNumber) = 1
jt.Attribute(eAttributeCodes.kPlateMainPartPrefix) = 1
jt.Attribute(eAttributeCodes.kPlateMPExplicitQuantity) = 1
jt.Attribute(eAttributeCodes.kPlateSPExplicitQuantity) = 1
jt.Attribute(eAttributeCodes.kPlateMPUsedForNumbering) = 1
jt.Attribute(eAttributeCodes.kPlateSPUsedForNumbering) = 1
jt.Attribute(eAttributeCodes.kHolePatternType) = 1
jt.Attribute(eAttributeCodes.kBoltPatternHoleTypeForEachConnObject) = 1
jt.Attribute(eAttributeCodes.kLevel) = 1

I have gone back to using just the separate model role objects and not using the JointTransfer. Am I supposed to be able to call both end plates of model role "Endplate" even when the geometry is different and use the JointTransfer to bring the part marks across from instance to instance?

[bogdan.vacut · Accepted solution]

Hi,

JointTransfer is only needed if you want to let the model role property of the objects created by the joint to be editable.

If you are good with it being read-only in the properties dialog, you can use the model role mechanism.

If you know the geometry is different between the 2 end plates use as name for the model role(or ID for JointTransfer) "EndPlate#1" and "EndPlate#2" and so on (this is what we do for our joints). Now the part marks will be transferred on update from old "EndPlate#1" to the new "EndPlate#1" and from old "EndPlate#2" to the new "EndPlate#2".

[dirvine_behlen_ca]

I'm not really sure what I did wrong before, but this seems to work okay. I must have something that isn't obvious to me wrong with my shortcut.