Formations error

[gmatelich]

We're having problems while building an exploded view with formations. After sometime of exploding, then trying to accept the formation to save changes we get the error:

LISP Error
NIL is not a structure


After recieving this error there seems to be no way of getting the formation to save again.

Any ideas what is causing the problem and how to recover from it?

[tom kirkman]

I get this error if the name of the formations is all capitals. Change the name so that the first letter is capitalized. leave the rest lower case.

Name

Good Luck

Tom Kirkman

[gmatelich]

The name is Explode.

[gmatelich]

A new problem: is having saved a package and opening it back up to find the Standard view exploded.
Before saving we could switch Standard and Explode everything worked correctly. But on re-opening the package the Standard view came in exploded, and selecting the Exploded formation it exploded farther.

[gmatelich]

Originally posted by gmatelich
A new problem: is having saved a package and opening it back up to find the Standard view exploded.

It appears to be a problem of saving while the formation was still open. Close the formation THEN save . . .
:o

[John Scheffel]

I don't have any answers, but Formations is now supported so you can also report these issues to CoCreate support.

[May Kung]

There are a couple ways to get around this error. One way is to make sure Annotation is shut down before you start creating the formation. Of course, usually by the time you see this error it's too late to shut Annotation without losing all your changes.

Another way around it is to save the Formation to a new name, like Explode1 or something. Just edit the name directly in the menu and tell it to save. It should let you save now.

This seems to work with SD9, but I assume it'll do the same thing under OSD11. I don't know why it does this, though.

[Jim McKim]

These kind of problems are exactly why I don't consider formations a real solution to the problem of making exploded view drawings. CoCreate needs to get their act together and supply a robust solution that is easy to use. Nothing like losing hours of work to make a user happy - NOT!
We avoid these problems by making a top assembly that contains two subassemblies: one assembled and one exploded, the parts of which are all shared. (Create the assembled one first, share the assembly, then unshare one level and move parts as needed for exploded representation.) Then we make a drawing which has both the exploded view and an assembled view, the viewset of each belonging to the corresponding 3D assembly. Nothing hidden to anyone who opens the files.
-Jim

[rcurrier]

How do you handle this when you have a top level assy that
has approx 1500 parts in it. I then would have to load about 3000 parts to update this assembly drawing. My current file already takes too long to load at 1500. I am using high end system, but still takes time to load and generate this much data.

I have had these same problems, and although supported, have not been able to get much feed back on how to eliminate the problems. they are random as best i can tell.

Also have found, that if you do an assembly drawing of assemblies below the top level, and then later load that individual assembly to make a modification, that the formations are not there. You need to have the top level, or what ever assembly up the structure you had loaded in your session, currently loaded in order to get to your formations.

[Jim McKim]

Originally posted by rcurrier
How do you handle this when you have a top level assy that
has approx 1500 parts in it. I then would have to load about 3000 parts to update this assembly drawing.

I don't think it would make as much difference as you think. The parts in the two assemblies are all shares of each other. I'm not sure, but I think that means that that is a lot less data than if they were unique parts or copies of each other. Quoting from the OSD Help page on sharing parts and assemblies, "When sharing parts or assemblies, the largest proportion of data, particularly data concerned with the geometry of a part, is shared between all instances. Consequently, this shared data exists only once in memory. In addition, a small amount of data must also be duplicated for each shared item, for example, positioning data. "
Our assemblies have only about a tenth of the number of parts you are dealing with. I don't have a way to test a loading time difference that small. You might try it - it is easy to create the shared assembly and check the file size and load time. I just made a file of an assembly with two shared sub-assemblies, and the file was only 0.4% bigger than that of one of the subassemblies by itself.

[rcurrier]

i will try it and let you know.....

[E-Buckner]

Originally posted by gmatelich
We're having problems while building an exploded view with formations. After sometime of exploding, then trying to accept the formation to save changes we get the error:

LISP Error
NIL is not a structure


After recieving this error there seems to be no way of getting the formation to save again.

Any ideas what is causing the problem and how to recover from it?

There are a few ways around the problem. One of them, the most often used here, is to save the model/assy out as a pkg, load it separately, modify it (in pkg form), then reload it into yer bundle.

I don't know if you have noticed yet but this error sometimes precludes one from deleting the formation as well. The above work around works here as well. Which leads me to believe that the problem lies in it's associativity to the AM but I have never recieved a satisfactory explanation as to the why...

Good luck.

[nan battaglia]

I've been using formations for sometime now with very few problems. I'm using OSD rel 11.6.
When I do get the LISP Error, NIL is not a structure, if I close Annotator (by way of OSD Modules) I'm able to accept the formation. I leave Annotator off until I'm finished exploding my assembly.
When you save your assembly as a package or sda, make sure your formation is Standard and not Explode when you save.
Another scenario:
When you are creating your formations make sure you don't add or remove any parts from the assembly while you are exploding. Make sure you have the Standard Formation open to add and remove parts.
Hope this helps

[E-Buckner]

When you are creating your formations make sure you don't add or remove any parts from the assembly while you are exploding. Make sure you have the Standard Formation open to add and remove parts.


This is a biggie. Making changes to yer assys while inside a formation other than standard is almost a surefire way to prompt this error/bug.

Thanks.