pcb2gcode-devel — PCB to Gcode - Developers

Re: [Pcb2gcode-devel] Start designing feature

[Lionel S. C. <lio...@gm...>]

Hi all

It is not all released yet, but it is under progress.
A m4 output is generated, and three interpreters are developped:
One gives gerber output, then toolpath can be compared with original gerber
in gerbv.
One gives gcode, so m4 data can be compared with original gcode data
One gives hpgl, because my main purpose is to run my lpkf mill.


Others features are developped :
Data is compacted (horizontal and vertical lines are joined together)
Toolpath can be reversed (becaus I want to mill stencils, not pcb)

One feature is still missing for me : internal contour.

I propose a major change in pcb2gcode. I would like to get_toolpath without
growing.
Then grow the vector data (not the pixel data)
This way internal, external contour will be easier.
I think it could be possible to detect arcs and lines in simplifypath, and
growing lines and arcs is not so hard I think. Detecting collisions on the
grown toolpath may be easy too. (today the way pcb2gcode is implemented
distorts the oblic and round path).

Well, some is done and some is a dream. Let's see what happens in the future

SY


Lionel SAINTE CLUQUE
adresse:
1, rue Paul de KOCK
92500 Rueil Malmaison
Téléphone +33 (0)6 18 04 20 75

2015-02-17 17:11 GMT+01:00 Nicola Corna <ni...@co...>:

> > Has there been any thought to moving the code to github or just
> > deprecating the sourceforge repo and making yours the new "official"
> > repo? Github Issues would also be a good way to stay on top of bugs, new
> > features and PRs that could involve people who aren't subscribed to this
> > mailing list (that sourceforge packs with ads). Is the project getting
> > any value out of Sourceforge?
>
> I agree. I've just moved the repo on GitHub, here it is
> https://github.com/pcb2gcode/pcb2gcode
>
> Nicola Corna
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel
>

Re: [Pcb2gcode-devel] m4 function

[Lionel S. C. <lio...@gm...>]

Well I did 90% of what you said but instead of forking/pushing I sent you a
patch.

I can fork today.

Thanks

Lionel SAINTE CLUQUE
adresse:
1, rue Paul de KOCK
92500 Rueil Malmaison
Téléphone +33 (0)6 18 04 20 75

2015-04-19 9:51 GMT+02:00 <ni...@co...>:

> If you don't know how to use git just fork the official repository (
> https://github.com/pcb2gcode/pcb2gcode), clone it on your computer (git
> clone <link>), apply your modifications, do a git add <files> of the
> modified files, git commit and a git push. After that open a pull request,
> so I can review the code and comment it.
>
> Nicola Corna
>
> April 19 2015 5:30 AM, "Lionel Sainte Cluque" <lio...@gm...> wrote:
> > Dear all
> >
> > As I told you I was interested in some features that are not currently
> in pcb2gcode.
> >
> > The first feature I was interested in, was to easilly expand or tune
> output languages and output
> > flavours. I was especially lacking a gerber output.
> > You may wander why I want a gerber to gerber translator ? The reason is
> that I want to easilly
> > control pcb2gcode behaviour, which is to my eyes necessary both for
> debug and for regular usage.
> > To get flexibilty in outputs I added a m4 output to pcb2gcode, a m4
> template (gerberonly by now,
> > but gcode and hpgl may follow) and a shell script to manage it.
> >
> > I am not sur on how to implement the autolovel feature (what is it?)
> >
> > I am  not a good GNU programmer. I don't know how to manage path in the
> shell script. I don't know
> > how to write the make install neither. I don't know a smart way to give
> you the source code to
> > review it. I tried a git patch, but it is pretty new to me, I hope it is
> ok.
> >
> > To test :
> >
> > First : get sources from git, patch, configure and make
> >
> > update : path in pcb2gcode.sh (first line should be enough)
> > move to : testing/gerbv_example/(the directory you prefer)
> > use : ../../../pcb2gcode.sh
> >
> > I hope it will be interesting/usefull for you too.
> >
> > Comments are welcome
> > Lionel SAINTE CLUQUE
> > adresse:
> > 1, rue Paul de KOCK
> > 92500 Rueil Malmaison
> > Téléphone +33 (0)6 18 04 20 75
>

Re: [Pcb2gcode-devel] m4 function

[<ni...@co...>]

If you don't know how to use git just fork the official repository (https://github.com/pcb2gcode/pcb2gcode), clone it on your computer (git clone <link>), apply your modifications, do a git add <files> of the modified files, git commit and a git push. After that open a pull request, so I can review the code and comment it.

Nicola Corna

April 19 2015 5:30 AM, "Lionel Sainte Cluque" <lio...@gm...> wrote:
> Dear all
> 
> As I told you I was interested in some features that are not currently in pcb2gcode.
> 
> The first feature I was interested in, was to easilly expand or tune output languages and output
> flavours. I was especially lacking a gerber output.
> You may wander why I want a gerber to gerber translator ? The reason is that I want to easilly
> control pcb2gcode behaviour, which is to my eyes necessary both for debug and for regular usage.
> To get flexibilty in outputs I added a m4 output to pcb2gcode, a m4 template (gerberonly by now,
> but gcode and hpgl may follow) and a shell script to manage it.
> 
> I am not sur on how to implement the autolovel feature (what is it?)
> 
> I am  not a good GNU programmer. I don't know how to manage path in the shell script. I don't know
> how to write the make install neither. I don't know a smart way to give you the source code to
> review it. I tried a git patch, but it is pretty new to me, I hope it is ok.
> 
> To test :
> 
> First : get sources from git, patch, configure and make
> 
> update : path in pcb2gcode.sh (first line should be enough)
> move to : testing/gerbv_example/(the directory you prefer)
> use : ../../../pcb2gcode.sh
> 
> I hope it will be interesting/usefull for you too.
> 
> Comments are welcome
> Lionel SAINTE CLUQUE
> adresse:
> 1, rue Paul de KOCK
> 92500 Rueil Malmaison
> Téléphone +33 (0)6 18 04 20 75

Re: [Pcb2gcode-devel] m4 function

[Lionel S. C. <lio...@gm...>]

commit e8354170dffa5dc843454f461ff26642e83422ed
Author: Lionel SC <co...@di...>
Date:   Sun Apr 19 05:28:24 2015 +0200

    Add m4 output and the first m4 template (gerber.m4)
    Probably not perfect, but it does the job

