CoCreate User Forum  

Go Back   CoCreate User Forum > Applications > CoCreate Modeling

Reply
 
Thread Tools Search this Thread Rate Thread Display Modes
  #16  
Old 07-15-2009, 08:33 AM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: secondary object of type 'asbm_struct' was missing.

Well, I experimented a litte, and still cannot reproduce precisely what ckrug described. But then, I didn't (and still don't) fully understand the description anyway (hence the questions I asked earlier in the discussion). Maybe you could post a command sequence so that we could see what you did?

That said, just a few notes on instance vs. contents data. Let's assume we have an assembly a1 owning a part p1. If you save this in *.sd* format, you'll get the following files:
  • a1.sda - instance data for a1
  • a1.sdac - contents data for a1, plus instance data of p1
  • p1.sdpc - contents data for p1

Instance data comprise all information which is particular to a given instance of an object. Contents data are common to all instances of the object, i.e. those data are shared. We'll see below what this means in practice.

If you analyse p1.sdpc, you'll notice that nowhere in the file you'll find the name of the part. This is because the part name belongs to the part's instance data, and those are stored with the owning assembly.

Why are instance data stored with the assembly? Well, because they only make sense in that particular assembly. The part p1 might have been shared into some other assembly, and there it might have a completely different name, such as foobar. (Other assembly-relative data for a part include its transformation relative to the owning assembly.)

a1.sdac contains both assembly contents data and instance data for the assembly's children. Originally, those data were actually written into two files, but then it was noticed that the two files could actually be combined without loss of functionality. This simplified file administration somewhat, but makes it a little more difficult to explain the instance/contents concept

Analysing a1.sdac will indeed show you that this file knows about a part called p1.

Setting a "model name" adds an interesting twist - the model name belongs to the contents portion of a part. If you save p1 after setting its model name to, say, wouldtherealp1pleasestandup, a file called wouldtherealp1pleasestandup.sdpc will be created, and in this file you will indeed find the model name wouldtherealp1pleasestandup.

I'd suggest that with this background information in mind, we should step through the complete description of the case and understand what's really happening.
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/
Reply With Quote
  #17  
Old 07-15-2009, 08:55 AM
BMaverick's Avatar
BMaverick BMaverick is offline
Registered User
 
Join Date: Mar 2009
Location: Tennessee, U.S.A.
Posts: 267
Re: secondary object of type 'asbm_struct' was missing.

ckrug, Seems that you got the answer, but still the question of why it happens. I've been dealing with this issue over and over with the legacy data I had inherited. Added to that complexity on my end is a hierarchy of sub-folders six or so deep that mimics the levels of the assembly.

Sounds as if you're only dealing with in in a single folder directory. That can be very helpful to work out the issue. On my end, I have to compare files sizes, file dates and Mi files staying blue.

I've avoided PKG and BDL files altogether. They can cause trouble if one isn't careful.

__________________
Support Your Local Sheriff - At high noon

Jason: "How much does it pay?"
Citizen: "Well, none of our other sheriffs ever lived long enough to find out."

Co-Create 2007 (15.50G)
ANSYS Workbench 14
SolidWorks 2011
UGNX-7.5 / TeamCenter UA 8
PADS 2000
Applicon Bravo
Autotrol
CADAM
Pro/E
Reply With Quote
  #18  
Old 07-15-2009, 09:00 AM
BMaverick's Avatar
BMaverick BMaverick is offline
Registered User
 
Join Date: Mar 2009
Location: Tennessee, U.S.A.
Posts: 267
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by clausb View Post
Well, I experimented a litte, and still cannot reproduce precisely what ckrug described. But then, I didn't (and still don't) fully understand the description anyway (hence the questions I asked earlier in the discussion). Maybe you could post a command sequence so that we could see what you did?

That said, just a few notes on instance vs. contents data. Let's assume we have an assembly a1 owning a part p1. If you save this in *.sd* format, you'll get the following files:
  • a1.sda - instance data for a1
  • a1.sdac - contents data for a1, plus instance data of p1
  • p1.sdpc - contents data for p1
Instance data comprise all information which is particular to a given instance of an object. Contents data are common to all instances of the object, i.e. those data are shared. We'll see below what this means in practice.

If you analyse p1.sdpc, you'll notice that nowhere in the file you'll find the name of the part. This is because the part name belongs to the part's instance data, and those are stored with the owning assembly.

