Another approach to assembly solver (A2plus)

[kbwbe]

You may at least consider to simplify the "muxAssemblyWithTopoNames" to avoid duplicated code, meaning to put the 'if a2plib.getUseTopoNaming():' into the 'for' loop. I can only attach the code-diff snippet below, as the rest of the file is in testing ATM:

Hi Manuel,
please find modified function within fresh devel branch on github.

[manuelkrause]

You may at least consider to simplify the "muxAssemblyWithTopoNames" to avoid duplicated code, meaning to put the 'if a2plib.getUseTopoNaming():' into the 'for' loop. I can only attach the code-diff snippet below, as the rest of the file is in testing ATM:

Hi Manuel,
please find modified function within fresh devel branch on github.

Hi Klaus,
thanks for taking it in.
From some short testing, I can say, that the devel changes up-to yesterday evening seem to work quite fine.

[manuelkrause]

Hi Manuel,
please find modified function within fresh devel branch on github.

Hi Klaus,
I've did some further testing...
Can it be that for the "duplicate part" the 'hold shift for multiple' doesn't work?
Not that I need it.
Originally I did want to clone the 'hold +shift' behavior for an added mode of "update imported parts", namely a forced mode. Since you removing

Code: Select all

-                if ( newPartCreationTime >= obj.timeLastImport or    # changed behaviour to allow refresh ondemand
+                if ( 
+                    newPartCreationTime > obj.timeLastImport or

in one of your latest commits
I miss the forced reloading for my testing. (In fact you fixed my wrong programming of my early improve-colors that remained after removing it's main parts.)

My idea was: Holding Shift at click on "update imported parts" switches a 'forced' flag = true and that overrides the
'if ( newPartCreationTime > obj.timeLastImport or ...' decision in "def updateImportedParts(doc)" to reload all objects regardless of times.

Does it sound useful to you, too, at least a little bit?
Unfortunately due to missing knowledge I'm not able to code the "Shift"-pressed reference to set the force flag for the called function, on my own.

Best regards and TIA

[kbwbe]

Can it be that for the "duplicate part" the 'hold shift for multiple' doesn't work?

Hi Manuel,
this is not implemented at the moment.

Originally I did want to clone the 'hold +shift' behavior for an added mode of "update imported parts", namely a forced mode. Since you removing

Code: Select all

-                if ( newPartCreationTime >= obj.timeLastImport or    # changed behaviour to allow refresh ondemand
+                if ( 
+                    newPartCreationTime > obj.timeLastImport or

in one of your latest commits
I miss the forced reloading for my testing. (In fact you fixed my wrong programming of my early improve-colors that remained after removing it's main parts.)

You have to change this line for your tests. I cannot leave it in your version within the code, as it forced unneeded reimports of all parts/subassemblies to a2p.

My idea was: Holding Shift at click on "update imported parts" switches a 'forced' flag = true and that overrides the
'if ( newPartCreationTime > obj.timeLastImport or ...' decision in "def updateImportedParts(doc)" to reload all objects regardless of times.

Does it sound useful to you, too, at least a little bit?
Unfortunately due to missing knowledge I'm not able to code the "Shift"-pressed reference to set the force flag for the called function, on my own.

Best regards and TIA

I think it is not useful for normal work with A2p, only for your tests. Why should a file be reimported if it not has been changed?

[kbwbe]

Hi all,

a new version of A2p has been released, V0.1.4

What's new ?
* added system undo for updateImportedParts command
* bugfixes for handling of unicode filenames
* new experimental usage of topological naming for assemblies, to be enabled on preferences page
* improved file importer, to make topological naming possible

Topological naming can improve stability of constraints, if the topology of related parts changes. A2p now uses a kind of toponaming "light". It maps all geometry of parts to those features, which created them. But it does not go into sketches.

It works fine for:
- parts done completely with Part WB
- parts done with PartDesign, if new features are added. (e.g. an additional hole for a fastener does not brake the assembly)
- modified subassemblies (perhaps a part as been added)

It will probably fail if:
- changing of underlying sketches. So you should only do constraints to related geometry if the sketch is ready done.

If anyone of you want's to test the experimental toponaming, you have to enable this option on preferences page and to start with an empty assembly.
During importing parts, the toponames are been created.

Have fun !

[manuelkrause]

(...)
Originally I did want to clone the 'hold +shift' behavior for an added mode of "update imported parts", namely a forced mode. Since you removing

Code: Select all

-                if ( newPartCreationTime >= obj.timeLastImport or    # changed behaviour to allow refresh ondemand
+                if ( 
+                    newPartCreationTime > obj.timeLastImport or

in one of your latest commits
I miss the forced reloading for my testing. (In fact you fixed my wrong programming of my early improve-colors that remained after removing it's main parts.)

You have to change this line for your tests. I cannot leave it in your version within the code, as it forced unneeded reimports of all parts/subassemblies to a2p.

My idea was: Holding Shift at click on "update imported parts" switches a 'forced' flag = true and that overrides the
'if ( newPartCreationTime > obj.timeLastImport or ...' decision in "def updateImportedParts(doc)" to reload all objects regardless of times.

Does it sound useful to you, too, at least a little bit?
Unfortunately due to missing knowledge I'm not able to code the "Shift"-pressed reference to set the force flag for the called function, on my own.

Best regards and TIA

I think it is not useful for normal work with A2p, only for your tests. Why should a file be reimported if it not has been changed?

In the end you're more than right with all your answers. Meaning to more-or-less force me to find out why the old code was able to refresh the face colors&transparency by the other means that had been in the code of that time.
EDIT: Today I assume that I wanted to force a re-MUX of the parts.

Can you please confirm that the object-caching in "def updateImportedParts(doc)", from which I don't know if it's functional or not, does not interfere re-loading of eventually pending objects?

Thanks for your answer, and after that I promise to try even harder to search on my side.

[kbwbe]

Can you please confirm that the object-caching in "def updateImportedParts(doc)", from which I don't know if it's functional or not, does not interfere re-loading of eventually pending objects?

Hi Manuel,
this functionality is needed. If having multiple instances of a complex part/subassembly within an A2p document, this is reloaded only once, in order to save computing time. Before importing, the cache is been cleared, then a fresh copy of each part to be updated is loaded to it. So the cache always contains the recent version of a part which has to be updated. (including fresh generated toponames).

[manuelkrause]

Can you please confirm that the object-caching in "def updateImportedParts(doc)", from which I don't know if it's functional or not, does not interfere re-loading of eventually pending objects?

Hi Manuel,
this functionality is needed. If having multiple instances of a complex part/subassembly within an A2p document, this is reloaded only once, in order to save computing time. Before importing, the cache is been cleared, then a fresh copy of each part to be updated is loaded to it. So the cache always contains the recent version of a part which has to be updated. (including fresh generated toponames).

Hi Klaus,
thank you for your reply.
No, I don't doubt the usefulness of caching. I only wanted to know that it works correctly:
Is the algo aware of changed cached items like imported parts/ subassemblies -- either opened or not (but saved of course!) ?

[kbwbe]

Is the algo aware of changed cached items like imported parts/ subassemblies -- either opened or not (but saved of course!) ?

Hi Manuel,
the cache is always up to date to last storage of an importPart, because:
- it is cleared and reloaded when you hit the button updateImportedParts.
- When this is done, it is cleared again.

[manuelkrause]

Is the algo aware of changed cached items like imported parts/ subassemblies -- either opened or not (but saved of course!) ?

Hi Manuel,
the cache is always up to date to last storage of an importPart, because:
- it is cleared and reloaded when you hit the button updateImportedParts.
- When this is done, it is cleared again.

Again, thank you for clarifying so quickly!