Unnecessary saving of assembly sub-components .. Why?

[bigseb]

Now if you update the reference parts, that means I have to update the drawings for those parts too! Up issue to reflect the part change, re-issue and distribute to all parties that involves. Do you not realise the domino effect these kind of issues cause? ... when NOTHING has actually changed!

I forgot about drawings!! Is this why my drawings are always broken when I reopen them? If I think of the all the time I lost 'fixing' broken drawings...

 

[simonb65]

Is this why my drawings are always broken when I reopen them?

I suspect the broken drawing links that we have all seen over recent releases could stem back to the underlying part/assembly being saved by Alibre during a non-related view/edit. It certainly makes sense that that could possibly be the root cause.

 

[JST]

S.........
Alibre, please sort this out otherwise the concept of having and maintaining a common parts and product library of approved design parts breaks all the versioning and validation rules that, as a company, I need to apply in order to control changes to already validated parts and maintain manufacturing integrity. You cannot update parts just because you want to update them to the latest version.

Now if you update the reference parts, that means I have to update the drawings for those parts too! Up issue to reflect the part change, re-issue and distribute to all parties that involves. Do you not realise the domino effect these kind of issues cause? ... when NOTHING has actually changed!

This is SO IMPORTANT that it bears repeating over and over until everyone "gets it".

Just to put this in developer perspective..... Would YOU like it if every time anyone at Alibre simply looked at part of your source code, the system made you re-save it and changed the release number?

That is essentially what is going on here.

EVEN IF Alibre is not changing anything in the part, just maybe some file feature, WE DO NOT KNOW THAT Part of the integrity of a library system is the absolute knowledge that what is in the library CANNOT BE CHANGED BY A USER. That has to be a CERTAINTY or the system is broken and nothing can be counted on.

We are dealing here with very important things that are basic and critical to a manufacturing company's existence. It is "IP", that cost hundreds of thousands of dollars at the least to develop. The problems which occur if basic data gets overwritten do not even bear thinking about.

If you expect any company to use Alibre, this has to stop. It is a big deal.

 

[danwilley]

+1

 

[wazzu83]

Nailed.It.

Thanks JST!

 

[GIOV]

Hi,
I confirm that in my system not bad behavior was detected.
My first Laptop is 32 Bits OSWV GD15
My Second one is 64 Bits OSW7AV22
I did a risk in one of my project:
Save as assemble (Structure) with new version and keeping the parts and sub assembles without any changes.
Open the assemble(Structure) with the generic name V14 and all was ok so ADV22 did not make any changes.
I hope that your issue asap will be solved! OS?

 

[simonb65]