Why are instance data stored with the assembly? Well, because they only make sense in that particular assembly. The part p1 might have been shared into some other assembly, and there it might have a completely different name, such as foobar. (Other assembly-relative data for a part include its transformation relative to the owning assembly.)

a1.sdac contains both assembly contents data and instance data for the assembly's children. Originally, those data were actually written into two files, but then it was noticed that the two files could actually be combined without loss of functionality. This simplified file administration somewhat, but makes it a little more difficult to explain the instance/contents concept

Analysing a1.sdac will indeed show you that this file knows about a part called p1.

Setting a "model name" adds an interesting twist - the model name belongs to the contents portion of a part. If you save p1 after setting its model name to, say, wouldtherealp1pleasestandup, a file called wouldtherealp1pleasestandup.sdpc will be created, and in this file you will indeed find the model name wouldtherealp1pleasestandup.

I'd suggest that with this background information in mind, we should step through the complete description of the case and understand what's really happening.

Thanks for the heads up on this. Great explaination indeed. Without it, I thought that the 3D Data was the original and the Instance was a copy for everything else to use. Guess that isn't the case for the CoCreate understanding.

Why have something saved as 3D Data that can have several names everywhere in different assemblies If part 2134 needs to be used everywhere, then it should be part 2134. Not something out of the blue. BOM and part inventory people would shoot me for not keeping the same component p/n.
__________________
Support Your Local Sheriff - At high noon

Jason: "How much does it pay?"
Citizen: "Well, none of our other sheriffs ever lived long enough to find out."

Co-Create 2007 (15.50G)
ANSYS Workbench 14
SolidWorks 2011
UGNX-7.5 / TeamCenter UA 8
PADS 2000
Applicon Bravo
Autotrol
CADAM
Pro/E
Reply With Quote
  #19  
Old 07-15-2009, 09:13 AM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by BMaverick View Post
Why have something saved as 3D Data that can have several names everywhere in different assemblies If part 2134 needs to be used everywhere, then it should be part 2134. Not something out of the blue.
Let's assume you modeled a wheel and want to use it both in a unicycle and in a bicycle, that we want to share the wheels (rather than reinvent them ), and that all instances, as you suggested, always have the same name:

Code:
  unicycle
  |____ wheel
  |____ ... other parts


  bicycle
  |
  |____ wheel
  |____ wheel
  |____ ... other parts
In such a setup, it is no longer possible to uniquely identify, say, the front wheel of the bicycle.

Quote:
BOM and part inventory people would shoot me for not keeping the same component p/n.
Sure - and I guess this is where the model names come in handy.

Claus
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/
Reply With Quote
  #20  
Old 07-15-2009, 01:41 PM
ckrug ckrug is offline
Registered User
 
Join Date: Sep 2008
Location: Santa Rosa,CA
Posts: 13
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by clausb View Post
Well, I experimented a litte, and still cannot reproduce precisely what ckrug described. But then, I didn't (and still don't) fully understand the description anyway (hence the questions I asked earlier in the discussion). Maybe you could post a command sequence so that we could see what you did?

That said, just a few notes on instance vs. contents data. Let's assume we have an assembly a1 owning a part p1. If you save this in *.sd* format, you'll get the following files:
  • a1.sda - instance data for a1
  • a1.sdac - contents data for a1, plus instance data of p1
  • p1.sdpc - contents data for p1

Instance data comprise all information which is particular to a given instance of an object. Contents data are common to all instances of the object, i.e. those data are shared. We'll see below what this means in practice.

If you analyse p1.sdpc, you'll notice that nowhere in the file you'll find the name of the part. This is because the part name belongs to the part's instance data, and those are stored with the owning assembly.

Why are instance data stored with the assembly? Well, because they only make sense in that particular assembly. The part p1 might have been shared into some other assembly, and there it might have a completely different name, such as foobar. (Other assembly-relative data for a part include its transformation relative to the owning assembly.)

a1.sdac contains both assembly contents data and instance data for the assembly's children. Originally, those data were actually written into two files, but then it was noticed that the two files could actually be combined without loss of functionality. This simplified file administration somewhat, but makes it a little more difficult to explain the instance/contents concept

Analysing a1.sdac will indeed show you that this file knows about a part called p1.

