Re: [Kicad-developers] [Bug 1176915] Re: problem with gerber files
Le 06/05/2013 22:01, Lorenzo Marcantonio a écrit : On Mon, May 06, 2013 at 03:09:12PM -0400, Wayne Stambaugh wrote: is the case. My guess that the units for linewidth plot setting is either mils or decimils. I don't think we ever intended for nanometer values to be saved in files. If I knew what units the linewidth setting is supposed to be, the fix would be easy. The comment in the header file doesn't specify the units. Other plot widths are in decimils, the default plot line width is copied by default from the global line width which is in BIU (from whence BIUs were decimils). The easiest way out would be storing the default plot width in decimils (breaking existing files, not really a tragic thing); the clean solution would be passing the unit for the current file to the pcb option parser and doing there the conversion. I'd vote for decimils plot line width. In fact the default width is only used for the sheet border, all the other stuff has default widths. linewidth plot setting is stored in file in BIU (should not, because all values are stored in mm (and very few in mils), no more in decimils). It is constrained in pcb_plot_params (PCB_PLOT_PARAMS::SetLineWidth), but the minimal value is 0. Perhaps this minimal value is a bad choice. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [Bug 1176915] Re: problem with gerber files
On Tue, May 07, 2013 at 11:20:00AM +0200, jp charras wrote: linewidth plot setting is stored in file in BIU (should not, because all values are stored in mm (and very few in mils), no more in decimils). It somehow escaped to the BIU transition... whatever choice we do probably old breaks; however it's not a tragic loss, since it's only a plot preference. It is constrained in pcb_plot_params (PCB_PLOT_PARAMS::SetLineWidth), but the minimal value is 0. Perhaps this minimal value is a bad choice. Something like 0,01 mm would be probably a saner choice; however the problem in generating gerber is fixed, it remains only to decide what is the 'right' unit to use for the external representations. I'd like to go away from decimils but other stuff in the plot infrastructure continues to use it anyway... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Option for gerber metric numeric formats
I had to done this for some *idiotic* people which needs gerbers in
millimeters. Could help in some extreme DRC situation on the fabrication
side, I don't know... or maybe to raise precision (even if I don't think
current technology can achieve over than one decimil there are 12000 dpi
photoplotter out there... what are they used for?)
In practice:
- Call the 'SetFormat' of the gerber plotter. You can ask for
metric/imperial and select the number of digits. See example in the
last hunk of the patch
- Enjoy. No really, there's nothing else. Also the default is the same
imperial 3.4 we are already using.
If someone in his spare time wants to add the controls in the
UI/scripting layer maybe it can be useful; I'll just put it here if
someone want or need it.
--
Lorenzo Marcantonio
Logos Srl
=== modified file 'common/common_plotGERBER_functions.cpp'
--- common/common_plotGERBER_functions.cpp 2013-05-06 18:34:14 +
+++ common/common_plotGERBER_functions.cpp 2013-05-07 12:34:25 +
@@ -26,7 +26,14 @@
wxASSERT( aScale == 1 );
plotScale = 1;
m_IUsPerDecimil = aIusPerDecimil;
-iuPerDeviceUnit = 1.0 / aIusPerDecimil;
+
+/* The pow add or removes decimal digits as required (decimils
+ * are the same as 4 imperial decimal figures) */
+if( m_metric )
+iuPerDeviceUnit = 25.4 / (aIusPerDecimil * pow( 10, 4-m_decimalFigures
) );
+else
+iuPerDeviceUnit = 1.0 / (aIusPerDecimil * pow( 10, 4-m_decimalFigures
) );
+
/* We don't handle the filmbox, and it's more useful to keep the
* origin at the origin */
paperSize.x = 0;
@@ -41,9 +48,8 @@
*/
void GERBER_PLOTTER::emitDcode( const DPOINT pt, int dcode )
{
-
fprintf( outputFile, X%dY%dD%02d*\n,
- int( pt.x ), int( pt.y ), dcode );
+ KiROUND( pt.x ), KiROUND( pt.y ), dcode );
}
/**
@@ -71,17 +77,26 @@
fprintf( outputFile, G04 (created by %s) date %s*\n,
TO_UTF8( Title ), TO_UTF8( DateAndTime() ) );
-/* Mass parameter: unit = INCHES */
-fputs( %MOIN*%\n, outputFile );
-
-/* Set coordinate format to 3.4 absolute, leading zero omitted */
-fputs( G04 Gerber Fmt 3.4, Leading zero omitted, Abs
format*\n%FSLAX34Y34*%\n,
- outputFile );
-
-/* Specify linear interpol (G01), unit = INCH (G70), abs format (G90) */
-fputs( G01*\nG70*\nG90*\n, outputFile );
+// Unit mode, coordinate format, absolute mode, leading zero omitted
+fprintf( outputFile,
+%%MO%s*%%\n
+G04 %s Gerber Fmt %d.%d, Leading zero omitted, Abs format*\n
+%%FSLAX%d%dY%d%d*%%\n,
+m_metric ? Metric : Imperial,
+m_metric ? MM : IN,
+m_integerFigures, m_decimalFigures,
+m_integerFigures, m_decimalFigures,
+m_integerFigures, m_decimalFigures );
+
+/* Specify linear interpol (G01), unit = INCH (G70) or MM (G71), abs
format (G90)
+ single quadrant mode (G74) (strongly recommended by the specs) */
+fprintf( outputFile, G01*\nG%d*\nG90*\nG74*\n, m_metric ? 71 : 70 );
+
+/* This is the marker for the insertion of the list during the
+ second pass */
fputs( G04 APERTURE LIST*\n, outputFile );
-/* Select the default aperture */
+
+// Select the default aperture
SetCurrentLineWidth( -1 );
return true;
@@ -202,8 +217,7 @@
for( std::vectorAPERTURE::iterator tool = apertures.begin();
tool != apertures.end(); tool++ )
{
-const double fscale = 0.0001f * plotScale
- * iuPerDeviceUnit ;
+const double fscale = userToDeviceSize( 1 ) * pow( 10,
-m_decimalFigures );
char* text = cbuf + sprintf( cbuf, %%ADD%d, tool-DCode );
/* Please note: the Gerber specs for mass parameters say that
@@ -309,7 +323,7 @@
fprintf( outputFile, G03 );
else
fprintf( outputFile, G02 );
-fprintf( outputFile, X%dY%dI%dJ%dD01*\n, int( devEnd.x ), int( devEnd.y
),
+fprintf( outputFile, X%dY%dI%dJ%dD01*\n, KiROUND( devEnd.x ), KiROUND(
devEnd.y ),
int( devCenter.x ), int( devCenter.y ) );
fprintf( outputFile, G74*\nG01*\n ); // Back to single quadrant and
linear interp.
}
=== modified file 'include/plot_common.h'
--- include/plot_common.h 2013-05-05 10:01:44 +
+++ include/plot_common.h 2013-05-07 07:21:52 +
@@ -760,6 +760,24 @@
workFile = 0;
finalFile = 0;
currentAperture = apertures.end();
+
+// Default format: imperial, 3.4 format
+m_metric = false;
+m_integerFigures = 3;
+m_decimalFigures = 4;
+}
+
+/**
+ * Gerber specific: set the output format in metric mode (default is
+ * imperial i.e. inches).
+ * Call this *before* setting the viewport!
+ * Note that the conversion is done thru an int, so ifig+dfig digits have
+ * to fit in the dynamic range of 2^32 */
+void SetFormat( bool metric, int
Re: [Kicad-developers] Regression Testing
On 7 May 2013 13:51, Dick Hollenbeck d...@softplc.com wrote: On 05/06/2013 04:36 PM, Brian Sidebotham wrote: This turned into just a set of notes about CTest and Boost.Test: CTest integrates well with CMake [1] and allows us to run executables that perform tests. Each test can be set as required (to be passed) or not. The result of each test is based on a rule that is defined in the each tests properties. For example, the integer return code from a process can be tested, or a regex match can be performed on stdout or stderr for the test process. Simple tests that depend on the integer return code of a process can be done via CMake's execute_process by checking RESULT_VARIABLE. Using the process return code, both CTest and CMake can test python API changes by executing python scripts and checking python's return value. The Boost.Test framework provides easy methods for writing C++ test cases as executables. A single executable can contain as many tests as required. Each test is called individually as a command line argument. The Boost.Test framework can work by returning a different integer return code from the executable depending on the result of a test. It is has some additional features which aid automatic regression testing (for example on build servers and the like) [2] Writing test cases using the Boost.Test framework provides an easy way to test WorkerFunctions within the codebase as we can write test cases and link them to the classes we're testing. This really requires code to be more modular so that we can link test executables against libraries. CTest and Boost.Test can allow memory leak testing as CTest integrates well with Purify or Valgrind. CTest allows subsets of tests to be run, so if you know you've only been working on a certain part of the codebase, you can quickly run just the tests that should be affected by your changes before running the whole test suite. The Python API requires test cases for stability so we know that our changes to the C++ code do not break other peoples IP based on our Python API. Thanks very much. I probably will not have much input into this decision moving forward. How is the wxPython build script coming for Windows? Hi Dick, I am going to cmake-ify wxPython to build it (I will maintain a patch, and hope wxPython will accept it), as I want to get rid of distutils which is really very broken for MinGW. Building wxPython is actually relatively straight forward, but there are a lot of options which translate to wxWidgets build options which need covering in cmake. This work isn't yet off the ground. I'm currently working on the NSIS packaging of python-a-mingw-us. At the moment it looks like we'll have to use an 8-bit colour BMP for the logo which doesn't look great. There seems to be some peculiarities with the BMP format used by makensis because if it is anything other than an 8-bit BMP the logo doesn't get displayed. I have read a lot of posts that sort-of relate to this, but most end up building the windows installer on a windows machine and this limitation doesn't then appear to exist. Anyway, I have the installer pretty much up and running. I'd like to email you a diff to review before committing, just to make sure you're happy with what I've done. I'll email a patch tonight. I had to rename one of the installable components because the name is directly used as a variable name in the nsis script, and a few other things too in order to get the packaging to work. I think everything except the headers component is a required installation component. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Include Boost installation instructions in build-msw.txt?
On 6 May 2013 13:34, Dick Hollenbeck d...@softplc.com wrote: On 05/06/2013 02:28 AM, Travis Ayres wrote: Hi everyone, I'm following along with build-msw.txt; should simple instructions for boost be included? Installing Boost with MinGW (so far) is a bit of a pain, and it could save people some time. The rest of the instructions were well written and concise. I'm even thinking it might be useful to include some info on doxygen and how to setup something like Code::Blocks for KiCad. I'm in the process of figuring all this out anyway - I could document it if there's any interest? Code blocks might make you a nice editor and a nice debugger. But our build system is CMake, and that is unlikely to ever change. Travis, CMake has a CodeBlocks generator (-G CodeBlocks - MinGW Makefiles) - in fact it is used by KiCad-Winbuilder because it generates a CodeBlocks project file and GNU Makefile. KiCad-Winbuilder just uses the Makefile direct, but I personally tend to use CodeBlocks for code development so the project file is there. So big-up CMake again! :D Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] layer based constraints
I have worked a bit more on the idea of the “layer based constraints”. We have already argued quite a bit about how one should tell KiCad about different constraints on different layers. But I think, we all more or less agree that there are realistic use cases where a constraint is not only dependent on the net, but also on the layer (and maybe other things). So, the routine getConstraint() (with or without an ‘other’ item passed as argument) should get another argument: LAYER_NUM aLayer, because, as soon as the layer, in one way or the other, influences the minimal acceptable clearance between different nets, I have to distinguish between these nets. For all these connectedItems that are only on one layer (like tracks), the item can just check on which layer it is, and return the appropriate value. But there are also pads and vias. And here, it is not sufficient anymore to just ask “what is the miminal clearance around you”? Instead, I have to ask: What is the minimal clearance around you on layer two?” That’s why I inserted the additional argument aLayer. Of course, I included it on all connectedItems because of subtyping. A track, for example, just ignores it and takes its own layer as a reference. Ok, then, I did another thing: ConnectedItems can show their clearance as a line around the item, which is one of the best features of KiCad, if you ask me. I LOVE this feature! But now, I had a problem with it. Again, if an item is on only one layer, it’s fine. Just show the clearance according to the layer of the track. But what about a pad? A pad can “sit” on all layers. So, which clearance to show? Possible anwers: - none - the net-based clearance (only feasable if we ARE separating net-based and layer-based clearances, and not mixing them in any way) - all clearances, in the respective color - the clearance according to the layer that is currently active, if it is a copper layer, and none if it is a non-copper layer. I, for my personal branch, decided to pick the last solution. But this confronted me with another question: If I am on layer two, and there is a multi-layer pad, a track on layer two and a track on layer one. What do I expect to see? I decided that I would like to see the clearances on layer two. Nothing else. So, the pad shows me the clearance it has on layer two. And the pad, that is on layer two, shows me its clearance, and the track on layer shows no clearance line. I hacked this behavior and must say that I like it. I never checkt “always” at “show tracks clearances”, because it was just too much information. But with my patch, I now think I’m going to stay at this option. It shows my all clearances I have to respect on the layer that is currentla active (a.e. the layer on which I am placing tracks at the moment). After all, I don’t care about a layer two’s clearance if I’m on layer one. I will upload a branch eventually so you guys can have a look at it. Not so much to press my implementation of it into a release (there's no chance for it, either ;-), but more to let you get a feeling of it, because I really think this is an issue. I think, a good CAE tool should take the layer into account when it comes to constraints. And as KiCad IS a very good tool, it is proven by induction, that KiCad should be able to handle this! :-) Just kidding Now, there are still other things, like, for example, constraints between two defined nets, area based constraints... all the fancy stuff. Of course, we could add also these things as additional parameters... or we could pass an object containing all important parameters an item has to know to calculate the clearance. Or... hmmm... just a reference to the caller item: - Item xy, tell me, please, how much clearance I have to keep to you. I am item yz. - Item yz, on what layer are you? And what’s your net? - Ok, Item xy, please stay 2mm away from me. Oh, I almost forgot: There is another thing that, as I suppose, is quite connected to this issue: Pads with defined pad-stacks. Say, I want to insert a pad on the outer layers, but on the inner layers, there should be no copper (or less copper). This surely influences the clearance. Again, the clearance strongly depends on the layer on which I am approaching the pad. What do you think? Is this worth a blue-print? I really really like the idea of implementing such a thing. I am, actually, now starting to work productively with my patch (but only as a hobbyist) and up to now, I really like also the slightly changed look-and-feel as described above. - I can define clearance and width constraints for every layer (which is, as I said, very useful to me because of manufactuer’s constraints) - I am shown all clearances (max of net-based and layer based) on the active layer - when I place a track with the “standard” thickness setting, it gets me the actual thickness of the net on the layer I am. - When I switch layers (a.e. place a via)
Re: [Kicad-developers] Regression Testing
On 5/7/2013 9:01 AM, Brian Sidebotham wrote: On 7 May 2013 13:51, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: On 05/06/2013 04:36 PM, Brian Sidebotham wrote: This turned into just a set of notes about CTest and Boost.Test: CTest integrates well with CMake [1] and allows us to run executables that perform tests. Each test can be set as required (to be passed) or not. The result of each test is based on a rule that is defined in the each tests properties. For example, the integer return code from a process can be tested, or a regex match can be performed on stdout or stderr for the test process. Simple tests that depend on the integer return code of a process can be done via CMake's execute_process by checking RESULT_VARIABLE. Using the process return code, both CTest and CMake can test python API changes by executing python scripts and checking python's return value. The Boost.Test framework provides easy methods for writing C++ test cases as executables. A single executable can contain as many tests as required. Each test is called individually as a command line argument. The Boost.Test framework can work by returning a different integer return code from the executable depending on the result of a test. It is has some additional features which aid automatic regression testing (for example on build servers and the like) [2] Writing test cases using the Boost.Test framework provides an easy way to test WorkerFunctions within the codebase as we can write test cases and link them to the classes we're testing. This really requires code to be more modular so that we can link test executables against libraries. CTest and Boost.Test can allow memory leak testing as CTest integrates well with Purify or Valgrind. CTest allows subsets of tests to be run, so if you know you've only been working on a certain part of the codebase, you can quickly run just the tests that should be affected by your changes before running the whole test suite. The Python API requires test cases for stability so we know that our changes to the C++ code do not break other peoples IP based on our Python API. You pretty much came to the same conclusion I did when I looked at this. Use CTest to build, run, and manage the tests and use the Boost unit test framework to write the tests. It might be a good idea to set up a separate branch on Launchpad until we have a workable testing framework in place and then merge that into the testing branch. I also want to make sure we have a reasonable set of expectations that we can either add to the coding policy or create a separate test policy before we make it available for general consumption. Thanks very much. I probably will not have much input into this decision moving forward. How is the wxPython build script coming for Windows? Hi Dick, I am going to cmake-ify wxPython to build it (I will maintain a patch, and hope wxPython will accept it), as I want to get rid of distutils which is really very broken for MinGW. Building wxPython is actually relatively straight forward, but there are a lot of options which translate to wxWidgets build options which need covering in cmake. This work isn't yet off the ground. I apologize for not being able to help with CMake-ifying wxPython. I've been busy and the footprint library table code is proving to be way more work than I had planned. Thank you for taking the lead on this. Best Wishes Wayne I'm currently working on the NSIS packaging of python-a-mingw-us. At the moment it looks like we'll have to use an 8-bit colour BMP for the logo which doesn't look great. There seems to be some peculiarities with the BMP format used by makensis because if it is anything other than an 8-bit BMP the logo doesn't get displayed. I have read a lot of posts that sort-of relate to this, but most end up building the windows installer on a windows machine and this limitation doesn't then appear to exist. Anyway, I have the installer pretty much up and running. I'd like to email you a diff to review before committing, just to make sure you're happy with what I've done. I'll email a patch tonight. I had to rename one of the installable components because the name is directly used as a variable name in the nsis script, and a few other things too in order to get the packaging to work. I think everything except the headers component is a required installation component. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe :
Re: [Kicad-developers] layer based constraints
If this feature would work neither with freerouter, nor Cern's push and shove router, then it would be useless to me. fair enough. Of course it has to be consistent with the whole package! I currently use freerouter in ps mode exclusively, never route in kicad. what? Actually, I've always seen freerouter just as an autorouter (and I don't like autorouters). I never had the idea to manually route with it. Will try this eventually. I think I have seen that freerouter doesn't know layer constraints, but you can tell net classes to be valid on certain layers. I personally still think, my way is the better one. :-) But that's not the point. Because also in this way, as I said, Kicad's constraint handler should be aware of the different layers implement what freerouter does. Tom, if he had time might comment on the likelihood of support for something like this in his ps work for internal pcbnew. Looking forward to that. But acually I don't think there will be a problem. I think, Tom will just ask about clearances and do some (very complex) stuff to avoid violations. How these clearances are calculated, I's suppose, is not of interest to Tom's PS router. Or am I wrong? On 05/07/2013 11:30 AM, Simon Huwyler wrote: I have worked a bit more on the idea of the “layer based constraints”. We have already argued quite a bit about how one should tell KiCad about different constraints on different layers. But I think, we all more or less agree that there are realistic use cases where a constraint is not only dependent on the net, but also on the layer (and maybe other things). So, the routine getConstraint() (with or without an ‘other’ item passed as argument) should get another argument: LAYER_NUM aLayer, because, as soon as the layer, in one way or the other, influences the minimal acceptable clearance between different nets, I have to distinguish between these nets. For all these connectedItems that are only on one layer (like tracks), the item can just check on which layer it is, and return the appropriate value. But there are also pads and vias. And here, it is not sufficient anymore to just ask “what is the miminal clearance around you”? Instead, I have to ask: What is the minimal clearance around you on layer two?” That’s why I inserted the additional argument aLayer. Of course, I included it on all connectedItems because of subtyping. A track, for example, just ignores it and takes its own layer as a reference. Ok, then, I did another thing: ConnectedItems can show their clearance as a line around the item, which is one of the best features of KiCad, if you ask me. I LOVE this feature! But now, I had a problem with it. Again, if an item is on only one layer, it’s fine. Just show the clearance according to the layer of the track. But what about a pad? A pad can “sit” on all layers. So, which clearance to show? Possible anwers: - none - the net-based clearance (only feasable if we ARE separating net-based and layer-based clearances, and not mixing them in any way) - all clearances, in the respective color - the clearance according to the layer that is currently active, if it is a copper layer, and none if it is a non-copper layer. I, for my personal branch, decided to pick the last solution. But this confronted me with another question: If I am on layer two, and there is a multi-layer pad, a track on layer two and a track on layer one. What do I expect to see? I decided that I would like to see the clearances on layer two. Nothing else. So, the pad shows me the clearance it has on layer two. And the pad, that is on layer two, shows me its clearance, and the track on layer shows no clearance line. I hacked this behavior and must say that I like it. I never checkt “always” at “show tracks clearances”, because it was just too much information. But with my patch, I now think I’m going to stay at this option. It shows my all clearances I have to respect on the layer that is currentla active (a.e. the layer on which I am placing tracks at the moment). After all, I don’t care about a layer two’s clearance if I’m on layer one. I will upload a branch eventually so you guys can have a look at it. Not so much to press my implementation of it into a release (there's no chance for it, either ;-), but more to let you get a feeling of it, because I really think this is an issue. I think, a good CAE tool should take the layer into account when it comes to constraints. And as KiCad IS a very good tool, it is proven by induction, that KiCad should be able to handle this! :-) Just kidding Now, there are still other things, like, for example, constraints between two defined nets, area based constraints... all the fancy stuff. Of course, we could add also these things as additional parameters... or we could pass an object containing all important parameters an item has to know to calculate the clearance. Or... hmmm... just a reference to the caller item: - Item
Re: [Kicad-developers] layer based constraints
On 05/07/2013 04:06 PM, Simon Huwyler wrote: If this feature would work neither with freerouter, nor Cern's push and shove router, then it would be useless to me. fair enough. Of course it has to be consistent with the whole package! I currently use freerouter in ps mode exclusively, never route in kicad. what? Actually, I've always seen freerouter just as an autorouter (and I don't like autorouters). I never had the idea to manually route with it. Will try this eventually. Page 17 of the specctra.pdf file I sent you a couple of weeks ago shows the class_descriptor. It would be a simple matter for you to test whether freerouter supports this by hand editing a *.DSN file after it was exported by pcbnew. Add some layer_rule_descriptor stuff or similar in there to see if freerouter does support layer based constraints. If it does, you can gather more support from folks that way to help you. Currently, I would not oppose your efforts, but would not sponsor them. I may not sponsor them even after freerouter compatibility is verified, but I could cheer lead. Dick I think I have seen that freerouter doesn't know layer constraints, but you can tell net classes to be valid on certain layers. I personally still think, my way is the better one. :-) But that's not the point. Because also in this way, as I said, Kicad's constraint handler should be aware of the different layers implement what freerouter does. Tom, if he had time might comment on the likelihood of support for something like this in his ps work for internal pcbnew. Looking forward to that. But acually I don't think there will be a problem. I think, Tom will just ask about clearances and do some (very complex) stuff to avoid violations. How these clearances are calculated, I's suppose, is not of interest to Tom's PS router. Or am I wrong? On 05/07/2013 11:30 AM, Simon Huwyler wrote: I have worked a bit more on the idea of the “layer based constraints”. We have already argued quite a bit about how one should tell KiCad about different constraints on different layers. But I think, we all more or less agree that there are realistic use cases where a constraint is not only dependent on the net, but also on the layer (and maybe other things). So, the routine getConstraint() (with or without an ‘other’ item passed as argument) should get another argument: LAYER_NUM aLayer, because, as soon as the layer, in one way or the other, influences the minimal acceptable clearance between different nets, I have to distinguish between these nets. For all these connectedItems that are only on one layer (like tracks), the item can just check on which layer it is, and return the appropriate value. But there are also pads and vias. And here, it is not sufficient anymore to just ask “what is the miminal clearance around you”? Instead, I have to ask: What is the minimal clearance around you on layer two?” That’s why I inserted the additional argument aLayer. Of course, I included it on all connectedItems because of subtyping. A track, for example, just ignores it and takes its own layer as a reference. Ok, then, I did another thing: ConnectedItems can show their clearance as a line around the item, which is one of the best features of KiCad, if you ask me. I LOVE this feature! But now, I had a problem with it. Again, if an item is on only one layer, it’s fine. Just show the clearance according to the layer of the track. But what about a pad? A pad can “sit” on all layers. So, which clearance to show? Possible anwers: - none - the net-based clearance (only feasable if we ARE separating net-based and layer-based clearances, and not mixing them in any way) - all clearances, in the respective color - the clearance according to the layer that is currently active, if it is a copper layer, and none if it is a non-copper layer. I, for my personal branch, decided to pick the last solution. But this confronted me with another question: If I am on layer two, and there is a multi-layer pad, a track on layer two and a track on layer one. What do I expect to see? I decided that I would like to see the clearances on layer two. Nothing else. So, the pad shows me the clearance it has on layer two. And the pad, that is on layer two, shows me its clearance, and the track on layer shows no clearance line. I hacked this behavior and must say that I like it. I never checkt “always” at “show tracks clearances”, because it was just too much information. But with my patch, I now think I’m going to stay at this option. It shows my all clearances I have to respect on the layer that is currentla active (a.e. the layer on which I am placing tracks at the moment). After all, I don’t care about a layer two’s clearance if I’m on layer one. I will upload a branch eventually so you guys can have a look at it. Not so much to press my implementation of it into a release
Re: [Kicad-developers] layer based constraints
A short google consultation showed me this: SPECCTRA FOR ORCAD AUTOROUTER SPECCTRA for OrCAD is well known for its comprehensive feature set. The extensive rule set can control a wide range of constraints from default board-level rules to rules by net and net class. default board-level rules sounds to me like something like this. But unfortunately I didn't find anything yet, and since it's twenty past one I'll call it a day for now. :-) Dick, could you tell me where I can find this pdf? Thanks! -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Wednesday, May 08, 2013 1:09 AM To: Dick Hollenbeck Cc: kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints Page 17 of the specctra.pdf file I sent you a couple of weeks ago shows the class_descriptor. What PDF file? I didn't get any. But of course I should find some information about this. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] layer based constraints
Load source specctra_import.cpp. In the comments near the top, look for specctra.pdf. tells where. On May 7, 2013 6:20 PM, Simon Huwyler simon.huwy...@bluewin.ch wrote: A short google consultation showed me this: SPECCTRA FOR ORCAD AUTOROUTER SPECCTRA for OrCAD is well known for its comprehensive feature set. The extensive rule set can control a wide range of constraints from default board-level rules to rules by net and net class. default board-level rules sounds to me like something like this. But unfortunately I didn't find anything yet, and since it's twenty past one I'll call it a day for now. :-) Dick, could you tell me where I can find this pdf? Thanks! -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Wednesday, May 08, 2013 1:09 AM To: Dick Hollenbeck Cc: kicad-developers@lists.**launchpad.netkicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints Page 17 of the specctra.pdf file I sent you a couple of weeks ago shows the class_descriptor. What PDF file? I didn't get any. But of course I should find some information about this. __**_ Mailing list: https://launchpad.net/~kicad-**developershttps://launchpad.net/~kicad-developers Post to : kicad-developers@lists.**launchpad.netkicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-**developershttps://launchpad.net/~kicad-developers More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
