View Issue Details

IDProjectCategoryView StatusLast Update
0002770PathBugpublic2019-07-29 15:07
Reportermlampert Assigned Tomlampert  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.17 
Target Version0.17Fixed in Version0.17 
Summary0002770: Profile names wrong on startup
DescriptionWhen a file is saved with a Profile the names of the profile are not correctly displayed when the file is loaded back into FC. If a contour's name is "Contour :TC" what is displayed upon startup is ":TC".

Only after the first "App.ActiveDocument.recompute()" are the names correct - and functions using object's name work properly again.
Steps To ReproduceCreate part with PathJob and Profile around it.
Save file and close FC.
Start FC and load saved file
Additional InformationThe problem I noticed is that the original contour path does not get hidden when it is dressed up right after loading. The user has to manually hide contour. Once the name is correctly displayed, creating a dressup will also correctly hide the "claimed" contour path.
TagsNo tags attached.
FreeCAD Information

Activities

mlampert

2016-12-10 23:32

developer  

path1.png (5,611 bytes)   
path1.png (5,611 bytes)   

mlampert

2016-12-10 23:32

developer  

path2.png (5,829 bytes)   
path2.png (5,829 bytes)   

mlampert

2016-12-10 23:39

developer   ~0007513

While working on the holding tags dressup the results of the missing recompute() became rather drastic (see attached screenshots).

Comparing the Path.Command's that get generated and the Path.Command's after the file is loaded back into FC shows that the serialisation and de-serialisation of float values might be the root cause.

Original:
Command G2 [ I:2.5 J:0 K:0 X:-2.641e-16 Y:12.5 Z:1.5 ]

After re-load:
Command G2 [ E:-16 I:2.5 J:0 K:0 X:-2.641 Y:12.5 Z:1.5 ]

It seems the exponent of X becomes a new key in the parameter dictionary "E:-16".

mlampert

2016-12-10 23:47

developer   ~0007514

Extracting the fcstd file and checking HoldingTagsDressup.nc it looks like serialisation is good:

....
G2 I2.5 J0 K0 X-2.6410315235593498e-16 Y12.5 Z1.5
....

mlampert

2016-12-11 02:26

developer   ~0007515

Upon further investigation it turns out that according to the g-code specification exponent notation is not supported (which means the serialization code is what's wrong):

From http://linuxcnc.org/docs/html/gcode/overview.html#_number

The following rules are used for (explicit) numbers. In these rules a digit is a single character between 0 and 9.

    A number consists of (1) an optional plus or minus sign, followed by (2) zero to many digits, followed, possibly, by (3) one decimal point, followed by (4) zero to many digits - provided that there is at least one digit somewhere in the number.

    There are two kinds of numbers: integers and decimals. An integer does not have a decimal point in it; a decimal does.

    Numbers may have any number of digits, subject to the limitation on line length. Only about seventeen significant figures will be retained, however (enough for all known applications).

    A non-zero number with no sign as the first character is assumed to be positive.

Notice that initial (before the decimal point and the first non-zero digit) and trailing (after the decimal point and the last non-zero digit) zeros are allowed but not required. A number written with initial or trailing zeros will have the same value when it is read as if the extra zeros were not there.

Numbers used for specific purposes in RS274/NGC are often restricted to some finite set of values or some to some range of values. In many uses, decimal numbers must be close to integers; this includes the values of indexes (for parameters and carousel slot numbers, for example), M codes, and G codes multiplied by ten. A decimal number which is supposed be close to an integer is considered close enough if it is within 0.0001 of an integer.

mlampert

2016-12-11 03:15

developer   ~0007516

As it turns out fixing the serialisation does not fix the recompute() issue. Back to the drawing board.

mlampert

2016-12-11 05:19

developer   ~0007517

The marking as dirty (touch) come from PathLoadTool.LoadTool.onChanged().

onChanged() gets called several times during the restore process (once for each property). Once the ToolController has "children" those get 'touch'ed each time onChanged() is called.

mlampert

2016-12-11 05:20

developer   ~0007518

Unfortunately not triggering the touch() (unconditionally) does not fix the naming issue of Contour on restore.

mlampert

2016-12-11 05:27

developer   ~0007519

The problem is that the logic to assign the proper label (based on the property UserLabel) only exists in Contour.execute(). Contour.onChanged() (which gets called during restore) however uses a simpler logic which leads to the name difference.

wmayer

2016-12-12 18:35

administrator   ~0007522

See https://github.com/FreeCAD/FreeCAD/pull/374

Related Changesets

FreeCAD: master c6781442

2016-12-12 19:34:27

wwmayer


Committer: GitHub Details Diff
Merge pull request 0000374 from mlampert/tracker-2770

Path: Assign Contour label on restore fixes 2770
Affected Issues
0002770
mod - src/Mod/Path/App/Command.cpp Diff File
mod - src/Mod/Path/PathScripts/PathContour.py Diff File
mod - src/Mod/Path/PathScripts/PathLoadTool.py Diff File
mod - src/Mod/Path/PathScripts/generic_post.py Diff File

Issue History

Date Modified Username Field Change
2016-11-13 00:33 mlampert New Issue
2016-12-10 23:32 mlampert File Added: path1.png
2016-12-10 23:32 mlampert File Added: path2.png
2016-12-10 23:39 mlampert Note Added: 0007513
2016-12-10 23:47 mlampert Note Added: 0007514
2016-12-11 02:26 mlampert Note Added: 0007515
2016-12-11 03:15 mlampert Note Added: 0007516
2016-12-11 05:19 mlampert Note Added: 0007517
2016-12-11 05:20 mlampert Note Added: 0007518
2016-12-11 05:25 mlampert Assigned To => mlampert
2016-12-11 05:25 mlampert Status new => assigned
2016-12-11 05:27 mlampert Note Added: 0007519
2016-12-12 18:35 wmayer Note Added: 0007522
2016-12-12 18:35 wmayer Status assigned => closed
2016-12-12 18:35 wmayer Resolution open => fixed
2016-12-12 18:35 wmayer Fixed in Version => 0.17
2019-07-29 15:07 Kunda1 Changeset attached => FreeCAD master c6781442