Setting a "model name" adds an interesting twist - the model name belongs to the contents portion of a part. If you save p1 after setting its model name to, say, wouldtherealp1pleasestandup, a file called wouldtherealp1pleasestandup.sdpc will be created, and in this file you will indeed find the model name wouldtherealp1pleasestandup.

I'd suggest that with this background information in mind, we should step through the complete description of the case and understand what's really happening.
Thank you for the thorough explanation of instance and contents files. I already understood 90% of it. I did not know that instance and contents information for assemblies was written out separately in the past. I have save "top level assembly" turned off by default, so I tend not to generate individual instance files for top level assemblies. In most cases I don't need instance files.

I cannot think of a good way to regenerate this problem.

As you request, here is a command sequence (I'll simplify the names a little more then my previous example and add a little more detail about my specific case. The part 1 is actually a small assembly, which I will now call a3) Also, all of the below names are "Model Names" not part or instance names:
- Load a1.sdac (a1 contains a2 which contains a3 which contains p1,p2,etc.)
Here is where I notice that the part number (model name) for a3 is incorrect. Darn. I run a little script in my directory that creates a "where used list" and upon inspection, a3 is only used in a2. So this means I can just change the model name for a3 without breaking any other assemblies.
- Change the "model name" of a3 to a4.
- Save "3D data" for a2.
Everything looks good in the options dialog box.
- Start New Session
- Load a2.sdac
a2 which contains a4 which contains p1,p2,etc are all loaded correctly as expected
- Start New Session
- Load a1.sdac
a1 which contains a2 which contains a3. which contains p1, p2, etc. is loaded incorrectly. a2 should have loaded a4 not a3. Unless there is some share of a3 loaded before a2 is loaded, I don't see how this can happen? I cannot find any shares of a3 outside of a2

As a troubleshooting step, I made a copy (one level only) of a1 and called it a1_copy. When I loaded a1_copy.sdac, it correctly loads a1_copy which contains a2 which contains a4 which cotnains p1, p2,etc. So I have a great solution when I know the problem exists. My issue is that I stumbled blindly onto this problem. How do I know this is the only case of this behavior?
Reply With Quote
  #21  
Old 07-17-2009, 01:03 AM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by ckrug View Post
I cannot think of a good way to regenerate this problem.
That was the thing I didn't get at first - I thought you had a reproducible way of provoking the problem, but apparently all you have is a repository of files (with some history behind them), and some of them exhibit the behavior which you are describing. Correct?

If so, then we'll have to work though a number of scenarios to find out how we could possibly arrive at the stage you're describing. I'm a little too busy right now to start with this right away - hope I'll have some more time next week.

Claus

PS: If you need quick and thorough answers, I recommend to talk to PTC support. I know we have some excellent filing experts in the team who will be able to analyse the situation quickly.
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/
Reply With Quote
  #22  
Old 07-30-2009, 08:42 AM
ckrug ckrug is offline
Registered User
 
Join Date: Sep 2008
Location: Santa Rosa,CA
Posts: 13
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by clausb View Post
That was the thing I didn't get at first - I thought you had a reproducible way of provoking the problem, but apparently all you have is a repository of files (with some history behind them), and some of them exhibit the behavior which you are describing. Correct?

If so, then we'll have to work though a number of scenarios to find out how we could possibly arrive at the stage you're describing. I'm a little too busy right now to start with this right away - hope I'll have some more time next week.

Claus

PS: If you need quick and thorough answers, I recommend to talk to PTC support. I know we have some excellent filing experts in the team who will be able to analyse the situation quickly.
Claus, Thank you for taking as much time as you have helping me with this issue. Actually, it's funny that no one really answered my original question. What does "secondary object of type 'asbm_struct' was missing" mean? Before version 16, I had never seen this load message. Now I see it all the time. In most cases it does not stop the load process, it's just an informational message. But, what does it mean "secondary".

A quick note, upon investigating my data I have discovered that I have data files all the way back to ME30 and/or One Space version 8 (not sure where it switched over to OneSpace). When I first started at HP we used ME30. I wonder how far back CC Modeling is backward compatible?

Thanks again for your help.

Cheers,
Calvin
Reply With Quote
  #23  
Old 07-30-2009, 09:12 AM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: secondary object of type 'asbm_struct' was missing.

Quote:
A quick note, upon investigating my data I have discovered that I have data files all the way back to ME30 and/or One Space version 8 (not sure where it switched over to OneSpace). When I first started at HP we used ME30. I wonder how far back CC Modeling is backward compatible?
Very far back. I'm not sure what we officially support, but technically, we could probably still load most files from versions as far back as 3.0, i.e. files created more than 15 years ago. (I'm sure our support folks will hate me for saying this Remember, this is not an official statement and not a promise - just an illustration that we're taking backwards compatibility very seriously!) And we can of course also load the even older ME30 files.

Claus
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/

Last edited by clausb; 07-30-2009 at 09:18 AM.
Reply With Quote
  #24  
Old 07-31-2009, 01:40 AM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by ckrug View Post
What does "secondary object of type 'asbm_struct' was missing" mean? Before version 16, I had never seen this load message. Now I see it all the time. In most cases it does not stop the load process, it's just an informational message.
I just checked with a fellow developer to help me with this. He told me that what happens here is that a secondary reference (such as a label) doesn't find its target, in this case an assembly. In other words, the target of the reference (an assembly) hasn't been loaded. This is where CoCreate Modeling's "open reference" mechanism will kick in automatically, i.e. no harm will be done.

BTW, where exactly do you see those messages? As a message box? As a message in the console window?
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/
Reply With Quote
  #25  
Old 08-28-2009, 10:23 PM
ckrug ckrug is offline
Registered User
 
Join Date: Sep 2008
Location: Santa Rosa,CA
Posts: 13
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by clausb View Post
I just checked with a fellow developer to help me with this. He told me that what happens here is that a secondary reference (such as a label) doesn't find its target, in this case an assembly. In other words, the target of the reference (an assembly) hasn't been loaded. This is where CoCreate Modeling's "open reference" mechanism will kick in automatically, i.e. no harm will be done.

BTW, where exactly do you see those messages? As a message box? As a message in the console window?
It's good to be back. Agilent started web blocking the CoCreate User forum so I have been unable to check this site from work. I am currently at home. I hope they correct this horrible error soon. I was really finding this user forum very helpful.

This message comes through when the file is loaded in the console window. At least I think that is what you are calling the console window. The same window that tells you about missing files. I was really hoping to understand the reason behind these messages because I'm certain they are causing additional problems. They are very nondescript when I get them. Is there a way to determine what secondary item or file is missing or any tools that I can use to troubleshoot the error? I realize I can just continue on "with no harm" but it still bugs me to not know.

It's good to hear about the backward compatibility. Every once in a while I do "save 3D data" instead of save modify, which I assume is dragging the data forward. Only old unloaded data remains in previous versions.

Cheers,
Calvin
Reply With Quote
  #26  
Old 08-28-2009, 11:31 PM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: secondary object of type 'asbm_struct' was missing.

Just to clarify the terms - the screenshot indicates what I call the "console window", versus what's known as the "output window".
Attached Thumbnails
Click image for larger version

Name:	consolewindow.png
Views:	488
Size:	68.7 KB
ID:	1551  
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/
Reply With Quote
  #27  
Old 08-28-2009, 11:34 PM
clausb's Avatar
clausb clausb is offline
Registered User
 
Join Date: Nov 2002
Posts: 1,168
Re: secondary object of type 'asbm_struct' was missing.

Quote:
Originally Posted by ckrug View Post
I was really hoping to understand the reason behind these messages because I'm certain they are causing additional problems. They are very nondescript when I get them. Is there a way to determine what secondary item or file is missing or any tools that I can use to troubleshoot the error? I realize I can just continue on "with no harm" but it still bugs me to not know.
Yup, that's what I would feel like as well 8-)

Maybe our support folks have tools for this. I'm not sure.

Quote:
Every once in a while I do "save 3D data" instead of save modify, which I assume is dragging the data forward. Only old unloaded data remains in previous versions.
That's right. (Although, of course, you have the option to save in older formats in "Save 3D" etc.)
__________________
CoCreate Modeling FAQ: http://www.clausbrod.de/CoCreateModeling/
Reply With Quote
Reply

Tags
asbm_struct, error


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 01:31 PM.



Hosted by SureServer    Forums   Modeling FAQ   Macro Site   Vendor/Contractors   Software Resellers   CoCreate   Gallery   Home   Board Members   Regional User Groups  By-Laws  

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.