I REALLY Hate this!
- Thread starter albie0803
- Start date
JST
Alibre Super User
That just looks like standard Alibre behavior. A bit worse than usual.
I am by now used to the idea that ANY update, EVEN THE MOST MINOR....... MAY RESULT IN A VAST AMOUNT OF RED AND DISSOCIATED DIMENSIONS. OR, other problems such as that shown. I do not LIKE that, but it happens, seemingly randomly. Sometimes tiny changes trigger it, and sometimes large changes cause no issue.
It's just the way Alibre works. it's not new, it has existed since before the "Geomagic" years. It has yet to be fixed. It seems to have yet to be even "admitted" by Alibre.
And, yes, it is a large productivity suck when it happens.
It is particularly bad because it normally happens in two cases..... 1) when checking the models and drawings and correcting minor issues just before delivering to the client 2) When "simple last minute changes" are requested by the client, and are implemented in the model.
In EITHER case, that means that the "quick updates" become much more work and time. If there are red dimensions, or a mess as illustrated by Albie, then not only the dimensions need to be corrected, but ALSO the entire drawing must be checked, to verify that the needed dimensions are all still present.
Mostly, the added time cannot be billed, since it is NOT due to a client request. It is a "problem with the tools".
Just to be VERY CLEAR here.... I DO understand that if dimensions are left without their features, due to a change, that they may be red. That is normal and expected. What is complained about is not that.
I am by now used to the idea that ANY update, EVEN THE MOST MINOR....... MAY RESULT IN A VAST AMOUNT OF RED AND DISSOCIATED DIMENSIONS. OR, other problems such as that shown. I do not LIKE that, but it happens, seemingly randomly. Sometimes tiny changes trigger it, and sometimes large changes cause no issue.
It's just the way Alibre works. it's not new, it has existed since before the "Geomagic" years. It has yet to be fixed. It seems to have yet to be even "admitted" by Alibre.
And, yes, it is a large productivity suck when it happens.
It is particularly bad because it normally happens in two cases..... 1) when checking the models and drawings and correcting minor issues just before delivering to the client 2) When "simple last minute changes" are requested by the client, and are implemented in the model.
In EITHER case, that means that the "quick updates" become much more work and time. If there are red dimensions, or a mess as illustrated by Albie, then not only the dimensions need to be corrected, but ALSO the entire drawing must be checked, to verify that the needed dimensions are all still present.
Mostly, the added time cannot be billed, since it is NOT due to a client request. It is a "problem with the tools".
Just to be VERY CLEAR here.... I DO understand that if dimensions are left without their features, due to a change, that they may be red. That is normal and expected. What is complained about is not that.
NateLiquidGravity
Alibre Super User
Disassociated dimensions and the lack of features/tools give so much trouble that I find it currently easier to create my views 1:1 in Alibre Design Drawings and export to AutoCAD to dimension and detail.
NateLiquidGravity
Alibre Super User
One example: When dealing with architectural things the cross section is almost "hung level" with respect to the horizon. Alibre Design offers no such aligning of cross sections.
Another example: The arc length dimensions, baseline dimensions, and chain dimensions I've requested for years.
I could go on.
VoltsAndBolts
Senior Member
That's a mess...
danwilley
Member
Here is another example of this bug. I am working on a drawing for a part. I created another sheet based on a different configuration of the same part with all chamfers suppressed and the part rotated 90 degrees, thinking the drawing might be less crowded and so easier to read. I finished the "no chamfer" sheet. Sometime later (hours) I reloaded the drawing for the part and found this scrambled mess.
This is very frustrating and such a waste of time. I wish Alibre would spend the remainder of this year just working on product stability... clean up this and other basic functions like the "detail" trim error bug (I posted to the forum a few days ago).
BTW... speaking of stability or lack of, a few days ago, I exited Alibre after a long work session (hours) only to find a second active Alibre session underneath with the same part I was working on in the Alibre instance I just ended. I did not think that was possible. I exited the second Alibre instance too. That second-instance part did not ask to be saved on exit so apparently, the part was correctly saved by Alibre instance 1. Also, there is definitely a bad memory leak. A few days ago my Alibre memory runtime footprint swelled to 1.8 gig when normally it sits around gig or so (with my current work effort).
Dan
The screenshot above is what the screenshot below should look like with regard to dimensions. It did for a while until Alibre went south.
This is very frustrating and such a waste of time. I wish Alibre would spend the remainder of this year just working on product stability... clean up this and other basic functions like the "detail" trim error bug (I posted to the forum a few days ago).
BTW... speaking of stability or lack of, a few days ago, I exited Alibre after a long work session (hours) only to find a second active Alibre session underneath with the same part I was working on in the Alibre instance I just ended. I did not think that was possible. I exited the second Alibre instance too. That second-instance part did not ask to be saved on exit so apparently, the part was correctly saved by Alibre instance 1. Also, there is definitely a bad memory leak. A few days ago my Alibre memory runtime footprint swelled to 1.8 gig when normally it sits around gig or so (with my current work effort).
Dan
The screenshot above is what the screenshot below should look like with regard to dimensions. It did for a while until Alibre went south.
simonb65
Alibre Super User
+1, ... and performance.
Last edited:
albie0803
Alibre Super User
I feel your pain brother!
Alibre Design isn't intended to suffer those problems, so if your workflow has revealed a weakness it is important that you submit the problem to Support with as much background detail as possible.
In some cases, changes to underlying geometry and the internal IDs of features due to edits may inevitably lead to dissociation. Where this isn't the case, we need to work out the cause/trigger, and hopefully then find a solution.
In some cases, changes to underlying geometry and the internal IDs of features due to edits may inevitably lead to dissociation. Where this isn't the case, we need to work out the cause/trigger, and hopefully then find a solution.
danwilley
Member
In both of these cases (post #1, post #12), it seems something different than disassociation is happening. I have had disassociations happen before and it is indeed because a reference point or edge has been removed. Adding chamfers after a drawing has been created is an example. In those cases, the affected drawing dimension generally stays where it was placed (on the drawing) but turns red in color. In these two cases however, not only did the drawing dimensions move way off target, they did not turn red. Only conjecture on my part, but it feels like the underlying meta-data was corrupted somehow… rather than through changes using normal work flow (ie: adding chamfers).
I still have the broken drawing and will submit the part, drawing and global parameter files to support some time later today.
Thanks,
Dan
I still have the broken drawing and will submit the part, drawing and global parameter files to support some time later today.
Thanks,
Dan
