View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002770 | Path | Bug | public | 2016-11-13 00:33 | 2019-07-29 15:07 |
Reporter | mlampert | Assigned To | mlampert | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 0.17 | ||||
Target Version | 0.17 | Fixed in Version | 0.17 | ||
Summary | 0002770: Profile names wrong on startup | ||||
Description | When 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 Reproduce | Create part with PathJob and Profile around it. Save file and close FC. Start FC and load saved file | ||||
Additional Information | The 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. | ||||
Tags | No tags attached. | ||||
FreeCAD Information | |||||
|
|
|
|
|
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". |
|
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 .... |
|
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. |
|
As it turns out fixing the serialisation does not fix the recompute() issue. Back to the drawing board. |
|
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. |
|
Unfortunately not triggering the touch() (unconditionally) does not fix the naming issue of Contour on restore. |
|
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. |
|
See https://github.com/FreeCAD/FreeCAD/pull/374 |
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 |
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 |