Isolation Removing Traces
Issue #585
resolved
I have been trying to get a PCB milled on my new machine. After much struggling I found some comments that isolation was not working on 8.994 and should revert to 8.5. I tried this and I managed to get a usable board. However getting 8.5 installed on Mac seems impossible and 8.9x Beta is much more better. I know Marius does not use Isolation, but I’d like to see if there is something wrong in what I’m doing.
Using FlatCam 8.944 with 1 isolation pass the traces almost disappear and are broken. Using 8.5 (3 passes 0.4 overlap) the traces are undersize (probably issues with my mill) but still survive with three passes. Opening the files side by side and checking the same pad, I can see that 8.994 mills 0.05 mm inwards, despite the V-Bit going deeper.
8.994 Gcode:
G00 X1.0501 Y9.8952
G01 F60.00
G01 Z-0.0746
G01 F120.00
G01 X2.7550 Y9.8950
G01 X2.7648 Y9.8960
8.5 G-Code for same Section:
G00 X1.0501Y9.8451
G01 Z-0.0600
G01 X2.7550Y9.8450
G01 X2.7697Y9.8461
So despite the Z depth being lower the cut is more to the interior of the pad. The result is on the picture below (8.994 on the left). If we add cut 0.05mm inward on both side and a bit deeper there is not change of the trace surviving. Looking at the preview on Flatcam 8.5 you can see the innermost pass is visually a bit further form the pad.
I know Marius is overloaded and does not use Isolation. I’m still assuming I’ve done something wrong, but I’m not sure what to do.
If it helps I can send the GRBL and both gcodes. I’m also willing to review the code I someone can point in the general direction.
Comments (20)
-
-
reporter
Thanks a lot for this explanation. I tried the calculator but no field appear on my installation (and actually had some other issues). I’m running this from commit ebf5cb9e3094362c4b0774a54cf119559c02211d on a Mac. Not sure this is the correct way to do it.
I reviewed the configuration. Here is a snapshot:
I think I got the things backwards. I kind of mixed the instruction from the AntCNC videos and a bunch of other videos. My goal was to have a similar Z-Depth. Using these parameter in 8.5 worked fine. But these were based on the experience of the creator of the Ant, and their experimentation. I’m now looking for some G-Code to test the machine capabilities. They suggested 0.2mm and Z-Depth 0.7, but on 8.5 the think is applied differently. If I go this correctly, on the Geometry, the V-Tip Dia is the nominal dia of the bit, using the calculator I get the theoretical dia at that depth (barring tolerances). This value is the value I should use on the Tools Table so the offset works correct. Which is backwards from what I did, by setting the V-Tip dia to get the depth I messed the offset completely.
I did a bunch of experiments (only SW) and it was definitely user error. I’ll test with the correct approach once I can make noise. If this produces the expected output I will place replies to the comments I found.
-
And just in case from the above it is not clear why the software is working as expected, by subtracting the Bottom Y from the Top Y we should get our (trace width + tool_diameter), meaning (0.1mm + 0.1268mm) = 0.2268mm.
Therefore we should test if: (10.1134 - 9.8866) == 0.2268 → 0.2268 == 0.2268 which is True.What you need to take into consideration:
- the V-bit quality might not be so good meaning that it’s geometry might not be as expected. Is the tip of the V-bit really centered on the 3.175mm shaft. If not then the actual tool diameter might be larger therefore cutting into the traces. Try a different brand of V-bit, maybe get a higher priced one.
- the V-bit might not be really centered in the spindle chuck. Make sure that it is as expected by turning the spindle and looking at the tip which should be a point and not a ‘circle’. This can be fixed by multiple attempts on seating the V-bit inside the chuck, searching for the best possible solution
- the spindle itself has a runout meaning that the rotor has play in the bearings therefore the rotation is not perfect but will also describe a circle instead of rotating in the same point. The better Chinese spindles profess a 0.05mm runout which is half of 0.1mm so you could see how a 0.1mm trace can be ruined by the spindle runout itself. There is no fix for this except replacing the spindle if the runout is too great (some may try to replace the bearings instead).So what can be done from the software point of view?
You can assume that the depth of cut is greater than the 0.05mm therefore assume a bigger actual tool diameter. Of course the clearances in our Gerber file are the limiting factor, there is a maximum that you can’t go beyond, without damaging the traces.In our case above, what I would do is to use a cutting depth starting from -0.1mm which translates into an actual too diameter of 0.1536mm (calculated with the Calculator Tool in FlatCAM beta). Or assume that you are using a 0.2mm tip diameter V-bit although you are using actually an 0.1mm tip-diameter V-bit, therefore entering in FlatCAM beta Tool diameter the value of 0.2268mm
That should fix your issues if the problem is listed above.There is another problem that can see your traces thinned and that is the so called ‘back-lash’ and depending on how your CNC is made, that has different fixes, but those are only mechanical fixes for the CNC.
Best regards,
Marius -
It looks like we were writing posts at the same time.
Based on the picture you posted, you need to understand that 2 things matter in regards of keeping the PCB feature intact:
TheCut Zparameter andTool Diameter. By selecting the V-shape as Tool Type (TT column in the table) you allow changing theCut Zby adjusting theTip DiameterandTip Angleparameters in the Tool Parameters. But those should reflect the reality as they describe physical properties of a V-bit. So in the end, the Tool Diameter is what it matters (how far from the trace you are going to mill).
-
Try to use my latest sources. I don’t work on the FlatCAM repository (here) but on my own forked repository.
https://bitbucket.org/marius_stanciu/flatcam_beta/get/Beta_8.995.zip -
reporter
These comments are really good. Worth adding to the original AntCNC sites and to the wiki (I know it’s beta).
I’m also using the silent day to try a set on hand or program crafted GCode, to try to gauge my machines precision and find good compromises. These comment are very illuminating.
I will also attempt to move to this latest version. If I were to use the code from source is there a preferred repo and branch to get stable versions? I assume https://bitbucket.org/marius_stanciu/flatcam_beta/branch/Beta_8.995 is under development.
Installed from you Zip, on my Mac (Python 3.10.2) I needed to do the following:
python -m pip install rasterio==1.3a3 pip install -r requirements.txtI’m happy to see you can set dark mode. Will play with it for stability.
-
What do you think about the new GUI? In the Plugins, the Properties for the Objects…
-
reporter
Had to resubmit this answer.
So with the correct parameter I have been able to mill usable board. The machine still has some issues but at least from the G-CODE perspective it seems fine.
I think the new UI is awesome. It looks much more polished and work in DarkMode. I kind of had to revert because of bCNC which does not work well in dark mode.
I found the plugins confusing at first. I expected the “create next step” approach and did get that the plugins did that at first.
The other observation was that I could not find a way to know what parameter generated the next step. So I had to dive into the G-Code to see my depth.
Also was wondering what the allow auto-leveling does and how to use it.
Overall I like the approach.
-
reporter
Been playing around and have a few comments:
- Love the multiple pass for the Pads. I have to try this for milling but the main reason for multiple passes is to avoid bridging, and that should only happen on pads. Great feature.
- At least on the Mac the tabs close is not very consistent. There is a X for project (which you can’t close). X for editor will not close (you have to click on the toolbar red button to close)
- Did not notice that V-Bit updates Dia on tool automatically.
- Still trying to figure out preferences, I think something like what Kicad does (tree bases) would be nicer. But maybe for 1.1.
-
Hello Thomas,
I could not find a way to know what parameter generated the next step
I don’t think I understand… What next step? The flow is basically: load Gerber, process it somehow (Isolation, NCC, Paint etc) and therefore generate a Geometry Object, optionally edit the Geometry object, process it with the Milling Plugin, optionally edit the GCode, save GCode.
Also was wondering what the allow auto-leveling does and how to use it.
It’s a work in process and related to the Levelling Plugin so we should pass on it for now.
There is a X for project (which you can’t close).
Can you post a picture so I can see what you are referring to? Thanks!
In regards of how you can close the Editor you can do it in 5 ways:
- from the Edit menu clickExit Editor
- from the Editor Tab in the bottom, clickExit Editor
- from the Toolbar, click the Red Exit button
- from the canvas context menu, click theExit Editoraction
- using the keys shortcut combo, pressCMD (Command)andS
Did not notice that V-Bit updates Dia on tool automatically
Where do you expect to see this behavior?
Best regards,
Marius -
PS: Don’t forget to click the
Basicbutton from time to time and therefore switch to Advanced mode where you will find a lot more features. Or in Preferences switch definitively to Advanced mode, in the General tab. -
reporter
I don’t think I understand… What next step? The flow is basically: load Gerber, process it somehow (Isolation, NCC, Paint etc) and therefore generate a Geometry Object, optionally edit the Geometry object, process it with the Milling Plugin, optionally edit the GCode, save GCode.
So when I click on the plugin I get a parameter window, fill the parameter and generate the next thing (e.g. from Gerbel → Geometry, Geometry → CNC Job). That panel is there until I close it and I could tweak the parameters and generate a new one.
However once the milling tab is gone there is no obvious way to know what parameters where in the tab that generated the CNC Job. Maybe it doesn’t even make sense, but it would make it easier to changes something and generate a variant (or replace the CNC Job).Maybe I’m thing this the wrong way. I think it would be practical to have something like a set of transformations:
T(Gerbel, Isolation[Params]) = Geometry_1
T(Geometry_1, Milling[Params]) = CNC Job.
So If I change the Gerbel or any of the two params I would update all the other objects. I don’t think how this works, but I feel it could make a simple flow..
On Mac all these tabs have X. I can even close the canvas. But some of the buttons do not work. I can’t close the project or Editor. Looking on your picture it seem that these X should not exist.
Another Mac oddity. The Cmd + Q should close the application, but for flatcam it opens the Print option. I need to click on the Close Window to terminate the applicaion.
-
Maybe it doesn’t even make sense, but it would make it easier to changes something and generate a variant (or replace the CNC Job).
However once the milling tab is gone there is no obvious way to know what parameters where in the tab that generated the CNC Job. Maybe it doesn’t even make sense, but it would make it easier to changes something and generate a variant (or replace the CNC Job).
Ok, I understand what you want. Said otherwise, you want that any changes in a Plugin, with a certain Application object (either Gerber, Excellon etc) loaded, should be saved in that object and when that object is used in another instance of that Plugin, the Plugin should load the parameters not from the default parameters as it does right now but from the Application object itself.
It’s an idea, I may implement it in the future versions of the app.But creating relations like inheritance between different objects therefore any change in a ‘father’ should trigger changes in it’s ‘children's’ is not on my table right now. Yet, who knows.
On Mac all these tabs have X. I can even close the canvas. But some of the buttons do not work. I can’t close the project or Editor. Looking on your picture it seem that these X should not exist.
The MacOS may do things differently and since I develop in Windows… This is how it should look like with latest changes in icons for the dark mode but the tabs are not changed. Some do have the closure button some do not.
Another Mac oddity. The Cmd + Q should close the application, but for flatcam it opens the Print option. I need to click on the Close Window to terminate the applicaion.
As you can see in the shortcuts list, I’ve assigned the
CTRL+Q(CMD+Qin MacOS?) to PDF Import Plugin.
Is this important enough so I can make an exception for the MacOS?
-
reporter
Concerning the chaining of creation I agree this could be a future things. There is a lot already in play and having a new version would be great.
I can try to see if I figure out how to get rid of the unwanted close tabs on the Mac. Some Qt6 coding could be interesting project. If you can point me in the direction of Tab reaction logic I can try to figure out how to get it removed.
Concerning Cmd+Q I’d say it’s important enough. Most apps respect this as it adheres to Human Interface Guidelines. I normally close thing using this (like Ctrl-F4 on Windows). The print is Cmd+P. This make flatcam hard to kill. Control+C on terminal does no do it (get intercepted), Cmd+Q gives you a dialog. You have to click on the Red close window bubble.
-
Concerning Cmd+Q I’d say it’s important enough.
I removed this assignment of
Ctr+Qshortcut combo to launching the PDF Import Plugin. Now it should work as expected in MacOS.The print is Cmd+P
I don’t know how this map in MacOS but in Windows, in the current state, by using the
Ctrl+Pshortcut combo it is triggered the functionality for saving as PDF (sort of printing).If you can point me in the direction of Tab reaction logic I can try to figure out how to get it removed.
I have to say currently it is working as expected in Windows. Any solution that is found have to make sure that there is no regression for the Windows users.
There is a custom class that distantly subclass the QTabWidget widget, called:
FCDetachableTab2, defined in theappGUi\GUIElements.pyfile.In
MainGUI.pyfile (in appGUI) folder there are two instances of this class:-
one for the notebook side (the left side of the app) which hold the tabs: Project, Properties and optionally, the Plugin tab. It is assigned to the
self.notebookproperty currently in line 971:python self.notebook = FCDetachableTab2(protect=True, protect_by_name=[_("Project"), _("Properties")], parent=self)* one for the plot are (the right side of the screen where the canvas is locate too) and which holds the tabs: Plot Area (Editor Area), Preferences, Bookmark Manager, Tools Database and some Editors. It is assigned to theself.plot_tab_areaproperty currently in line 1520:python self.plot_tab_area = FCDetachableTab2(protect=False, protect_by_name=[_('Plot Area')], parent=self)
As you can see there is a parameter which accepts a list, named
protect_by_name.
Any tab that belong to that custom TabWidget whose name is listed in that list, it’s protected in the sense that the default closure widget (the redX) is removed from those tabs.
As you can see above the tabs named: Project, Properties and Plot Area are protected and, at least in Windows, have the closure button removed therefore making them not-closable.Now, it is possible that the MacOS window manager handle those things differently and might force the presence of this button due of windows looking different in MacOS than in Windows.
The actual so-called protection is done in the parent class (FCDetachableTab from the same GuiElements.py file) in the
protectTab()method:def protectTab(self, currentIndex): # self.FCTabBar().setTabButton(currentIndex, QtWidgets.QTabBar.RightSide, None) self.tabBar.setTabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide, None)Here: https://forum.qt.io/topic/88393/hide-close-button-of-a-tab-in-qtabwidget/3 they suggest to also delete it but by adding that line I get some random errors.
So basically the question is if in MacOS thisQtWidgets.QTabBar.ButtonPosition.RightSidehas any meaning, maybe the close button is located (identified differently).By looking in the Qt code here: https://github.com/qt/qtbase/blob/a37dd93defd91b79fb6730d0ff0515a66a0d3972/src/widgets/widgets/qtabbar.cpp#L2337
it looks like it is possible that the close button can be located to the left so I just updated the above method to:def protectTab(self, currentIndex): # self.FCTabBar().setTabButton(currentIndex, QtWidgets.QTabBar.RightSide, None) self.tabBar.setTabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide, None) try: self.tabBar.setTabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.LeftSide, None) except Exception: passOtherwise, you could modify the method above like this (but as I said, I get random RunTime errors which do not crash the app but I much prefer not to have them):
def protectTab(self, currentIndex): self.tabBar.tabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide).deleteLater() try: self.tabBar.tabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide).deleteLater() except Exception: pass self.tabBar.setTabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide, None) try: self.tabBar.setTabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.LeftSide, None) except Exception: passYou could try this and report if those fix your problem.
-
-
reporter
Finally had some time to test this. The first change worked perfectly the X are gone and now the app behaves the same. Editor opens and can be closed by usual way.
The second one failed to load at all with an exception.
2022-05-08 12:59:50.958323 Traceback (most recent call last): File "/Users/tms/Development/FlatCam-8.995/FlatCAM.py", line 161, in <module> fc = App(qapp=app) File "/Users/tms/Development/FlatCam-8.995/appMain.py", line 1059, in __init__ self.ui = MainGUI(self) File "/Users/tms/Development/FlatCam-8.995/appGUI/MainGUI.py", line 1473, in __init__ self.notebook.protectTab(0) File "/Users/tms/Development/FlatCam-8.995/appGUI/GUIElements.py", line 3253, in protectTab self.tabBar.tabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide).deleteLater() AttributeError: 'NoneType' object has no attribute 'deleteLater'I’ll keep running with first one. Also if I want to track your branch which should I use? Also should we close this issue and start another about Mac “glitches” (if I find others).
-
The first change is already implemented in the
working_branchwhich currently is this: https://bitbucket.org/marius_stanciu/flatcam_beta/branch/Beta_8.995The second change looks like it is wrongly coded (late in night) it should have been:
# should see if there is a way to get where the button is placed and get rid of the too-general-exceptions def protectTab(self, currentIndex): # try to delete later the button, it does not work all the time so the need for try-except block try: self.tabBar.tabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.LeftSide).deleteLater() except Exception: pass try: self.tabBar.tabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide).deleteLater() except Exception: pass # remove the button by making it None, but we don't know if the system has a left-side o right-side button # so we use the try-except block try: self.tabBar.setTabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.RightSide, None) except Exception: pass try: self.tabBar.setTabButton(currentIndex, QtWidgets.QTabBar.ButtonPosition.LeftSide, None) except Exception: passSince the original problem looks to be fixed, correctly we need this issue closed.
-
reporter
This last version works, but out of curiosity I added print to the exception handling. They all fail with the exception
'NoneType' object has no attribute 'deleteLater'So I wonder if it’s worth adding this option. If it has effect on other platform it masks sense. Otherwise I would not add this.
-
I don’t use the
deleteLater()method but I also don't know the quirks in MacOS window manager so I thought they might be useful in some cases, I saw them used in some code examples. As you see I did not include those lines in the code so I agree that those should be left out. It’s good that it worked in the end, by removing the left button. -
reporter
- changed status to resolved
Original questions were addressed.
- Log in to comment
Hello Thomas,
Thank you for your report! Let see what is the issue.
Can you please quote here those comments? FlatCAM beta 8.994 Isolation works but there were some issues in the sense that the GRBL users reported that they had a problem with the fact that I forced a tool change command in the GCode even when the tool change was not used therefore always adding a
Tx…M6GCode section which created problems for GRBL firmware.
Don’t worry about that. It is true that I prefer to use chemicals to make my own PCB's (most are dual layer, via-plated, tinned and sometimes adding soldermask/silkscreen) but that does not mean that I do not fix issues when I find them. I maintain FlatCAM beta in all aspects since I created this fork of FlatCAM.
It will help if you can post the settings that you have used in the Isolation Tool (Plugin).
Due of the conical shape of the V-bits, the deeper you mill inside the PCB the larger is the cut width so this is as expected.
To get and idea, for a cylindrical end mill, for which the cut width is the same regardless of the depth of cut, setting an isolation of 0.1mm it means that the cut width is 0.1mm at say 0.05mm depth of cut (Z=-0.05mm).
For a V-bit with the tip diameter of 0.1mm and a tip angle of 30º cutting at 0.05mm (Z=-0.05mm) the cut width is 0.1268mm therefore the effective tool diameter that should be used in the Isolation Tool (plugin) needs to be this value of 0.1268mm.
Test case.
Isolating a Gerber trace with 0.1mm thickness and 10mm long. We set the tool diameter to 0.1268mm because we use a V bit with tip diameter of 0.1mm and tip angle of 30º.
Using the Calculator Plugin we get this value of 0.1268mm.
We set the Isolation Plugin like this:
On the Geometry object that is generated by Isolation we are using the following parameters:
We can see that the Isolation leave the trace to be at exactly 0.1mm so it does not byte from the copper, at least as much as the visualization let us see.
There are some expected interpolation errors due of the translation of a circular area to a sequence of lines but that should not be much.
And we get this isolation GCode:
Most of it is made out of the lines that make the circular ends, and it’s not that easy to evaluate those sections, so we will focus on the horizontal moves.
We know that the isolation is done at half the cut width, therefore we should see that the isolation is done at 0.1268 / 2 = 0.0634mm therefore for the horizontal moves (one above, one below) the Y should be:
- for the move at the top Y should be: Y = 10mm + 0.05mm + 0.0634mm = 10.1134mm
- for the move at the bottom Y should be: Y = 10mm - 0.05mm - 0.0634mm = 9.8866 mm
The above are calculated:
10mm → it is the Y were the trace is placed.
0.05mm → it is half the trace width.
0.0634 → it is half of the used tool diameter (cut width) which is the cut width that a V-bit with 0.1mm tip diameter and 30º tip angle has when cutting at -0.05mm cut depth.
If we look in the generated GCode, the lines where the bottom horizontal move is done are:
where we see that the Y is …. 9.8866mm. Which is exactly what we calculated above, the expected values.
The lines where the top horizontal move is done are:
where we see that the Y value is 10.1134 mm which again it is identical with what we have calculated above.
Conclusion: we can safely rule out any software calculation issues (or bug) in the isolation.