diff --git a/m4_exporter.cpp b/m4_exporter.cpp
new file mode 100644
index 0000000..43474d5
--- /dev/null
+++ b/m4_exporter.cpp
@@ -0,0 +1,302 @@
+/*!\defgroup M4_EXPORTER*/
+/******************************************************************************/
+/*!
+ \file       m4_exporter.cpp
+ \brief
+
+ \version
+ based on 1.1.4 - 2009, 2010 Patrick Birnzain <pbi...@us...> 
+
+ \ingroup    M4_EXPORTER
+ */
+/******************************************************************************/
+
+#include "m4_exporter.hpp"
+#include <boost/foreach.hpp>
+#include <boost/algorithm/string.hpp>
+#include <iostream>
+#include <iomanip>
+using namespace std;
+
+#include <glibmm/miscutils.h>
+using Glib::build_filename;
+
+/******************************************************************************/
+/*
+ */
+/******************************************************************************/
+M4_Exporter::M4_Exporter(shared_ptr<Board> board)
+         : Exporter(board), dpi(board->get_dpi()), quantization_error( 2.0 / dpi ) {
+   this->board = board;
+   bDoSVG = false;
+}
+
+/******************************************************************************/
+/*
+ */
+/******************************************************************************/
+void M4_Exporter::set_svg_exporter(shared_ptr<SVG_Exporter> svgexpo) {
+   this->svgexpo = svgexpo;
+   bDoSVG = true;
+}
+
+/******************************************************************************/
+/*
+ */
+/******************************************************************************/
+void M4_Exporter::add_header(string header) {
+   this->header.push_back(header);
+}
+
+/******************************************************************************/
+/*
+ */
+/******************************************************************************/
+void M4_Exporter::export_all(boost::program_options::variables_map& options) {
+
+   bMetricinput = options["metric"].as<bool>();      //set flag for metric input
+   bMetricoutput = options["metricoutput"].as<bool>();      //set flag for metric output
+   bMirrored = options["mirror-absolute"].as<bool>();      //set flag
+   bCutfront = options["cut-front"].as<bool>();      //set flag
+   bFrontAutoleveller = options["al-front"].as<bool>();
+   bBackAutoleveller = options["al-back"].as<bool>();
+   string outputdir = options["output-dir"].as<string>();
+
+   //set imperial/metric conversion factor for output coordinates depending on metricoutput option
+   cfactor = bMetricoutput ? 25.4 : 1;
+
+   if( options["zero-start"].as<bool>() )
+   {
+      xoffset = board->get_min_x();
+      yoffset = board->get_min_y();
+   }
+   else
+   {
+      xoffset = 0;
+      yoffset = 0;
+   }
+
+   if( options.count("g64") )
+       g64 = options["g64"].as<double>();
+   else
+	   g64 = quantization_error * cfactor;      // set maximum deviation to 2 pixels to ensure smooth movement
+   
+   if( bFrontAutoleveller || bBackAutoleveller )
+   	  leveller = new autoleveller ( options, quantization_error, xoffset, yoffset );
+
+   if (options["bridges"].as<double>() > 0 && options["bridgesnum"].as<unsigned int>() != 0)
+      bBridges = true;
+   else
+      bBridges = false;
+
+   BOOST_FOREACH( string layername, board->list_layers() ) {
+      std::stringstream option_name;
+      option_name << layername << "-output";
+      string of_name = build_filename(outputdir, options[option_name.str()].as<string>());
+      of_name += ".m4";
+      cerr << "Exporting " << layername << "... ";
+      export_layer(board->get_layer(layername), of_name);
+      cerr << "DONE." << " (Height: " << board->get_height() * cfactor
+           << (bMetricoutput ? "mm" : "in") << " Width: "
+           << board->get_width() * cfactor << (bMetricoutput ? "mm" : "in")
+           << ")" << endl;
+   }
+}
+
+/******************************************************************************/
+/*
+/*
+/******************************************************************************/
+void M4_Exporter::export_layer(shared_ptr<Layer> layer, string of_name) {
+
+   string layername = layer->get_name();
+   shared_ptr<RoutingMill> mill = layer->get_manufacturer();
+   bool bSvgOnce = TRUE;
+   bool bAutolevelNow;
+   vector<unsigned int> bridgesIndexes;
+   vector<unsigned int>::const_iterator currentBridge;
+   vector<shared_ptr<icoords> > toolpaths = layer->get_toolpaths();
+
+   // open output file
+   std::ofstream of;
+   of.open(of_name.c_str());
+
+   // write header to .m4 file
+   BOOST_FOREACH( string s, header ) {
+      of << "m4_header(`" << s << "')\n";
+   }
+
+   if( ( bFrontAutoleveller && layername == "front" ) ||
+   	   ( bBackAutoleveller && layername == "back" ) ) {
+      of << "define(m4_autoleveller)dnl\n";
+  	  bAutolevelNow = true;
+   }
+   else {
+      of << "define(m4_noautoleveller)dnl\n";
+      bAutolevelNow = false;
+    }
+
+   of.setf(ios_base::fixed);      //write floating-point values in fixed-point notation
+   of.precision(5);              //Set floating-point decimal precision
+   of << setw(7);        //Sets the field width to be used on output operations.
+   of << "define(m4_digitdot," << 2 << ")dnl\n";
+   of << "define(m4_dotdigit," << 5 << ")dnl\n";
+
+   if (bMetricoutput) {
+      of << "define(m4_metric)dnl\n";
+   } else {
+      of << "define(m4_imperial)dnl\n";
+   }
+
+   of << "define(m4_spindlespeed," << mill->speed << ")dnl\n";
+   of << "define(m4_maxdeviation," << g64 << ")dnl\n";
+   of << "define(m4_feedrate," << mill->feed * cfactor << ")dnl\n";
+   of << "define(m4_plungerate," << mill->feed/2 * cfactor << ")dnl\n";
+   of << "define(m4_zsafe," << mill->zsafe * cfactor << ")dnl\n";
+   of << "define(m4_zwork," << mill->zwork * cfactor << ")dnl\n";
+
+    if( bAutolevelNow ) {
+      if( !leveller->prepareWorkarea( toolpaths ) ) {
+         std::cerr << "Required number of probe points (" << leveller->requiredProbePoints() <<
+                      ") exceeds the maximum number (" << leveller->maxProbePoints() << "). "
+                      "Reduce either al-x or al-y." << std::endl;
+         exit(EXIT_FAILURE);
+      }
+
+      leveller->header( of );
+    }
+
+   //SVG EXPORTER
+   if (bDoSVG) {
+      //choose a color
+      svgexpo->set_rand_color();
+   }
+
+   of << "m4_preamble" << "\n";       //insert external preamble
+   
+   // contours
+   BOOST_FOREACH( shared_ptr<icoords> path, toolpaths ) {
+
+      of << "m4_move(" << ( path->begin()->first - xoffset ) * cfactor << "," << ( path->begin()->second - yoffset ) * cfactor << ")\n";
+
+      //SVG EXPORTER
+      if (bDoSVG) {
+         svgexpo->move_to(path->begin()->first, path->begin()->second);
+         bSvgOnce = TRUE;
+      }
+
+      /* if we're cutting, perhaps do it in multiple steps, but do isolations just once.
+       * i know this is partially repetitive, but this way it's easier to read
+       */
+      shared_ptr<Cutter> cutter = boost::dynamic_pointer_cast<Cutter>(mill);
+
+      if (cutter && cutter->do_steps) {
+         if( bBridges ) {
+            try {
+                bridgesIndexes = outline_bridges::makeBridges( path, cutter->bridges_num, cutter->bridges_width + cutter->tool_diameter );
+                currentBridge = bridgesIndexes.begin();
+                if ( bridgesIndexes.size() != cutter->bridges_num )
+                    cerr << "Can't create " << cutter->bridges_num << " bridges on this layer, only " << bridgesIndexes.size() << " will be created." << endl;
+            } catch ( outline_bridges_exception &exc ) {
+                cerr << "Error while adding outline bridges. Outline bridges on this path won't be created." << endl;
+            }
+         }
+
+         //--------------------------------------------------------------------
+         //cutting (outline)
+
+         double z_step = cutter->stepsize;
+         double z = mill->zwork + z_step * abs(int(mill->zwork / z_step));
+
+         while (z >= mill->zwork) {
+            of << "m4_plunge("<< z << ")\n";
+
+            icoords::iterator iter = path->begin();
+            icoords::iterator last = path->end();      // initializing to quick & dirty sentinel value
+            icoords::iterator peek;
+            while (iter != path->end()) {
+               peek = iter + 1;
+
+               if (mill->optimise //Already optimised (also includes the bridge case)
+                       || last == path->end()  //First
+                           || peek == path->end()   //Last
+                               || !aligned(last, iter, peek) ) {    //Not aligned
+                  of << "m4_mill(" << ( iter->first - xoffset ) * cfactor << "," << ( iter->second - yoffset ) * cfactor << ")\n";
+                  if (bDoSVG) {
+                     if (bSvgOnce)
+                        svgexpo->line_to(iter->first, iter->second);
+                  }
+
+                  if( bBridges && currentBridge != bridgesIndexes.end() ) {
+                      if( *currentBridge == iter - path->begin() )
+                         of << "m4_Z(" << cutter->bridges_height * cfactor << ")\n";
+                      else if( *currentBridge == last - path->begin() ) {
+                         of << "m4_Z(" << z * cfactor << ")\n";
+                         ++currentBridge;
+                      }
+                  }
+               }
+
+               last = iter;
+               ++iter;
+            }
+            //SVG EXPORTER
+            if (bDoSVG) {
+               svgexpo->close_path();
+               bSvgOnce = FALSE;
+            }
+            z -= z_step;
+         }
+      } else {
+         //--------------------------------------------------------------------
+         // isolating (front/backside)
+         if( bAutolevelNow ) {
+            leveller->setLastChainPoint( icoordpair( ( path->begin()->first - xoffset ) * cfactor, ( path->begin()->second - yoffset ) * cfactor ) );
+            of << "m4_G01corr(" << ( path->begin()->first - xoffset ) * cfactor << "," << ( path->begin()->second - yoffset ) * cfactor << ")\n";
+         }
+
+         icoords::iterator iter = path->begin();
+         icoords::iterator last = path->end();      // initializing to quick & dirty sentinel value
+         icoords::iterator peek;
+         while (iter != path->end()) {
+            peek = iter + 1;
+            if (mill->optimise //When simplifypath is performed, no further optimisation is required
+                    || last == path->end()  //First
+                        || peek == path->end()   //Last
+                            || !aligned(last, iter, peek) ) {    //Not aligned
+                /* no need to check for "they are on one axis but iter is outside of last and peek" because that's impossible from how they are generated */
+               if( bAutolevelNow )
+		          of << "m4_addChainPoint(" << ( iter->first - xoffset ) * cfactor << "," << ( iter->second - yoffset ) * cfactor << ")\n";
+               else 
+                      of << "m4_mill(" << ( iter->first - xoffset ) * cfactor << "," << ( iter->second - yoffset ) * cfactor << ")\n";
+               //SVG EXPORTER
+               if (bDoSVG)
+                  if (bSvgOnce)
+                     svgexpo->line_to(iter->first, iter->second);
+            }
+
+            last = iter;
+            ++iter;
+         }
+         //SVG EXPORTER
+         if (bDoSVG) {
+            svgexpo->close_path();
+            bSvgOnce = FALSE;
+         }
+      }
+   }
+
+   of << "m4_postamble" << "\n";
+
+   if( bAutolevelNow ) {
+      leveller->footer( of );
+   }
+
+   of.close();
+
+   //SVG EXPORTER
+   if (bDoSVG) {
+      svgexpo->stroke();
+   }
+}
+
diff --git a/m4_exporter.hpp b/m4_exporter.hpp
new file mode 100644
index 0000000..d4629a4
--- /dev/null
+++ b/m4_exporter.hpp
@@ -0,0 +1,89 @@
+/*!\defgroup M4_EXPORTER*/
+/******************************************************************************/
+/*!
+ \file       m4_exporter.hpp
+ \brief
+
+ \version
+ based on latest 1.1.4 - 2009, 2010 Patrick Birnzain <pbi...@us...> 
+
+ \ingroup    M4_EXPORTER
+ */
+/******************************************************************************/
+
+#ifndef M4EXPORTER_H
+#define M4EXPORTER_H
+
+#include <vector>
+using std::vector;
+
+#include <string>
+using std::string;
+using std::pair;
+
+#include <fstream>
+using std::ofstream;
+
+#include <boost/shared_ptr.hpp>
+using boost::shared_ptr;
+
+#include <boost/program_options.hpp>
+
+#include "coord.hpp"
+#include "mill.hpp"
+#include "exporter.hpp"
+#include "svg_exporter.hpp"
+#include "autoleveller.hpp"
+#ifndef Included_OutlineBridges_H
+#include "outline_bridges.hpp"
+#endif
+
+/******************************************************************************/
+/*
+ */
+/******************************************************************************/
+class M4_Exporter: public Exporter {
+public:
+	M4_Exporter(shared_ptr<Board> board);
+	/* virtual void add_path( shared_ptr<icoords> ); */
+	/* virtual void add_path( vector< shared_ptr<icoords> > ); */
+	void add_header(string);
+	void export_all(boost::program_options::variables_map&);
+	void set_svg_exporter(shared_ptr<SVG_Exporter> svgexpo);
+	void set_preamble(string);
+	void set_postamble(string);
+
+protected:
+	void export_layer(shared_ptr<Layer> layer, string of_name);
+	inline bool aligned(icoords::const_iterator p0, icoords::const_iterator p1, icoords::const_iterator p2) {
+	    return ( (p0->first == p1->first) && (p1->first == p2->first) ) ||      //x-aligned
+	           ( (p0->second == p1->second) && (p1->second == p2->second) );    //y-aligned
+	}
+
+	bool bDoSVG;            //!< if true, export svg
+	shared_ptr<SVG_Exporter> svgexpo;
+	shared_ptr<Board> board;
+	vector<string> header;
+    string preamble;        //!< Preamble from command line (user file)
+    string postamble;       //!< Postamble from command line (user file)
+
+	double g64;             //!< maximum deviation from commanded toolpath
+	double cfactor;         //!< imperial/metric conversion factor for output file
+	bool bMetricinput;      //!< if true, input parameters are in metric units
+	bool bMetricoutput;     //!< if true, metric g-code output
+	bool bMirrored;         //!< if true, mirrored along y axis
+	bool bCutfront;         //!< if true, the outline will be cut from front
+    bool bBridges;
+    const unsigned int dpi;
+    const double quantization_error;
+
+	
+	autoleveller *leveller;
+	bool bFrontAutoleveller;
+	bool bBackAutoleveller;
+
+	double xoffset;
+	double yoffset;
+};
+
+#endif // M4EXPORTER_H
diff --git a/main.cpp b/main.cpp
index a2edd6a..7c1053a 100644
--- a/main.cpp
+++ b/main.cpp
@@ -64,6 +64,7 @@ using Glib::build_filename;
 #include "gerberimporter.hpp"
 #include "surface.hpp"
 #include "ngc_exporter.hpp"