So, further investigation of the original issue (see post #1):

The constituents tree showing the relationship between entities ...

1. Actions were that Assembly B is made through the API by creating an assembly, then adding parts and sub-assemblies to it.
2. Add Assembly B to existing Assembly A and constrain to Assembly A using Part C.
3. Save Assembly A and Assembly A, Assembly B and Assembly D is flagged as edited.

Now, delving deeper ...

1. Opening just Assembly B and then ...
2. Close Assembly B (No Interaction other than the close button) results in Assembly B and Assembly D flagged as edited.

and deeper ...

1. Opening just Assembly D and then ...
2. Close Assembly D (No Interaction other than the close button) results in Assembly D flagged as edited.

and deeper ...

1. Opening and Closing the 2 constituent parts of Assembly D does not flag of any changes.

So questions for Alibre Dev and @Max (and importantly Ashok), possibly rhetorical, but here to provoke the thought/analysis process ...

1. If you successfully load data from a constituent part/assembly (even though it may be a earlier version and a subset of the current version), why do you feel the necessity to modify and resave (modified) it without any user interaction?
2. Up until the point of any active edit of that part/assembly, why is the file not treated exclusively as read only?
3. Why only this sub Assembly? There are other parts and assemblies all created at the same time (same version of AD) that are also being referenced.
4. What is being updated in the file? (I know from investigating that index orders are changed ... So what is the implication for drawings and/or other assemblies that use those indexes for constraints and/or reference)? Do they rely on index ordering?
5. Why is the status/data structure of a constituent part/assembly a direct concern (and responsibility) of the Assembly that merely needs to reference it?
6. How does the unsolicited modifying of the Assembly affect drawings that are derived from them? Only you (Alibre) know what gets modified and it's impact.

Saving the modified file and a quick look with Beyond Compare shows a 6Kb increase in file size (highlighted at the top of each data column) and as you can see down the left side of this image, a significant number of changes throughout the file, as I keep stressing, for ZERO user changes.



It does appear that some geometry has been changed (by Alibre ... not the USER!) ...



Also, why is this stuff saved in an Assembly or Part file, that's application UI metrics not geometry specific ...



Who made the decision to put this in a data 'geometry' file? Does no one check actually what is and isn't saved and if it actually should be.

I'm not sure where you're really going with the data in these files, I'm not convinced analysing these newer files that you 100% do either! I'm not sure it's really been thought through. I don't think the upgrade path has been thought through. I don't think the structure of data has been thought through. This looks like a classic case of building more on bad foundations. If this came from my team, I'd seriously be having a sit down with them and sort this out. You'll never catch up with the mess this is generating if you just plough on adding stuff without thought of structure, where it should be, the impact of making changes to that structure, file size bloat and it's impact on load and save operations, etc

I'm trying to help you out here guys ... take the advice/analysis or just ignore it and plough on, that's your choice. But remember, it's you that has the task of maintaining, developing and dealing with the fallout of this and it's your customers you need to keep happy ... just glad it's not my problem. If it was, I wouldn't be spending valuable time changing the UI until the backend was robust and scalable.

I might be being a bit harsh. It may be a simple bug. But the fact is it has a big impact on your customers, their time and ultimately their businesses, so I think we have a right to get a little frustrated now and then.

 

[simonb65]

More session related UI specific stuff saved in the 'Assembly' file ...



WHY? What has this got to do with the GEOMETRY of my assembly or part?

The very reason why Visual Studio (for example) has a Project file, a Solution File and a User Session file. There is a segregation needed here to remove UI only stuff away from design data. The data architecture here is just too bad for kind words, so I just won't comment any further.

 

[Max]

WHY? What has this got to do with the GEOMETRY of my assembly or part? The very reason why Visual Studio (for example) has a Project file, a Solution File and a User Session file. There is a segregation needed here to remove UI only stuff away from design data. The data architecture here is just too bad for kind words, so I just won't comment any further.

Simon, with all due respect, these are file properties. Not system properties, which are abstracted away in a separate file. If you believe our save file must contain “geometry only” at all costs otherwise our data structure is bad, then I don't know what to tell you. It is clear from what you’re saying, though, that you don’t have a good idea of what you’re looking at.

When you resize the Design Explorer, when you modify node expansion states, change File Properties values, etc. that is remembered between sessions on a file-by-file basis because that information is stored in the file properties, which are file specific, along with the geometry, which is file specific. That's why you don't open every file and the tree is collapsed; rather it is where you left it, how you left it, among many other things that operate similarly. Even if you send them to another person, or download it to a new machine. This is as normal as it is mundane.

With respect to files updating seemingly at random, or geometry changing

This should never happen. In almost no cases does it happen, and even less often in an unexplained way, once investigated.

Every time a file is saved it is versioned internally. Internal versioning is used, for example, to determine if a drawing should be updated or not – if the drawing’s idea of a part’s version is different than the part’s version, an update is prompted.

Like drawings, subassemblies also detect the versions of their constituents. If you have a subassembly that thinks a constituent part is v20, but once loaded the constituent part turns out to be v21, that subassembly is updated to reflect the new version context of its constituent. At this point, the subassembly has changed and it is now “dirty”, a term meaning that you will be prompted to save the changes to it. It has to be saved to know what version of the part it’s referencing.

In this way, it is possible that a part change you made a while ago in a seemingly unrelated place may have somehow worked its way, via the subassemblies and locations in models that it is in, into a model you’re viewing today and all of the sudden it’s asking you to save a subassembly. In nearly every case we see, it is because references are working their way up to ensure correct versioning.

Why individual files might prompt a save

In workspaces, there are obvious things that would prompt a save. Things like changing a part’s geometry. Changing its material. Changing its part data. There are other things that do this too, that may be less obvious. Anything that is file-related that is changed (except a few things) will prompt you for an update. Things like switching dimensions to Dual Dimensions, or modifying some visualization settings such as turning off Ambient Occlusion.

A handful of things do not, on their own, cause a file to prompt to be saved. Things like making the Design Explorer wider, changing Design Explorer node expansion states, or switching from Orthographic to Perspective. This class of items will get saved if the part is saved, but will not on their own prompt a save to take place.

To the original issue

The short answer is that without seeing your file we don’t know what happened. It could be something related to the API calls you’re using. Maybe it’s something you’re doing to actually dirty the part when it seems like it wouldn’t dirty it. Maybe it’s a bug. I don’t know because you have decided to write a novel on the forum in a derogatory, investigation-style tone instead of asking us. I do know that if we ever found a case that was truly unexplained of this behavior happening, or where geometry actually changed in an unexplained way, it would likely become the highest priority item of the team. We’ve had people ping us with this kind of question before, and after looking at what actually happened and explaining it, almost always the answer is “oh, yeah I did that”. Maybe yours is different – we need to check.

To the way in which you are choosing to engage with us

Simon, you have a very shoot first, don’t ask questions later approach to your “investigations”, assuming that you are always correct in your assertions about a codebase you have never seen and do not know the details of. I’m sure you are a fantastic developer, but in 20 years I have never seen any developer be as confident about a codebase they’ve never seen as you seem to be about ours. Take from that what you will. We do not, however, need SimonB65’s forum advice on how to run our teams, when to “sit down” with our team members, or how to “sort out” our “bad coding”. It’s getting really tiring to have to continue saying that. At some point soon I’m going to stop saying that.

Your post is very difficult to follow and doing so without model files is meaningless in any case.

However, the result of posts like this is that they are most often incorrect, and then we start to see follow on questions like this:

Another action which triggers a save is a zoom, or rotate, even though no edit is done. I do NOT think that is correct behavior.

No, zoom and rotate do not trigger saves.

I forgot about drawings!! Is this why my drawings are always broken when I reopen them? If I think of the all the time I lost 'fixing' broken drawings...

No. Drawings become disassociated typically when really fundamental changes have been made that completely remap the ACIS entity IDs. There might be another reason or two, but this has nothing to do with it.

That is essentially what is going on here.

No, it’s not.

This post is not adding value – it is causing confusion. It is to no one’s benefit.

So what can be done now?

A few things are obvious here. One, if Simon or others are having this issue they should send us files and we will investigate them. We’ll be happy to crack them open and see if there’s an issue. If there is, we’ll be on it.

Next, I think it is fair that even if some of the behavior is intended, it is obviously not transparent enough and perhaps there is room for the behavior to be changed to be more obvious or to operate in a different way or to give you more control. We can certainly evaluate those things. An obvious place to start is to more finely delineate which items that are saved on a per-file basis should result in an incrementing of the internal version number. That would probably go a long way to solving almost all of these issues.

I can say that millions of parts have been made in Alibre products over 22 years and this is not a rampant issue. For some people, clearly, there are perceived issues and perhaps real ones. Much of the behavior is probably for a good reason, but if you don't think it is you should work with us to figure out why this is happening for your workflow. That might result in either you learning something or in us taking different approaches to some things, both of which would be positive things.

Since this thread has little room for further progress given that we need more interaction / files and less conjecture, I'm going to close it for further comment. If someone would like to start a new thread to discuss specific about when they see these kinds of things, please do so as it would be helpful for everyone to see if there are any similarities to their own workflows.

 

[Max]

To summarize Alibre's action items from this -

• We will evaluate the approach to internal version incrementation.
  • Some things you can change within a workspace today do cause version increases, and practically speaking that may be confusing and is probably unnecessary.
  • Some other things today cause version increases, and they should not.
    • This is the root cause of the issues described in this thread, I believe.
      
• The net result of this evaluation will be a set of changes that, when made, allow you to make "cosmetic" changes to files and to save them, but not increment the internal version number. This prevents save prompts and reprojections when you, as the user, feel like there is no reason for things to reproject or update things, because "all you did was open it and ____" (and then save).

This approach should alleviate the issue almost entirely and I think will be a big positive, assuming there are not other things at play such as a bug. While this thread did get a little out of control, the issues raised in general are good targets for action and I think we have a solid game plan to address them.