- Status Closed
- Percent Complete
- Task Type Bug Report
- Category QCAD/CAM
-
Assigned To
andrew - Operating System All
- Severity Low
- Priority Very Low
- Reported Version 3.31.2
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Opened by Deejay - 07.01.2025
Last edited by andrew - 08.01.2025
FS#2625 - CamExporterV2 writes too many footers when some toolpaths are not visible
Hi Andrew,
while adjusting my CAM postprocessor file for my needs, I found an error in CamExporterV2.js for generating output code.
The bug seems to be in the handling of disabled (not visible / ‘frozen’) layers with different tools. It leads to write too many footers.
Lets assume the following example: There are 3 toolpaths in exactly this order:
Toolpath 1, using tool number 1
Toolpath 2, using tool number 3
Toolpath 3, using tool number 1
The problem occurs if toolpath 1 + 3 are visible and toolpath 2 is not visible. By ‘not visible’ I mean ‘deselected’ using the eye-symbol in the toolpath list.
In this case, CamExporterV2 does only export the visible toolpaths (as expected). But in the code, there is a bug for the detection when the footer-block must be written.
This leads to writing too many footer-blocks and the header/footer-ratio does not match any more.
The wrong footer is written in CamExporterV2.writeFile function.
In line 4814 of CamExporterV2.js, there is this if-condition:
if (!isNull(this.tool) && this.tool!==this.toolNext) ...
The variable this.toolNext is set wrong at this point.
Digging deeper, I found that toolNext is set at in line 5075.
Checking where this.toolpathBlockNext comes from, leads to
line 5049:
this.toolpathBlockNext = Cam.getNextToolpathBlock(toolpathBlock);
The problem is that the function Cam.getNextToolpathBlock() does not consider if the toolpaths are visible or not. If getNextToolpathBlock() would check if the toolpath is visible or not, it would work fine.
Interesting is that the function Cam.getPrevToolpathBlock() has a parameter called ‘ignoreFrozen’ and so this function does correctly consider not visible (or should I say frozen) toolpaths. So the tool-headers are generated correctly.
I think doing the same for getNextToolpathBlock() will solve the issue!
I tested that by overwriting the getNextToolpathBlock() function.
By adding
if (toolpathBlocks[k].isFrozen()) continue;
to line 1764 of Cam.js should work. But I do not know if there are possible ‘side-effects’ somewhere else.
Perhaps it is better to add a optional parameter ‘ignoreFrozen’ (with default set to false) like it is the case for getPrevToolpathBlock() and set this parameter true when calling from CamExporterV2.
Please let me know if you need more details.
Regards
Deejay
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task