+#include "m4_exporter.hpp"
 #include "board.hpp"
 #include "drill.hpp"
 #include "options.hpp"
@@ -318,24 +319,44 @@ int main(int argc, char* argv[]) {
          svgexpo->create_svg( build_filename(outputdir, vm["svg"].as<string>()) );
       }
 
-      shared_ptr<NGC_Exporter> exporter(new NGC_Exporter(board));
-      exporter->add_header(PACKAGE_STRING);
-
-      if (vm.count("preamble") || vm.count("preamble-text")) {
-         exporter->set_preamble(preamble);
-      }
-
-      if (vm.count("postamble")) {
-         exporter->set_postamble(postamble);
-      }
-
-      //SVG EXPORTER
-      if (vm.count("svg")) {
-         exporter->set_svg_exporter(svgexpo);
+      if (vm["m4"].as<bool>()){
+         shared_ptr<M4_Exporter> exporter(new M4_Exporter(board));
+         exporter->add_header(PACKAGE_STRING);
+   
+         //if (vm.count("preamble") || vm.count("preamble-text")) {
+         //   exporter->set_preamble(preamble);
+         //}
+   
+         //if (vm.count("postamble")) {
+         //   exporter->set_postamble(postamble);
+         //}
+   
+         //SVG EXPORTER
+         if (vm.count("svg")) {
+            exporter->set_svg_exporter(svgexpo);
+         }
+   
+         exporter->export_all(vm);
+      } else {
+         shared_ptr<NGC_Exporter> exporter(new NGC_Exporter(board));
+         exporter->add_header(PACKAGE_STRING);
+   
+         if (vm.count("preamble") || vm.count("preamble-text")) {
+            exporter->set_preamble(preamble);
+         }
+   
+         if (vm.count("postamble")) {
+            exporter->set_postamble(postamble);
+         }
+   
+         //SVG EXPORTER
+         if (vm.count("svg")) {
+            exporter->set_svg_exporter(svgexpo);
+         }
+   
+         exporter->export_all(vm);
       }
 
-      exporter->export_all(vm);
-
    } catch (std::logic_error& le) {
       cout << "Internal Error: " << le.what() << endl;
    } catch (std::runtime_error& re) {
diff --git a/ngc_exporter.cpp b/ngc_exporter.cpp
index 023adec..1d21560 100644
--- a/ngc_exporter.cpp
+++ b/ngc_exporter.cpp
@@ -126,6 +126,7 @@ void NGC_Exporter::export_all(boost::program_options::variables_map& options) {
       std::stringstream option_name;
       option_name << layername << "-output";
       string of_name = build_filename(outputdir, options[option_name.str()].as<string>());
+      of_name += ".ngc"; 
       cerr << "Exporting " << layername << "... ";
       export_layer(board->get_layer(layername), of_name);
       cerr << "DONE." << " (Height: " << board->get_height() * cfactor
diff --git a/ngc_exporter.hpp b/ngc_exporter.hpp
index 7894419..f8d194d 100644
--- a/ngc_exporter.hpp
+++ b/ngc_exporter.hpp
@@ -66,7 +66,9 @@ using boost::shared_ptr;
 #include "exporter.hpp"
 #include "svg_exporter.hpp"
 #include "autoleveller.hpp"
+#ifndef Included_OutlineBridges_H
 #include "outline_bridges.hpp"
+#endif
 
 /******************************************************************************/
 /*
diff --git a/options.cpp b/options.cpp
index cb590ad..92b3225 100644
--- a/options.cpp
+++ b/options.cpp
@@ -110,9 +110,9 @@ void options::parse(int argc, char** argv) {
       basename = instance().vm["basename"].as<string>() + "_";
    }
 
-   string front_output = "--front-output=" + basename + "front.ngc";
-   string back_output = "--back-output=" + basename + "back.ngc";
-   string outline_output = "--outline-output=" + basename + "outline.ngc";
+   string front_output = "--front-output=" + basename + "front";
+   string back_output = "--back-output=" + basename + "back";
+   string outline_output = "--outline-output=" + basename + "outline";
    string drill_output = "--drill-output=" + basename + "drill.ngc";
 
    const char *fake_basename_command_line[] = { "", front_output.c_str(),
@@ -180,66 +180,67 @@ options::options()
 			"version", "show the current software version");
 
    cfg_options.add_options()(
-			"front", po::value<string>(),"front side RS274-X .gbr")(
-            "back", po::value<string>(), "back side RS274-X .gbr")(
-            "outline", po::value<string>(), "pcb outline polygon RS274-X .gbr")(
-            "drill", po::value<string>(), "Excellon drill file")(
-            "svg", po::value<string>(), "SVG output file. EXPERIMENTAL")(
-            "zwork", po::value<double>(),
-            "milling depth in inches (Z-coordinate while engraving)")(
-            "zsafe", po::value<double>(), "safety height (Z-coordinate during rapid moves)")(
-            "offset", po::value<double>(), "distance between the PCB traces and the end mill path in inches; usually half the isolation width")(
-            "mill-feed", po::value<double>(), "feed while isolating in [i/m] or [mm/m]")(
-            "mill-speed", po::value<int>(), "spindle rpm when milling")(
-            "milldrill", po::value<bool>()->default_value(false)->implicit_value(true), "drill using the mill head")(
-            "nog81", po::value<bool>()->default_value(false)->implicit_value(true), "replace G81 with G0+G1")(
-            "extra-passes", po::value<int>()->default_value(0), "specify the the number of extra isolation passes, increasing the isolation width half the tool diameter with each pass")(
-            "fill-outline", po::value<bool>()->default_value(false)->implicit_value(true), "accept a contour instead of a polygon as outline (you likely want to enable this one)")(
-            "outline-width", po::value<double>(), "width of the outline")(
-            "cutter-diameter", po::value<double>(), "diameter of the end mill used for cutting out the PCB")(
-            "zcut", po::value<double>(), "PCB cutting depth in inches")(
-            "cut-feed", po::value<double>(), "PCB cutting feed in [i/m] or [mm/m]")(
-			"cut-speed", po::value<int>(), "spindle rpm when cutting")(
-            "cut-infeed", po::value<double>(), "maximum cutting depth; PCB may be cut in multiple passes")(
-            "cut-front", po::value<bool>()->default_value(false)->implicit_value(true), "cut from front side. Default is back side.")(
-			"zdrill", po::value<double>(), "drill depth")(
-            "zchange", po::value<double>(), "tool changing height")(
-            "drill-feed", po::value<double>(), "drill feed in [i/m] or [mm/m]")(
-            "drill-speed", po::value<int>(), "spindle rpm when drilling")(
-            "drill-front", po::value<bool>()->default_value(false)->implicit_value(true), "drill through the front side of board")(
-            "onedrill", po::value<bool>()->default_value(false)->implicit_value(true), "use only one drill bit size")(
-            "metric", po::value<bool>()->default_value(false)->implicit_value(true), "use metric units for parameters. does not affect gcode output")(
-            "metricoutput", po::value<bool>()->default_value(false)->implicit_value(true), "use metric units for output")(
-            "optimise", po::value<bool>()->default_value(false)->implicit_value(true), "Reduce output file size by up to 40% while accepting a little loss of precision.")(
-            "bridges", po::value<double>()->default_value(0), "add bridges with the given width to the outline cut")(
-            "bridgesnum", po::value<unsigned int>()->default_value(2), "specify how many bridges should be created")(
-            "zbridges", po::value<double>(), "bridges heigth (Z-coordinates while engraving bridges, default to zsafe) ")(
-			"al-front", po::value<bool>()->default_value(false)->implicit_value(true),
-            "enable the z autoleveller for the front layer")(
-			"al-back", po::value<bool>()->default_value(false)->implicit_value(true),
-            "enable the z autoleveller for the back layer")(
-			"software", po::value<string>(), "choose the destination software (useful only with the autoleveller). Supported softwares are linuxcnc, mach3, mach4 and custom")(
-			"al-x", po::value<double>(), "width of the x probes")(
-			"al-y", po::value<double>(), "width of the y probes")(
-			"al-probefeed", po::value<double>(), "speed during the probing")(
-			"al-probe-on", po::value<string>()->default_value("(MSG, Attach the probe tool)@M0 ( Temporary machine stop. )"), "execute this commands to enable the probe tool (default is M0)")(
-			"al-probe-off", po::value<string>()->default_value("(MSG, Detach the probe tool)@M0 ( Temporary machine stop. )"), "execute this commands to disable the probe tool (default is M0)")(
-			"al-probecode", po::value<string>()->default_value("G31"), "custom probe code (default is G31)")(
-			"al-probevar", po::value<unsigned int>()->default_value(2002), "number of the variable where the result of the probing is saved (default is 2002)")(
-			"al-setzzero", po::value<string>()->default_value("G92 Z0"), "gcode for setting the actual position as zero (default is G92 Z0)")(
-            "dpi", po::value<int>()->default_value(1000), "virtual photoplot resolution")(
-            "zero-start", po::value<bool>()->default_value(false)->implicit_value(true), "set the starting point of the project at (0,0)")(
-            "g64", po::value<double>(), "maximum deviation from toolpath, overrides internal calculation")(
-            "mirror-absolute", po::value<bool>()->default_value(false)->implicit_value(true), "mirror back side along absolute zero instead of board center\n")(
-            "output-dir", po::value<string>()->default_value(""), "output directory")(
-            "basename", po::value<string>(), "prefix for default output file names")(
-            "front-output", po::value<string>()->default_value("front.ngc"), "output file for front layer")(
-            "back-output", po::value<string>()->default_value("back.ngc"), "output file for back layer")(
-            "outline-output", po::value<string>()->default_value("outline.ngc"), "output file for outline")(
-            "drill-output", po::value<string>()->default_value("drill.ngc"), "output file for drilling")(
-            "preamble-text", po::value<string>(), "preamble text file, inserted at the very beginning as a comment.")(
-            "preamble", po::value<string>(), "gcode preamble file, inserted at the very beginning.")(
-            "postamble", po::value<string>(), "gcode postamble file, inserted before M9 and M2.");
+         "m4", po::value<bool>()->default_value(0),"export m4")(
+         "front", po::value<string>(),"front side RS274-X .gbr")(
+         "back", po::value<string>(), "back side RS274-X .gbr")(
+         "outline", po::value<string>(), "pcb outline polygon RS274-X .gbr")(
+         "drill", po::value<string>(), "Excellon drill file")(
+         "svg", po::value<string>(), "SVG output file. EXPERIMENTAL")(
+         "zwork", po::value<double>(),
+         "milling depth in inches (Z-coordinate while engraving)")(
+         "zsafe", po::value<double>(), "safety height (Z-coordinate during rapid moves)")(
+         "offset", po::value<double>(), "distance between the PCB traces and the end mill path in inches; usually half the isolation width")(
+         "mill-feed", po::value<double>(), "feed while isolating in [i/m] or [mm/m]")(
+         "mill-speed", po::value<int>(), "spindle rpm when milling")(
+         "milldrill", po::value<bool>()->default_value(false)->implicit_value(true), "drill using the mill head")(
+         "nog81", po::value<bool>()->default_value(false)->implicit_value(true), "replace G81 with G0+G1")(
+         "extra-passes", po::value<int>()->default_value(0), "specify the the number of extra isolation passes, increasing the isolation width half the tool diameter with each pass")(
+         "fill-outline", po::value<bool>()->default_value(false)->implicit_value(true), "accept a contour instead of a polygon as outline (you likely want to enable this one)")(
+         "outline-width", po::value<double>(), "width of the outline")(
+         "cutter-diameter", po::value<double>(), "diameter of the end mill used for cutting out the PCB")(
+         "zcut", po::value<double>(), "PCB cutting depth in inches")(
+         "cut-feed", po::value<double>(), "PCB cutting feed in [i/m] or [mm/m]")(
+         "cut-speed", po::value<int>(), "spindle rpm when cutting")(
+         "cut-infeed", po::value<double>(), "maximum cutting depth; PCB may be cut in multiple passes")(
+         "cut-front", po::value<bool>()->default_value(false)->implicit_value(true), "cut from front side. Default is back side.")(
+         "zdrill", po::value<double>(), "drill depth")(
+         "zchange", po::value<double>(), "tool changing height")(
+         "drill-feed", po::value<double>(), "drill feed in [i/m] or [mm/m]")(
+         "drill-speed", po::value<int>(), "spindle rpm when drilling")(
+         "drill-front", po::value<bool>()->default_value(false)->implicit_value(true), "drill through the front side of board")(
+         "onedrill", po::value<bool>()->default_value(false)->implicit_value(true), "use only one drill bit size")(
+         "metric", po::value<bool>()->default_value(false)->implicit_value(true), "use metric units for parameters. does not affect gcode output")(
+         "metricoutput", po::value<bool>()->default_value(false)->implicit_value(true), "use metric units for output")(
+         "optimise", po::value<bool>()->default_value(false)->implicit_value(true), "Reduce output file size by up to 40% while accepting a little loss of precision.")(
+         "bridges", po::value<double>()->default_value(0), "add bridges with the given width to the outline cut")(
+         "bridgesnum", po::value<unsigned int>()->default_value(2), "specify how many bridges should be created")(
+         "zbridges", po::value<double>(), "bridges heigth (Z-coordinates while engraving bridges, default to zsafe) ")(
+         "al-front", po::value<bool>()->default_value(false)->implicit_value(true),
+         "enable the z autoleveller for the front layer")(
+         "al-back", po::value<bool>()->default_value(false)->implicit_value(true),
+         "enable the z autoleveller for the back layer")(
+         "software", po::value<string>(), "choose the destination software (useful only with the autoleveller). Supported softwares are linuxcnc, mach3, mach4 and custom")(
+         "al-x", po::value<double>(), "width of the x probes")(
+         "al-y", po::value<double>(), "width of the y probes")(
+         "al-probefeed", po::value<double>(), "speed during the probing")(
+         "al-probe-on", po::value<string>()->default_value("(MSG, Attach the probe tool)@M0 ( Temporary machine stop. )"), "execute this commands to enable the probe tool (default is M0)")(
+         "al-probe-off", po::value<string>()->default_value("(MSG, Detach the probe tool)@M0 ( Temporary machine stop. )"), "execute this commands to disable the probe tool (default is M0)")(
+         "al-probecode", po::value<string>()->default_value("G31"), "custom probe code (default is G31)")(
+         "al-probevar", po::value<unsigned int>()->default_value(2002), "number of the variable where the result of the probing is saved (default is 2002)")(
+         "al-setzzero", po::value<string>()->default_value("G92 Z0"), "gcode for setting the actual position as zero (default is G92 Z0)")(
+         "dpi", po::value<int>()->default_value(1000), "virtual photoplot resolution")(
+         "zero-start", po::value<bool>()->default_value(false)->implicit_value(true), "set the starting point of the project at (0,0)")(
+         "g64", po::value<double>(), "maximum deviation from toolpath, overrides internal calculation")(
+         "mirror-absolute", po::value<bool>()->default_value(false)->implicit_value(true), "mirror back side along absolute zero instead of board center\n")(
+         "output-dir", po::value<string>()->default_value(""), "output directory")(
+         "basename", po::value<string>(), "prefix for default output file names")(
+         "front-output", po::value<string>()->default_value("front"), "output file for front layer")(
+         "back-output", po::value<string>()->default_value("back"), "output file for back layer")(
+         "outline-output", po::value<string>()->default_value("outline"), "output file for outline")(
+         "drill-output", po::value<string>()->default_value("drill.ngc"), "output file for drilling")(
+         "preamble-text", po::value<string>(), "preamble text file, inserted at the very beginning as a comment.")(
+         "preamble", po::value<string>(), "gcode preamble file, inserted at the very beginning.")(
+         "postamble", po::value<string>(), "gcode postamble file, inserted before M9 and M2.");
 }
 
 /******************************************************************************/
diff --git a/outline_bridges.hpp b/outline_bridges.hpp
index 91f4ae9..89aaae3 100755
--- a/outline_bridges.hpp
+++ b/outline_bridges.hpp
@@ -22,6 +22,8 @@
  */
 /******************************************************************************/
 
+#define Included_OutlineBridges_H
+
 #include <vector>
 using std::vector;
 using std::pair;
diff --git a/pcb2gcode.sh b/pcb2gcode.sh
new file mode 100755
index 0000000..e9f9c9a
--- /dev/null
+++ b/pcb2gcode.sh
@@ -0,0 +1,68 @@
+PCB2GCODE_BASE=/home/saintel/pcb2gcode/git_20150418/pcb2gcode/
+PCB2GCODE=$PCB2GCODE_BASE/pcb2gcode
+PCB2GCODE_M4=$PCB2GCODE_BASE/pcb2gcode_m4
+MILLPROJECT=millproject
+
+if [ -a $MILLPROJECT ] ; then {
+   $PCB2GCODE --m4=true
+   
+
+   if (grep -q front $MILLPROJECT); then {
+
+      if (grep -q ^front-output $MILLPROJECT); then {
+         FRONT_OUTPUT=`grep front-output millproject | sed -e 's/^[ ]*front-output[ ]*=[ ]*\([^ \t]\+\)/\1/'`
+      }; else { 
+         FRONT_OUTPUT='front' 
+      }; fi;
+      FRONT_OUTPUT_M4=$FRONT_OUTPUT.m4
+      FRONT_OUTPUT_GBR=$FRONT_OUTPUT.gbr
+
+      if [ -a $FRONT_OUTPUT_M4 ]; then {
+         echo "Processing front file : $FRONT_FILE" 
+         m4 $PCB2GCODE_M4/gerber.m4 $FRONT_OUTPUT_M4 > $FRONT_OUTPUT_GBR
+      }; else {
+         echo "Front template file not found : $FRONT_OUTPUT_M4" 
+      }; fi;
+
+   } fi;
+   
+   if (grep -q ^back $MILLPROJECT); then {
+
+      if (grep -q back-output $MILLPROJECT); then {
+         BACK_OUTPUT=`grep back-output millproject | sed -e 's/^[ ]*back-output[ ]*=[ ]*\([^ \t]\+\)/\1/'`
+      }; else { 
+         BACK_OUTPUT='back' 
+      }; fi;
+      BACK_OUTPUT_M4=$BACK_OUTPUT.m4
+      BACK_OUTPUT_GBR=$BACK_OUTPUT.gbr
+
+      if [ -a $BACK_OUTPUT_M4 ]; then {
+         echo "Processing back file : $BACK_FILE" 
+         m4 $PCB2GCODE_M4/gerber.m4 $BACK_OUTPUT_M4 > $BACK_OUTPUT_GBR
+      }; else {
+         echo "Back template file not found : $BACK_OUTPUT_M4" 
+      }; fi;
+
+   } fi;
+
+   if (grep -q outline $MILLPROJECT); then {
+
+      if (grep -q outline-output $MILLPROJECT); then {
+         OUTLINE_OUTPUT=`grep outline-output millproject | sed -e 's/^[ ]*outline-output[ ]*=[ ]*\([^ \t]\+\)/\1/'`
+      }; else { 
+         OUTLINE_OUTPUT='outline' 
+      }; fi;
+      OUTLINE_OUTPUT_M4=$OUTLINE_OUTPUT.m4
+      OUTLINE_OUTPUT_GBR=$OUTLINE_OUTPUT.gbr
+
+      if [ -a $OUTLINE_OUTPUT_M4 ]; then {
+         echo "Processing outline file : $OUTLINE_FILE" 
+         m4 $PCB2GCODE_M4/gerber.m4 $OUTLINE_OUTPUT_M4 > $OUTLINE_OUTPUT_GBR
+      }; else {
+         echo "Outline template file not found : $OUTLINE_FILE_M4" 
+      }; fi;
+
+   } fi;
+   
+} fi;
+
diff --git a/pcb2gcode_m4/gerber.m4 b/pcb2gcode_m4/gerber.m4
new file mode 100644
index 0000000..e27ab81
--- /dev/null
+++ b/pcb2gcode_m4/gerber.m4
@@ -0,0 +1,17 @@
+define(`m4_header',`G04 $1 *')dnl
+define(`m4_preamble',`G04 File Generated using pb2gcode and m4 template gerber.m4*
+`%FSLAX'm4_digitdot`'m4_dotdigit`Y'm4_digitdot`'m4_dotdigit`*%'
+ifdef(`m4_metric',`%MOMM*%')`'dnl
+ifdef(`m4_imperial',`%MOIN*%')
+%TF.Part,Other*%
+%LPD%
+%ADD10C,0.010*%
+D10*
+G01*')dnl
+define(`m4_coord',`define(`dotpos',`index($1,`.')')substr($1,0,eval(dotpos))substr($1,eval(dotpos+1))')dnl
+define(m4_postamble,M02*)dnl
+define(m4_header,)dnl
+define(m4_move,`define(`X',$1)define(`Y',$2)`X'm4_coord(X)`Y'm4_coord(Y)`D02*'')dnl
+define(m4_mill,`define(`X',$1)define(`Y',$2)`X'm4_coord(X)`Y'm4_coord(Y)`D01*'')dnl
+define(plunge,`G04 Plunge')dnl
+define(m4_Z,`G04 Z:$1')dnl

[Pcb2gcode-devel] m4 function

[Lionel S. C. <lio...@gm...>]

Dear all

As I told you I was interested in some features that are not currently in
pcb2gcode.

The first feature I was interested in, was to easilly expand or tune output
languages and output flavours. I was especially lacking a gerber output.
You may wander why I want a gerber to gerber translator ? The reason is
that I want to easilly control pcb2gcode behaviour, which is to my eyes
necessary both for debug and for regular usage.
To get flexibilty in outputs I added a m4 output to pcb2gcode, a m4
template (gerberonly by now, but gcode and hpgl may follow) and a shell
script to manage it.

I am not sur on how to implement the autolovel feature (what is it?)

I am  not a good GNU programmer. I don't know how to manage path in the
shell script. I don't know how to write the make install neither. I don't
know a smart way to give you the source code to review it. I tried a git
patch, but it is pretty new to me, I hope it is ok.

To test :
First : get sources from git, patch, configure and make
update : path in pcb2gcode.sh (first line should be enough)
move to : testing/gerbv_example/(the directory you prefer)
use : ../../../pcb2gcode.sh

I hope it will be interesting/usefull for you too.

Comments are welcome

Lionel SAINTE CLUQUE
adresse:
1, rue Paul de KOCK
92500 Rueil Malmaison
Téléphone +33 (0)6 18 04 20 75

Re: [Pcb2gcode-devel] Start designing feature

[Nicola C. <ni...@co...>]

> Has there been any thought to moving the code to github or just
> deprecating the sourceforge repo and making yours the new "official"
> repo? Github Issues would also be a good way to stay on top of bugs, new
> features and PRs that could involve people who aren't subscribed to this
> mailing list (that sourceforge packs with ads). Is the project getting
> any value out of Sourceforge?

I agree. I've just moved the repo on GitHub, here it is https://github.com/pcb2gcode/pcb2gcode

Nicola Corna

Re: [Pcb2gcode-devel] Start designing feature

[Spencer R. <sf...@me...>]

Has there been any thought to moving the code to github or just
deprecating the sourceforge repo and making yours the new "official"
repo? Github Issues would also be a good way to stay on top of bugs, new
features and PRs that could involve people who aren't subscribed to this
mailing list (that sourceforge packs with ads). Is the project getting
any value out of Sourceforge?

On Tue, Feb 10, 2015, at 09:06 AM, Nicola Corna wrote:
> > To do that I would like to know what is the legacy repository, to design it on the latest sources. 
> 
> Here it is
> https://sourceforge.net/p/pcb2gcode/code/ci/master/tree/
> 
> I'm working on new features in the simplifypath branch and I'll merge it
> shortly with master, you should pull the code from it
> https://sourceforge.net/p/pcb2gcode/code/ci/simplifypath/tree/
> 
> Nicola Corna
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take
> a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel

Re: [Pcb2gcode-devel] Start designing feature

[Lionel S. C. <lio...@gm...>]

Thx

Lionel SAINTE CLUQUE
adresse:
1, rue Paul de KOCK
92500 Rueil Malmaison
Téléphone +33 (0)6 18 04 20 75

2015-02-10 15:06 GMT+01:00 Nicola Corna <ni...@co...>:

> > To do that I would like to know what is the legacy repository, to design
> it on the latest sources.
>
> Here it is
> https://sourceforge.net/p/pcb2gcode/code/ci/master/tree/
>
> I'm working on new features in the simplifypath branch and I'll merge it
> shortly with master, you should pull the code from it
> https://sourceforge.net/p/pcb2gcode/code/ci/simplifypath/tree/
>
> Nicola Corna
>

Re: [Pcb2gcode-devel] Start designing feature

[Nicola C. <ni...@co...>]

> To do that I would like to know what is the legacy repository, to design it on the latest sources. 

Here it is
https://sourceforge.net/p/pcb2gcode/code/ci/master/tree/

I'm working on new features in the simplifypath branch and I'll merge it shortly with master, you should pull the code from it
https://sourceforge.net/p/pcb2gcode/code/ci/simplifypath/tree/

Nicola Corna

Re: [Pcb2gcode-devel] autoleveller

[Mathias K. <mk...@gm...>]

On 07.02.2015 18:18, Nicola Corna wrote:
>>  --optimise does not reduce
>> the file size more than ~40%, because it just removes the redundant
>> intermediate positions
>> along vertical and horizontal moves. The paths for 45 degree traces and
>> pads are rectangular step curves, --optimise does not touch them because
>> adjacent segments
>> are short but perpendicular.
>>
>> 'simplifypath' is somewhat different from 'optimise':
>>
>> //take two points of the path
>> // and their interconnecting path.
>> // if the distance between all intermediate points and this line
>> is smaller
>> // than the accuracy, all the points in between can be removed..
>>
>> - If it really does what is advertised, I did not check that.
>>
>> At least it does not only merge adjacent segments as 'optimise'.
>>
>> I fully agree on the precision calculation - computing it all in terms
>> of dpi sounds good as well, so there is only one handle to turn.
> I've also noticed that the code for simplifypath was created by Bernhard Kubicek in commit b49f0f1f70dfc0ad7c31fb8a250dc85b3a9ff361 in 2010, and no one has modified it since then. He also has his fork of pcb2gcode (https://github.com/bkubicek/pcb2gcode), but I don't think that a pull from him is a good idea, the repo changed a lot since his last commit (2012) and the current simplifypath function works well enough without the need of a merge with an unmaintained repo.
>
> I've done some tests on my gerber file, here's are the sizes of the front output gcode:
> no optimization: 432 KB
> "optimise" optimization: 245 KB
> simplifypath optimization: 27 KB
> both: 27 KB
> A diff between "simplifypath optimization" and "both" returns that the two files are identical, therefore the optimise code should be completely redundant. In the simulator, the simplifypath's output seems to be ok, the only thing that doesn't work is the "bridge" option (with simplifypath enabled only 2 bridges of 4 are created, I'll work on it).
> I hadn't tested autoleveller + simplifypath yet.
>
> If we fix this bug, do you think it's reasonable to remove the current optimise code and replace it with simplifypath?
From my (little) experience with both I would say yes.
A little test checking the precision on sample files would give some
more confidence.

Bye

 Mathias

[Pcb2gcode-devel] Start designing feature

[Lionel S. C. <lio...@gm...>]

Dear all,

I’m sorry of this stupid question, but I want to start designing a feature (pc2gcode outputs a toolpath in a m4 understandable format, the m4 is invoked to produce a flavor go gcode, gerber, hpgl, riprap gcode or pdf)

To do that I would like to know what is the legacy repository, to design it on the latest sources. 

Thanks by advance.

Lionel SAINTE CLUQUE
+33(0)6 18 04 20 75

www.dipole-electronique.fr

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

> Could you check that commit once again, please ? I'm afraid
> 91dcdf40835a62af94a639e277d6397859ba15e4 just renamed variables.
My bad... To keep the history clean I had to do a rebase; sorry!
Now the commit is c962e7bb53aedaf28dcc9600b07fa77f1d6d6c16

> Yes I did. But as predicted in the help text, --optimise does not reduce
> the file size more than ~40%, because it just removes the redundant
> intermediate positions
> along vertical and horizontal moves. The paths for 45 degree traces and
> pads are rectangular step curves, --optimise does not touch them because
> adjacent segments
> are short but perpendicular.
> 
> 'simplifypath' is somewhat different from 'optimise':
> 
> //take two points of the path
> // and their interconnecting path.
> // if the distance between all intermediate points and this line
> is smaller
> // than the accuracy, all the points in between can be removed..
> 
> - If it really does what is advertised, I did not check that.
> 
> At least it does not only merge adjacent segments as 'optimise'.
> 
> I fully agree on the precision calculation - computing it all in terms
> of dpi sounds good as well, so there is only one handle to turn.
I've also noticed that the code for simplifypath was created by Bernhard Kubicek in commit b49f0f1f70dfc0ad7c31fb8a250dc85b3a9ff361 in 2010, and no one has modified it since then. He also has his fork of pcb2gcode (https://github.com/bkubicek/pcb2gcode), but I don't think that a pull from him is a good idea, the repo changed a lot since his last commit (2012) and the current simplifypath function works well enough without the need of a merge with an unmaintained repo.

I've done some tests on my gerber file, here's are the sizes of the front output gcode:
no optimization: 432 KB
"optimise" optimization: 245 KB
simplifypath optimization: 27 KB
both: 27 KB
A diff between "simplifypath optimization" and "both" returns that the two files are identical, therefore the optimise code should be completely redundant. In the simulator, the simplifypath's output seems to be ok, the only thing that doesn't work is the "bridge" option (with simplifypath enabled only 2 bridges of 4 are created, I'll work on it).
I hadn't tested autoleveller + simplifypath yet.

If we fix this bug, do you think it's reasonable to remove the current optimise code and replace it with simplifypath?

Nicola

Re: [Pcb2gcode-devel] autoleveller

[Mathias K. <mk...@gm...>]

Hello Nicola,

On 06.02.2015 12:18, Nicola Corna wrote:
>> Firstly, I think I found another issue with the interpolation. It was
>> only correct with 4 probe points in 1in distance, here is a patch to
>> correct it:
> Committed, thanks
Could you check that commit once again, please ? I'm afraid
91dcdf40835a62af94a639e277d6397859ba15e4 just renamed variables. This is
what is left comparing HEAD against my local files:

204,205c204,205
<     x_minus_x0_rel = point.first - startPointX - xminindex * XProbeDist;
<     y_minus_y0_rel = point.second - startPointY - yminindex * YProbeDist;
---
>     x_minus_x0_rel = (point.first - startPointX - xminindex *
XProbeDist) / XProbeDist;
>     y_minus_y0_rel = (point.second - startPointY - yminindex *
YProbeDist) / YProbeDist;

>> The huge size is due to 'trivial G-Code' stemming from the outline
>> bitmap tracing. The 'optimise' command line option does not completely
>> remove the redundant steps. There is something similar in surface.cpp
>> around line 226, the 'simplifypath'-method. Switching that on and
>> setting the accuracy argument to 1/dpi dramatically reduces the file
>> size while keeping sufficient precision.
> Did you also activated the optimise switch? Does "simplifypath" includes all the optimizations done by "optimise"? I've never looked inside that part of code.
> I think that 2.0/dpi is a better choice, because the default g64 is 2.0/dpi and lower precisions are ignored by the CNC controller
Yes I did. But as predicted in the help text, --optimise does not reduce
the file size more than ~40%, because it just removes the redundant
intermediate positions
along vertical and horizontal moves. The paths for 45 degree traces and
pads are rectangular step curves, --optimise does not touch them because
adjacent segments
are short but perpendicular.

'simplifypath' is somewhat different from 'optimise':

        //take two points of the path
        // and their interconnecting path.
        // if the distance between all intermediate points and this line
is smaller
        // than the accuracy, all the points in between can be removed..

- If it really does what is advertised, I did not check that.

At least it does not only merge adjacent segments as 'optimise'.

I fully agree on the precision calculation - computing it all in terms
of dpi sounds good as well, so there is only one handle to turn.

>> There is one issue left:
>> simplifypath does not know about the autoleveller and can generate very
>> long moves crossing several cells of the probing grid. One should break
>> those long moves to interpolate at the cell boundaries.
> I've already created a function for that purpose: autoleveller.cpp, line 225
>
> subsegments = splitSegment( point, numOfSubsegments( point ) );
>
> This function splits a single segment in subsegments with a length of ~X(Y)ProbeDist, therefore any optimization shouldn't have any negative effect on autoleveller. Of course it increases the size, but we can't do much for that, if we want z-correction we need a bigger gcode.

That's great, I did not spot it.

 Bye
   Mathias

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

> Firstly, I think I found another issue with the interpolation. It was
> only correct with 4 probe points in 1in distance, here is a patch to
> correct it:

Committed, thanks

> The huge size is due to 'trivial G-Code' stemming from the outline
> bitmap tracing. The 'optimise' command line option does not completely
> remove the redundant steps. There is something similar in surface.cpp
> around line 226, the 'simplifypath'-method. Switching that on and
> setting the accuracy argument to 1/dpi dramatically reduces the file
> size while keeping sufficient precision.

Did you also activated the optimise switch? Does "simplifypath" includes all the optimizations done by "optimise"? I've never looked inside that part of code.
I think that 2.0/dpi is a better choice, because the default g64 is 2.0/dpi and lower precisions are ignored by the CNC controller

> There is one issue left:
> simplifypath does not know about the autoleveller and can generate very
> long moves crossing several cells of the probing grid. One should break
> those long moves to interpolate at the cell boundaries.

I've already created a function for that purpose: autoleveller.cpp, line 225

subsegments = splitSegment( point, numOfSubsegments( point ) );

This function splits a single segment in subsegments with a length of ~X(Y)ProbeDist, therefore any optimization shouldn't have any negative effect on autoleveller. Of course it increases the size, but we can't do much for that, if we want z-correction we need a bigger gcode.

Nicola Corna

Re: [Pcb2gcode-devel] autoleveller

[Mathias K. <mk...@gm...>]

Hello,

 I milled a board with 'autolevelling' today and the result was quite
nice. However I had to change a few things beforehand:

Firstly,  I think I found another issue with the interpolation. It was
only correct with 4 probe points in 1in distance, here is a patch to
correct it:

diff --git a/autoleveller.cpp b/autoleveller.cpp
index e9e30c9..a44c63c 100644
--- a/autoleveller.cpp
+++ b/autoleveller.cpp
@@ -196,20 +196,21 @@ void autoleveller::probeHeader( std::ofstream &of,
double zprobe, double zsafe,
 string autoleveller::interpolatePoint ( icoordpair point ) {
     int xminindex;
     int yminindex;
-    double x_minus_x0;
-    double y_minus_y0;
+    double x_minus_x0_rel;
+    double y_minus_y0_rel;
    
     xminindex = floor ( ( point.first - startPointX ) / XProbeDist );
     yminindex = floor ( ( point.second - startPointY ) / YProbeDist );
-    x_minus_x0 = point.first - startPointX - xminindex * XProbeDist;
-    y_minus_y0 = point.second - startPointY - yminindex * YProbeDist;
+    x_minus_x0_rel = (point.first - startPointX - xminindex *
XProbeDist) / XProbeDist;
+    y_minus_y0_rel = (point.second - startPointY - yminindex *
YProbeDist) / YProbeDist;
    
+    //    std::cerr << "IPP " << xminindex << "," << yminindex << " "
<< XProbeDist << "," << YProbeDist << " " << x_minus_x0 << "," <<
y_minus_y0 << "\n";
     return str( boost::format( callSub[software] ) %
BILINEAR_INTERPOLATION_MACRO_NUMBER %
                                                       getVarName(
xminindex, yminindex + 1 ) %
                                                       getVarName(
xminindex + 1, yminindex + 1 ) %
                                                       getVarName(
xminindex, yminindex ) %
                                                       getVarName(
xminindex + 1, yminindex ) %
-                                                      y_minus_y0 %
x_minus_x0 );
+                                                      y_minus_y0_rel %
x_minus_x0_rel );
 }

The "_x_y"-Variables are only Z coordinates, so the #5 and #6 in the
macro below must be relative positions (from [0,1]) within a rectangle
of probe points:

o1000 sub ( Bilinear interpolation macro )
#7=[#3+[#1-#3]*#5] ( Linear interpolation of the x-min elements )
#8=[#4+[#2-#4]*#5] ( Linear interpolation of the x-max elements )
#100=[#7+[#8-#7]*#6] ( Linear interpolation of previously interpolated
points )
o1000 endsub


The second change I made is not really related to autolevelling, but the
'optimization'. Initially I got 14Mb of G-Code for the bottom layer of
my test board. It's 90x55mm and is not very dense. I run the
'machinekit' offspring of linuxcnc on a Beaglebone Black to control the
mill - the step timing is so much more precise (and the machine quieter
and faster) with the hardware generated step timing. However 160k lines
of G-Code in 'Axis' is no fun on a 512Mb ARM system.
The largest board I milled with the Eagle-pcbgcode-Toolchain was
~100x80mm large and had much more components on it, and it used
~550kByte / 16k lines of G-Code.

The huge size is due to 'trivial G-Code' stemming from the outline
bitmap tracing. The 'optimise' command line option does not completely
remove the redundant steps. There is something similar in surface.cpp
around line 226, the 'simplifypath'-method. Switching that on and
setting the accuracy argument to 1/dpi dramatically reduces the file
size while keeping sufficient precision. There is one issue left:
simplifypath does not know about the autoleveller and can generate very
long moves crossing several cells of the probing grid. One should break
those long moves to interpolate at the cell boundaries.
With 'simplifypath' enabled I got ~680k of G-Code.

Regards,
 Mathias



On 02.02.2015 22:57, Nicola Corna wrote:
> You're welcome!
> I've pushed a commit (ba90eac95d503952f5f35b5a095a0dc0e1fa9917) that fixes that bug. Now also the 1st point of the chain has interpolation.
> That ~0.1mm is curious... I don't have a probe tool yet, I'll let you know when I get it.
>
> Nicola Corna
>
> 1 Febbraio 2015 23:15, "Mathias Katzer" <mk...@gm...> wrote:
>
>> Hello Nicola,
>>
>> with those changes LinuxCNC accepts the NGC output here as well.
>>
>> I tried the autoleveller superficially in the LinuxCNC simulator (probe
>> close is a button) but not on the real mill yet. It seems to interpolate
>> the tracks well so far, however the initial Z-move after the rapid x/y
>> to the start of a chain is produced directly in ngc-exporter.cpp:344 and
>> is not interpolated from the probed Z positions:
>>
>> [...]
>>
>> Can you please tell me if the autoleveller works for you? It's still experimental and any
>> feedback 
>>> is very appreciated
>>> Thanks
>>>
>>> Nicola Corna
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel

[Pcb2gcode-devel] Internal board cutouts

[Matthijs K. <mat...@st...>]

Hi folks,

I'm trying to make a board with a rectangular internal slot cut out (an
opening for some leds to peek through). However, I'm not sure how to
achieve this using pcb2gcode (and Kicad for the original design).

I'm trying to model this on the outline / edge cuts layer. I've tried:

 1. Drawing the board outline as well as the cutout using lines. This
    somewhat has the intended effect, in the sense that pcb2gcode
    generates two toolpaths - on for the edge, one for the cutout.
    Howver, both of them are milled on the _outside_, making the cutout
    bigger than intended. I can of course shrink the cutout in Kicad,
    but I'd like to avoid having to hardcode the cutting bit diameter in
    my pcb design.
 2. Drawing the board outline as a filled zone, using a cutout area for
    the slot. This results in just the board outline being milled, the
    cutout entirely disappears in the gcode. Looking a the gerber file,
    this produces a G36 polygon that uses a single line to define both
    the board edge and cutout (so there is a line from the board edge to
    the cutout). That line is defined both in a G36/G37 polygon, as well
    as outside the polygon (to give some thickness to the line,
    perhaps).

In both cases, I've used fill-outline=0, IIRC setting it to 1 doesn't
help.

Is pcb2gcode capable of producing such cutouts? Any suggestions for a
working workflow?

Gr.

Matthijs

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

You're welcome!
I've pushed a commit (ba90eac95d503952f5f35b5a095a0dc0e1fa9917) that fixes that bug. Now also the 1st point of the chain has interpolation.
That ~0.1mm is curious... I don't have a probe tool yet, I'll let you know when I get it.

Nicola Corna

1 Febbraio 2015 23:15, "Mathias Katzer" <mk...@gm...> wrote:

> Hello Nicola,
> 
> with those changes LinuxCNC accepts the NGC output here as well.
> 
> I tried the autoleveller superficially in the LinuxCNC simulator (probe
> close is a button) but not on the real mill yet. It seems to interpolate
> the tracks well so far, however the initial Z-move after the rapid x/y
> to the start of a chain is produced directly in ngc-exporter.cpp:344 and
> is not interpolated from the probed Z positions:
> 
> [...]
> G0 Z0.25000 ( Move Z to safe height )
> (PROBECLOSE) ( Close the probe log file )
> ( Probing has ended, each Z-coordinate will be corrected with a bilinear
> interpolation )
> (MSG, detach the probe tool)
> M0 ( Temporary machine stop. )
> 
> M3 ( Spindle on clockwise. )
> G04 P0 ( dwell for no time -- G64 should not smooth over this point )
> G00 Z0.25000 ( retract )
> 
> G00 X2.12901 Y2.17717 ( rapid move to begin. )
> ==> G01 Z-0.00100 <==
> G04 P0 ( dwell for no time -- G64 should not smooth over this point )
> o1000 call [#<_0_1>] [#<_1_1>] [#<_0_0>] [#<_1_0>] [2.17717] [2.12901]
> [...]
> 
> I like the autoleveller feature a lot. Previously I worked with
> pcb-gcode for Eagle and a self written tool that generated probe g-code
> and accepted the probe log in a second run to modify the z moves in the
> pcb-gcode output. That's obviously complicated because files have to be
> copied around during the job, so the interpolation within the g-code is
> much more elegant. Now that I decided to switch to kiCad, this comes in
> perfectly on time, thanks :-).
> 
> When I started experimenting with the probing, I noticed that there is a
> temperature (?) drift of ~0.1mm if I start the probing several times
> after initially powering on the mill. It stabilized after 5~10min of
> operation, the second and 3rd probing run produce similar results but
> the 1st and second don't. I wonder whether that is just a bug of my
> homegrown mill or happens elsewhere, too.
> I do need a lot of probing points by the way because I use cheap and
> bit-friendly FR2 baseboard. It is not level at all and too flexible to
> pin larger pieces down perfectly.
> 
> Bye,
> 
> Mathias
> 
> On 31.01.2015 17:38, Nicola Corna wrote:
> 
>> I've added both solutions in commits 118a9af7d27049b4fdfda8723d2d0bb5349f51c4 and
>> 4bc07773f3c0945a2ca1729eb871f90c621f47a7
>> Your patch should fix every bad point and, if it does not work, my patch should still make a
>> correct gcode
>> I've tested your gerber's output with LinuxCNC and everything seems to be ok, can you confirm it?
>> Can you please tell me if the autoleveller works for you? It's still experimental and any
> 
> feedback 
>> is very appreciated
>> Thanks
>> 
>> Nicola Corna

Re: [Pcb2gcode-devel] autoleveller

[Mathias K. <mk...@gm...>]

Hello Nicola,

 with those changes LinuxCNC accepts the NGC output here as well.

I tried the autoleveller superficially in the LinuxCNC simulator (probe
close is a button) but not on the real mill yet. It seems to interpolate
the tracks well so far, however the initial Z-move after the rapid x/y
to the start of a chain is produced directly in ngc-exporter.cpp:344 and
is not interpolated from the probed Z positions:

[...]
G0 Z0.25000 ( Move Z to safe height )
(PROBECLOSE) ( Close the probe log file )
( Probing has ended, each Z-coordinate will be corrected with a bilinear
interpolation )
(MSG, detach the probe tool)
M0 ( Temporary machine stop. )

M3 ( Spindle on clockwise. )
G04 P0 ( dwell for no time -- G64 should not smooth over this point )
G00 Z0.25000 ( retract )

G00 X2.12901 Y2.17717 ( rapid move to begin. )
==> G01 Z-0.00100   <==
G04 P0 ( dwell for no time -- G64 should not smooth over this point )
o1000 call [#<_0_1>] [#<_1_1>] [#<_0_0>] [#<_1_0>] [2.17717] [2.12901]
[...]


I like the autoleveller feature a lot. Previously I worked with
pcb-gcode for Eagle and a self written tool that generated probe g-code
and accepted the probe log in a second run to modify the z moves in the
pcb-gcode output. That's obviously complicated because files have to be
copied around during the job, so the interpolation within the g-code is
much more elegant. Now that I decided to switch to kiCad, this comes in
perfectly on time, thanks :-).

When I started experimenting with the probing, I noticed that there is a
temperature (?) drift of ~0.1mm if I start the probing several times
after initially powering on the mill. It stabilized after 5~10min of
operation, the second and 3rd probing run produce similar results but
the 1st and second don't. I wonder whether that is just a bug of my
homegrown mill or happens elsewhere, too.
I do need a lot of probing points by the way because I use cheap and
bit-friendly FR2 baseboard. It is not level at all and too flexible to
pin larger pieces down perfectly.

Bye,

 Mathias


On 31.01.2015 17:38, Nicola Corna wrote:
> I've added both solutions in commits 118a9af7d27049b4fdfda8723d2d0bb5349f51c4 and 4bc07773f3c0945a2ca1729eb871f90c621f47a7
> Your patch should fix every bad point and, if it does not work, my patch should still make a correct gcode
> I've tested your gerber's output with LinuxCNC and everything seems to be ok, can you confirm it?
> Can you please tell me if the autoleveller works for you? It's still experimental and any feedback is very appreciated
> Thanks
>
> Nicola Corna
>

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

I've added both solutions in commits 118a9af7d27049b4fdfda8723d2d0bb5349f51c4 and 4bc07773f3c0945a2ca1729eb871f90c621f47a7
Your patch should fix every bad point and, if it does not work, my patch should still make a correct gcode
I've tested your gerber's output with LinuxCNC and everything seems to be ok, can you confirm it?
Can you please tell me if the autoleveller works for you? It's still experimental and any feedback is very appreciated
Thanks

Nicola Corna

31 Gennaio 2015 15:17, "Mathias Katzer" <mk...@gm...> wrote: 
> Hello Nicola,
> 
> yes of course it is a bad hack as I wrote.
> 
> So I wanted to know what is really going on and found out the size of
> the error corresponds to the value of the 'dpi' option. Therefore I
> believe it could just be quantisation error from the outline bitmap in
> surface.cpp.
> The patch below fixes the issue for me ( again it enlarges the probe
> area, but only 4 dots of the outline bitmap this time ). Your
> extrapolation proposal might even be better because it does not assume
> so much about the max. possible error, but I'm not into the pcb2gcode
> code enough to do it right now.
> 
> diff --git a/board.cpp b/board.cpp
> index c8c1f9b..b9a673f 100644
> --- a/board.cpp
> +++ b/board.cpp
> @@ -119,10 +119,10 @@ void Board::createLayers() {
> shared_ptr<Isolator> trace_mill =
> boost::static_pointer_cast<Isolator>(prepared_layers.at("front").get<1>());
> ivalue_t radius = trace_mill->tool_diameter / 2;
> int passes = trace_mill->extra_passes + 1;
> - min_x -= radius * passes;
> - max_x += radius * passes;
> - min_y -= radius * passes;
> - max_y += radius * passes;
> + min_x -= radius * passes+2./dpi;
> + max_x += radius * passes+2./dpi;
> + min_y -= radius * passes+2./dpi;
> + max_y += radius * passes+2./dpi;
> }
> catch( std::logic_error& e ) {
> min_x -= margin;
> 
> Bye,
> 
> Mathias
> 
> On 30.01.2015 15:07, Nicola Corna wrote:
> 
>> I don't like your solution, it forcefully increases the area, especially when there are only 4
>> probing points at each angle
>> Since the problematic points are very close to the border, we can simply do a linear
> interpolation
>> of the closest points
>> Send me your Gerber file, I'll use it as a test
>> Thanks for your bug report
> 
> 30 Gennaio 2015 12:27, "Mathias Katzer" <mk...@gm...> wrote:
> 
>>> It is because some pad in the Gerber file sticks out by ~0.01in from the
>>> bounding box returned by the importer.
>>> 
>>> For myself I enlarged the probing area by one ProbeDist in both
>>> coordinates. Of course that does not solve the root of the problem, but
>>> adds robustness. I guess the actual bug is in gerbv or kicad - don't
>>> know yet.

Re: [Pcb2gcode-devel] autoleveller

[Mathias K. <mk...@gm...>]

Hello Nicola,

 yes of course it is a bad hack as I wrote.

So I wanted to know what is really going on and found out the size of
the error corresponds to the value of the 'dpi' option. Therefore I
believe it could just be quantisation error from the outline bitmap in
surface.cpp.
The patch below fixes the issue for me ( again it enlarges the probe
area, but only 4 dots of the outline bitmap this time ). Your
extrapolation proposal might even be better because it does not assume
so much about the max. possible error, but I'm not into the pcb2gcode
code enough to do it right now.

diff --git a/board.cpp b/board.cpp
index c8c1f9b..b9a673f 100644
--- a/board.cpp
+++ b/board.cpp
@@ -119,10 +119,10 @@ void Board::createLayers() {
             shared_ptr<Isolator> trace_mill =
boost::static_pointer_cast<Isolator>(prepared_layers.at("front").get<1>());
             ivalue_t radius = trace_mill->tool_diameter / 2;
             int passes = trace_mill->extra_passes + 1;
-            min_x -= radius * passes;
-            max_x += radius * passes;
-            min_y -= radius * passes;
-            max_y += radius * passes;
+            min_x -= radius * passes+2./dpi;
+            max_x += radius * passes+2./dpi;
+            min_y -= radius * passes+2./dpi;
+            max_y += radius * passes+2./dpi;
         }
         catch( std::logic_error& e ) {
             min_x -= margin;

Bye,

  Mathias


On 30.01.2015 15:07, Nicola Corna wrote:
> I don't like your solution, it forcefully increases the area, especially when there are only 4 probing points at each angle
> Since the problematic points are very close to the border, we can simply do a linear interpolation of the closest points
> Send me your Gerber file, I'll use it as a test
> Thanks for your bug report
>
30 Gennaio 2015 12:27, "Mathias Katzer" <mk...@gm...> wrote:
>> It is because some pad in the Gerber file sticks out by ~0.01in from the
>> bounding box returned by the importer.
>>
>> For myself I enlarged the probing area by one ProbeDist in both
>> coordinates. Of course that does not solve the root of the problem, but
>> adds robustness. I guess the actual bug is in gerbv or kicad - don't
>> know yet.
>>

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

I don't like your solution, it forcefully increases the area, especially when there are only 4 probing points at each angle
Since the problematic points are very close to the border, we can simply do a linear interpolation of the closest points
Send me your Gerber file, I'll use it as a test
Thanks for your bug report

Nicola Corna

30 Gennaio 2015 12:27, "Mathias Katzer" <mk...@gm...> wrote: 
> Hello,
> 
> I got broken NGC output when trying the autoleveller with a specific
> Gerber file created in KiCad.
> 
> It is because some pad in the Gerber file sticks out by ~0.01in from the
> bounding box returned by the importer.
> 
> For myself I enlarged the probing area by one ProbeDist in both
> coordinates. Of course that does not solve the root of the problem, but
> adds robustness. I guess the actual bug is in gerbv or kicad - don't
> know yet.
> 
> If you wish I can provide the Gerber file and / or patches
> 
> Mathias
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel

[Pcb2gcode-devel] autoleveller

[Mathias K. <mk...@gm...>]

Hello,

  I got broken NGC output when trying the autoleveller with a specific
Gerber file created in KiCad.

It is because some pad in the Gerber file sticks out by ~0.01in from the
bounding box returned by the importer.

For myself I enlarged the probing area by one ProbeDist in both
coordinates. Of course that does not solve the root of the problem, but
adds robustness. I guess the actual bug is in gerbv or kicad - don't
know yet.

If you wish I can provide the Gerber file and / or patches

  Mathias

Re: [Pcb2gcode-devel] Some minor fixes to pcb2gcode

[Patrick B. <pat...@gm...>]

I think it should be pretty very to write a different exporter. If I remember correctly, the program was designed to easily allow this. You can probably just start with the gcode exporter class and rewrite it as an m4 exporter, then add a "-m4" flag or something that selects the new exporter in main.cpp

-- Patrick


On Mon, 26 Jan 2015 10:05:15 +0100
Lionel SAINTE CLUQUE <lio...@gm...> wrote:

> Dear all
> 
> I find very restrictive that pcb2gcode outputs gcode directly. If gcode syntax has to change or language has to change (dxf, gerber, …) it needs to be compiled again.
> 
> Do you think that it may be more suitable to output (let’s say) a m4 file and then convert it to gcode using a M4 template.
> 
> It is just an idea perhaps m4 is not the good language, or this idea is bad, but I think that it may be the best solution. 
> Template may be different for drilling, milling, milling stencils, …
> 
> Any ideas ? 
> 
> Lionel SAINTE CLUQUE
> +33(0)6 18 04 20 75
> 
> www.dipole-electronique.fr
> 
> > Le 25 janv. 2015 à 20:39, Lionel Sainte Cluque <lio...@gm...> a écrit :
> > 
> > Dear all
> > 
> > I made some improvements to pcb2gcode, but it is far too ugly, I have to rework it. It was on an earlier version.
> > 
> > The improvements included : 
> > Factorisation of lines in 3 directions : vertical, horizontal 45 degrees. This is quite quick and reduces the number of points in the toolpath easily
> > I was never successfull to implement a Douglas Peucker algo. Is this implemented now?
> > Grow by zero mill on the image to extract the exact outline. Then I use my usual cam software to do an external cut (or internal cut when I do a stencil)
> > "Grow by amount" on the vectorial data, not the image.
> > Export as a gerber of the toolpath. This is necessary to run visual check on gerbv.
> > 
> > Need to check if this is still compatible to the new code. If someone want to react (give advices, propose adjustments or tell what seems unusefull) please do it this week, before I work on that again. 
> > 
> > Thanks
> > 
> > 
> > Lionel SAINTE CLUQUE
> > adresse:
> > 1, rue Paul de KOCK
> > 92500 Rueil Malmaison
> > Téléphone +33 (0)6 18 04 20 75
> > 
> > 2015-01-25 12:09 GMT+01:00 Nicola Corna <ni...@co... <mailto:ni...@co...>>:
> > Hi
> > I've merged your repo (https://github.com/ssfrr/pcb2gcode <https://github.com/ssfrr/pcb2gcode>) into the master
> > Thanks
> > 
> > Nicola Corna
> > 
> > ------------------------------------------------------------------------------
> > New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> > GigeNET is offering a free month of service with a new server in Ashburn.
> > Choose from 2 high performing configs, both with 100TB of bandwidth.
> > Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> > http://p.sf.net/sfu/gigenet <http://p.sf.net/sfu/gigenet>
> > _______________________________________________
> > Pcb2gcode-devel mailing list
> > Pcb...@li... <mailto:Pcb...@li...>
> > https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel <https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel>
> > 
> 

Re: [Pcb2gcode-devel] Some minor fixes to pcb2gcode

[Lionel S. C. <lio...@gm...>]

Dear all

I find very restrictive that pcb2gcode outputs gcode directly. If gcode syntax has to change or language has to change (dxf, gerber, …) it needs to be compiled again.

Do you think that it may be more suitable to output (let’s say) a m4 file and then convert it to gcode using a M4 template.

It is just an idea perhaps m4 is not the good language, or this idea is bad, but I think that it may be the best solution. 
Template may be different for drilling, milling, milling stencils, …

Any ideas ? 

Lionel SAINTE CLUQUE
+33(0)6 18 04 20 75

www.dipole-electronique.fr

> Le 25 janv. 2015 à 20:39, Lionel Sainte Cluque <lio...@gm...> a écrit :
> 
> Dear all
> 
> I made some improvements to pcb2gcode, but it is far too ugly, I have to rework it. It was on an earlier version.
> 
> The improvements included : 
> Factorisation of lines in 3 directions : vertical, horizontal 45 degrees. This is quite quick and reduces the number of points in the toolpath easily
> I was never successfull to implement a Douglas Peucker algo. Is this implemented now?
> Grow by zero mill on the image to extract the exact outline. Then I use my usual cam software to do an external cut (or internal cut when I do a stencil)
> "Grow by amount" on the vectorial data, not the image.
> Export as a gerber of the toolpath. This is necessary to run visual check on gerbv.
> 
> Need to check if this is still compatible to the new code. If someone want to react (give advices, propose adjustments or tell what seems unusefull) please do it this week, before I work on that again. 
> 
> Thanks
> 
> 
> Lionel SAINTE CLUQUE
> adresse:
> 1, rue Paul de KOCK
> 92500 Rueil Malmaison
> Téléphone +33 (0)6 18 04 20 75
> 
> 2015-01-25 12:09 GMT+01:00 Nicola Corna <ni...@co... <mailto:ni...@co...>>:
> Hi
> I've merged your repo (https://github.com/ssfrr/pcb2gcode <https://github.com/ssfrr/pcb2gcode>) into the master
> Thanks
> 
> Nicola Corna
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet <http://p.sf.net/sfu/gigenet>
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li... <mailto:Pcb...@li...>
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel <https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel>
> 

Re: [Pcb2gcode-devel] Some minor fixes to pcb2gcode

[Lionel S. C. <lio...@gm...>]

Dear all

I made some improvements to pcb2gcode, but it is far too ugly, I have to
rework it. It was on an earlier version.

The improvements included :

   - Factorisation of lines in 3 directions : vertical, horizontal 45
   degrees. This is quite quick and reduces the number of points in the
   toolpath easily
   - I was never successfull to implement a Douglas Peucker algo. Is this
   implemented now?
   - Grow by zero mill on the image to extract the exact outline. Then I
   use my usual cam software to do an external cut (or internal cut when I do
   a stencil)
   - "Grow by amount" on the vectorial data, not the image.
   - Export as a gerber of the toolpath. This is necessary to run visual
   check on gerbv.


Need to check if this is still compatible to the new code. If someone want
to react (give advices, propose adjustments or tell what seems unusefull)
please do it this week, before I work on that again.

Thanks


Lionel SAINTE CLUQUE
adresse:
1, rue Paul de KOCK
92500 Rueil Malmaison
Téléphone +33 (0)6 18 04 20 75

2015-01-25 12:09 GMT+01:00 Nicola Corna <ni...@co...>:

> Hi
> I've merged your repo (https://github.com/ssfrr/pcb2gcode) into the master
> Thanks
>
> Nicola Corna
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel
>