V24 [bug] - Sketch dimensions not updating

[simonb65]

Updating a dimension and the dimension shown on the sketch doesn't update! Dimension line stays where it used to be and the value remains unchanged, yet the line it dimensions has moved to the new location ...



Open up the dimension and it actually shows the correct value ...



Looks like the data model in memory doesn't actually match what the UI is rendering!

Regenerate all (F5) and re edit the sketch and it still renders the incorrect (old) value. BTW : This is in an 'Edit in Separate Window' operation from an assembly.
Close the part ... returning back to the assembly, then re-edit in separate window and the problem persists.
Saving and closing the assembly, re-open the assembly, then re-edit in separate window and the problem persists.

Open only the part, problem persists.

Part attached. Extrusion<5>, Sketch<3> if anyone wants to confirm.

Not seen this in any earlier versions of Alibre.

 

[DavidJ]

Simon,

Something similar has been seen in previous versions. It typically indicates that the dimension has been corrupted - deleting an re-inserting fixes the immediate issue.

Can you recall what triggered the problem? If it is reproducible that would be really useful. My recollection is that this hasn't been possible to reproduce on demand, and files that show the issue don't give clues as to how it occurred. Any additional information that you can provide might help with diagnosis.

 

[simonb65]

Can you recall what triggered the problem? If it is reproducible that would be really useful.

Sadly not David. I just opened the part, edit sketch and then edited the dimension. On Ok'ing the new value the symptoms showed up. I've been editing (tweeking!) dimensions on a number of parts in an assembly, one of which was exactly the same as this part but just opposite handed. All without issue.

I had changed the dimension above it from 3.89 to 4.4 immediately before changing this one from 2.89 to 3.05, so nothing obvious in steps leading up to it.

I know finding issues in data might not be straight forward, but in my experience, dev can look at what code modifies that value and can figure out potential sources could corrupt it (i.e. thread sync issues, updates not being applied before the data is saved, was the value changed before another process had completed in the background? etc). It's strange how the visual rendering of the dimension object is incorrect even though the underlying data (and the geometry its driving) seems to be rendering ok! and the fact it persists through a save and re-load is odd. I deduce from that, that the dimension data is stored separately from the actual geometry data it's driving, rather than once single bit of data that's used for both. Again, to me, it would narrow down the bug hunting to the dimension rendering code and asking the questions. i.e. where is it getting the old data from? why is it choosing to render the old data over the new geometry data it's annotating? Is there 2 values in the part file that need keeping in sync like the dimension value and the geometry value? what in code would cause that mismatch in sync? ... These are the types of rhetorical questions I would be asking myself when I see issues like this. Maybe it's not the full method of repeatability that makes it easy, but there are clues there in the symptoms that can be used to hunt these things down.

In my line of software, I can't wait for repeatable evidence if/when there is a glitch in my current software project (brake-by-wire automotive braking system) ... because usually that means someone can get seriously hurt if I just wait for more data. Symptoms can tell you an awful lot.

If I get a repeat David, I'll post more info.

 

[simonb65]

Deleting the dimension and re-applying it does 'fix' the issue, but looking at the data in the PRT file, there is 'corruption' part way thorough the CARTESIAN DATA POINTS in both the original PRT file and the fixed dimension file ...

Dimension showing an issue ...



This CARTESIAN POINT just happens to be referenced by a LINEAR DIMENSION ...



Dimension deleted, re-applied and re-saved. Looks like the corruption now moves ...



this is reference by a circular dimension ...



I'm pretty certain that block of 'data' shouldn't be halfway through a floating point number definition!

Now, if dev knows what that block of data is for (where it originates from), then I suspect that's where 'a' problem may lie. Unless it's a block header in the binary file where the STEP text data is inserted, but the data in that data block doesn't change if it appears in the PRT file multiple times? So, unlikely a data block header.

Here is another on from another part file (interesting how its in the middle of a DIMENSIONANNOTATION record!) ...

 

[simonb65]

... and looking at the binary of both corrupt and 'fixed' dimension files it appears that the block of corrupting data has been inserted at the same address location in both files (regardless of what should be there), so wherever that data is coming from is probably the source of the bug (or its an object serialization 'thread?' sync issue!) ... and is potentially corrupting a lot of files as it appears in all files that I've saved under v24 so far ...



... and before Max chips in and says I know nothing about the software ... I know how to debug software!

 

[simonb65]

Something similar has been seen in previous versions.

Similar corruption is also present in v23 files, which is why it may have been seen before ...

Plus the nature of where that data block is being written will be quite random to what effect or symptom it shows to the user. My money is on if that gets sourced and fixed, a number of random behaviours may be disappear. Doesn't fix the already corrupt files though!



Not sure why something like this hasn't been visually picked up already.