Too Cool for Internet Explorer

Your (Cutting) Plotter and Inkscape   February 17th, 2013

I own a Cutting Plotter from Helo, which is bundled with HeloCut, a proprietary software which connects to CorelDraw or Inkscape.

This software has many disadvantages:

  • It is expensive
  • It can only drive a Helo Plotter
  • On install it is bundled with your Computer hardware and cannot be installed on 2 Computers or a fresh install of the same Computer!!!
  • It is buggy as hell
  • The only thing it does (as i found out) is converting the SVG data to HPGL which is an open data format for Plotters (Dating back to the 90’s)

To summarize it: Every time you re-install windows you have to spend 70 Euros (or 50 Euros for an update) for the same software again.

All this points made me search for alternatives. There are a few ones, but none of them are really “good software”. Most are very expensive, and then there is InkCut.

InkCut COULD be a good and usable alternative, but it is also buggy and difficult to understand. And the knockout argument against InkCut is that it does not run under Windows. Or to be precise: It only runs under Windows after installing tons of Python Software in an specific fashion. This is simply much too complicated for normal users. And even if some users manage to do so it is missing some major features that are not compatible with windows.

After doing a ton of research i realized two important points: First, Windows is automatically installing a Serial Interface when the USB cable is connected (The chip the Plotter uses is a standard, widely used Serial-to-USB bridge), and second, Inkscape already has a HPGL export (Since 2008), which outputs data that can be sent directly to the Plotter via a serial connection.

Now i could export a drawing to an HPGL file, open that file, copy the HPGL data and send it via a serial console program directly to the Plotter. That worked.

The existing HPGL export of Inkscape is very basic, and i found that it is missing two important features: Overcut and Tool Offset correction. Both features are vital when plotting on a Swivel Knife Plotter (That is the most common type of Plotter). Without those features the drawing will look like Comic Sans because the knife is dragged around, also the plot will most of the time not be closed and stick to the rest of the foil.

This demonstrates the path to plot with and without the Tool Offset correction. Since the knife is dragged behind, the path on the right will result in sharp edges on the plot:

HPGL_Export_Interface_Correction

After some bickering with myself i decided to expand the existing HPGL export in Inkscape. I added all the features i found missing and even added a nice little feature which raises the convenience a lot: It can now send the Data to the serial interface by itself.

This is the new Interface:

HPGL_Export_Interface

On first glance it is a bit intimidating, but every feature has a Tool Tip to help you understand what it does:

HPGL_Export_Interface_ToolTip

Now the HPGL export is full featured, easy to use, and does (nearly) the same things that very expensive software does.

New features:

  • Selectable offset
  • Selectable alignment
  • Overcut
  • Tool offset correction
  • Automatically chosen zero point
  • Send HPGL data via serial port
  • Help texts on all options
  • Changed all units from Pixels to mm (Pixels are not a real world unit)

This new export will be officially included in Inkscape 0.49, or if you are impatient you can download a “Development Version” from the same download page further down.

If you want to use the serial communication you need to install pySerial also (Open Source):

  1. Download pySerial here: http://pypi.python.org/pypi/pyserial
  2. Extract the “serial” subfolder from the zip to the following folder: “C:\Program Files (x86)\inkscape\python\Lib\” (Or wherever your Inkscape is installed to)
  3. Restart Inkscape

How to Use the HPGL export:

  1. Ungroup all your drawings
  2. Convert all your drawings to paths
  3. Union all paths (Not necessary, but the Plot order will be better if you do so)
  4. Click “File” -> “Save As”
  5. Choose “HP Graphics Language file (*.hpgl)” as type
  6. Click “Save”
  7. Choose the Parameters as they fit your Plotter
  8. If you want to plot right away, choose the serial port and baud rate fitting your plotter
  9. Click “OK”

I hope it is as useful to you as it is to me.

Please let me know how it works with your Plotter and if you have any problems in the comments!

Tags: , , , , , ,
This entry was posted on Sunday, February 17th, 2013 at 21:37 and is filed under Plugins, Programming, Tools. You can follow any responses to this entry through the RSS 2.0 feed.Responses are currently closed, but you can trackback from your own site.

19 Responses

March 13th, 2013 at 11:10
Raphael Says:

That’s really useful!
But it doesn’t work for me :(. I’m using an old Roland DPX 2000 which uses a coordinate system with a centered origin. So I can just use 1/4 of the size of my plotter :(.
Maybe you can make an option for LL or center origin in an next version.

March 17th, 2013 at 23:51
TimeWaster Says:

Hi Raphael,
i have changed the plugin to fit your type of plotter and sent the change to the Inkscape team. The changes are committed into the Inkscape repository now and are available via the Inkscape download page’s Development Versions starting from revision 12220.

March 24th, 2013 at 18:55
Joakim Says:

Hi.

I have been looking for that solution for at long time – Great work!

It would be a nice improvement if the resolution could be specified for X and Y axis y individual. On my Refine MH721 there is a small difference in resolution for X and Y direction.

I can’t get “Send to Plotter…” to work on Windows 7 x64, but a solution is to make a .BAT file to send the output file to the COM port:

%ECHO off
REM Send HPGL file to MH721 Plotter

REM Set COM port used
set COM=\\.\COM3

mode COM3:9600,n,8,1 > NUL
copy %1 %COM% /b

Copy the text to the file MH721.BAT and send print with the command:

MH721 [file.hpgl]

Again great work!

– Joakim

July 22nd, 2013 at 23:54
Thomas Says:

Hi all. I was very pleased to read about this Inkscape plugin for cutting plotters. However, after installing the latest developer release of Inkscape, and the serial module for python, and checking the send to plotter checkbox, nothing happens. My Refine EH 360 plotter does nothing. I also tried the batch file solution as suggested. No plot is done. What could be the solution for me?
I am using Win 7 and a Refine EH 360 plotter via FTDI USB serial adapter. It works (if I am lucky …) with Artcut 2009 Pro, but the software sucks in general. That’s why I want to try the Inkscape version. Thanks for any suggestions.

July 23rd, 2013 at 15:05
TimeWaster Says:

Hi Thomas,

after a short look into the specifications of your plotter i have to say that it will not work with any software that uses HPGL, because your plotter uses DMPL as a commando language.

i never heared of DMPL before, and the plotter support i have written for inkscape was developed from the existing HPGL export of inkscape.

since i am developing the plotter support further (i am working right now at driving plotters from the extension menu of inkscape), there is a good chance that i also add DMPL support in the future, but it will at least take a couple of months since i do that in my spare time (also i could use someone with a DMPL plotter for testing then). sorry.

i hope i could answer all your questions.

July 24th, 2013 at 07:56
Thomas Says:

Hi admin, thank you for your quick reply. You’re absolutely right about the DNPL issue. I tried to set my plotter to HPGL in Artcut – same thing, the plotter is dead. So that is bad news, since I’ll have to stick with Artcut for the time being. But thank you for figuring this out.

Concerning beta-tests for the DMPL implementation – count me in.

October 9th, 2013 at 04:47
Jens Wilmer Says:

Hello,

I have a big old cutter with an old small buffer, so i can’t use the “send to cutter” option as with inkcut before, because hardware handshaking is not available. Would it be possible to get an option for initializing pyserial with “rtscts=1″? That would be terrific.
I would also like to have an extension as inkcut has been, to send the output to the cutter neither writing it to a file nor having to choose a filename for it (and remember to use “save copy” not to loose the original .svg file as default save target).
My Cutter (Roland CAMM1 PNC1800) also seems to compensate for the blade offset hiimself, when the “pen” is set to “cutter”. This leads to quite eratic movements, if both compensations are present. This can be avoided by choosing one of pen1 to pen8 at the cutter, if anyone encounters similar problems.
I also have a little problem with the overcut feature: Very small fragments are torn from the sheet when the overcut get to work. A long narrow stripe gets completely removed by a 0.5mm overcut, because the overcut always cuts whole pathsegments, which can be quite long. The stripes starting on the small side do not get ripped of, as there is only a small side scale overcut, but i’m not shure, if i can modify my drawings to start on the small side always.
Could you explain the “Return Factor” a bit? It is not really clear to me, how it is calculated into the path to send.
In your rectangular example above, i would tend to set it close to one, if it is the distance on the following line from the end of the previous line (where the blade should reside now) to the point on the following line the first movement should be aimed. That way the blade would more or less stay on one point until it is turned into the right direction and starts from the beginning of the following line. To be precise, the head should have moved in a circle with radius equal to the blade offset, which could be close enough. But if there is an acute angle, this might no longer work, because the initial movement is far from the optimal segment of a circle around the “blade-point”.
So how does it really work?
Another Question about the curve flattness: In your Screenshot, it is 0.5mm, in my inkscape the default value is 0.2mm and the tooltip says, the default would be 1.2mm… how Coarse do the curves get, and what is a reasonable value? The size of the smallest details to cut? Half that? A tenth? Haven’t seen much of a difference yet, but i’m very careful not to ruin my cuts by turning the wheels too fast.
Nonetheless: A very big thank for your work!
Jens Wilmer

October 9th, 2013 at 20:04
TimeWaster Says:

hi Jens,

for all the following statements: i can not release them before the new tool offset correction is finished. this should be done in 2 weeks.

– i will take a look into the “rtscts” config and will add it when necessary.
– i changed the code to be an extension already (while preserving the hpgl file output functionality)
– about overcut: this is already fixed (the cutting length gets shortened to the specified overcut length regardless of the length of the drawing).
– the return factor will be removed with the new release, i changed the method of tool offset correction to be circles like you described.
– about curve flattness default: the default is 1.2, i think it is this when the export gets called the first time, maybe you changed it at some point? inkscape remembers all the parameter values.
– about curve flattness: this value is a threshhold that gives the maximum distance between the handles of the bézier curve, if the distance is bigger than 1.2 (multiplied with the dpi setting to preserve reproduction quality regardless of plotter resolution) the curve gets devided into two curves, and so on. this parameter has no unit, it is just an esotherical description of the granularity of a reproduction of a curve. i found 1.2 to be a reasonable value, fine enough to not be seen with the blank eye, but rough enough to keep the file size down. other than that i can give you no further hint than just to try different values. or you can just use the default, it is really good enough for very fine details.

i hope i could answer all your questions :)

other than that just be patient, there should be a new version shortly.

maybe you want to beta-test the new features when they are finished, so you get all the goodness before it is released?

October 10th, 2013 at 01:55
Jens Wilmer Says:

Hello,

i just looked into my e-mail while i started to write a perl script to implement the tool offset:

My plotter uses 40 units per millímeter, the blade offset is 10 units.

A line from 10,10 to 100,10 has been plot. so the edge of the blade looks to the right.
A line from 10,20 to 100,20 should be cut, so the commands would be
PU20,20; (the blades tip is ten units to the left)
PD110,20; (cut one blade offset longer, the tip is now at 100,20)

The next line should end at 100,100, the angle between the two lines is 90 degrees and my plotter supports arc command:
AA100,20,90,0.1; moves the head 90 degrees anticlockwise around the center at 100,20, being is the blades tipps position we already know, this should stop at 100,30 with the tip still at 100,20. The forth parameter is the granularity, taken from an hpgl example resulting in 180 degrees broken up into 8 segments.

Next Step:
PD100,110; (Already seen, endpoint plus bladeoffset)
doesn’t look so hard, if the plotter supports arcs.
The angles in degrees are more than fine enough for me, the angle between 0,0 -> 0,10 and 0,0 -> 1,10 is about 5,7 degrees. So small values could be ignored by the program or will be a little later by the plotter…

the blade could should also be turned at the beginning of a line if the previous cutting movements angle is known. At the start the cutter could start at 0,10, 10,20, 20,10 or 10,0 making an at least 270 degrees cut ending in th direction of the first cut, to get the blade into the right position.

To have the space for turning the blade and positioning the head with the offset, the position of the plot should be shifted by one blade offset (or two blade offsets on one axis for the initial turn, if there cannot be found an unused square with an area of a quarter of a squaremilimeter.)

The rtscts option can be activated by changing one line to:
self.S = serial.Serial(port=self.options.port, baudrate=self.options.baudRate, timeout=0.01, writeTimeout=None, rtscts=1)
(At least adding this Parameter to the initialization of PySerial in InkCut did it for me. Making it configurable should be no problem for you.)

Another feature would also help me: A progressbar or other kind of notification of the process still running. I just recently realized, that a lot of my tests are invalid, because i changed some parameter, but actually plotted the old file, because the export had not finished yet. I just discovered it by accident, when closing Inkscape while the export was still running and getting an errormessage about inkscape having crashed. After that i started some tests with different filenames and got to know how long the export really takes.

I already learned about the flattness by reading your comments in the inkscape bug report about this extension, but my mind still tries to see something else when reading the word. (But i tell it its the allowed curve deviation every time; it will get used to it…)

I would very much like becoming a beta tester, as i am in my holidays right now, and won’t see my plotter alot in three weeks. Maybe i can also help to implement the missing features.
(And i can test the extension on Linux with an old plotter with just a few bytes of memory heavily depending on hardware handshaking. (And i can test if your code is still vi editable, although the vi hatress put into it by you :o) ) )

Looking forward to hearing from you,
Jens Wilmer

October 10th, 2013 at 20:25
TimeWaster Says:

i think this weekend i will be able to finish development, and i will give you the code afterwards.

im afraid a progressbar is not possible since the inkscape extension system is VERY limited in its possibilities. just wait until your plotter stops moving ^^

i could use some help in the C++ code, are you good in C++?
anyway, i am looking forward to your linux test!

it should be still vi editable. i learned to come to terms with vi/vim, although i still dont like it (but i use it often ^^).

December 14th, 2013 at 22:41
Juliane Says:

We tested the Windows version (will try Linux soon) with our Helo plotter but didn’t get good results (we played with the settings). Some lines have not been cut through and the plotter often cut diagonal lines through the drawings. We couldn’t find out when and when not.

It worked fine with the HeloCut5 trial version but like so many other folks we were not able to activate our payed software so that experience ended after 30 days. We would be happy to use Open Source and maybe help making it better anyway so it would be great if this would work.

Do you have any ideas what could help? Which settings are best for our plotter? What information do you need to debug the problem? We’ve got a huge project after Christmas so fast help would be appreciated.

December 15th, 2013 at 03:20
TimeWaster Says:

Hi Juliane,

yeah, i have an Helo plotter also, they are the cheapest china crap.

usually the Helo cutters start cutting lines over the drawings when it contains too many nodes. it is a pain in the arse, but i haven’t found any solution for that problem. i even had it with HeloCut.

you could try reducing the amount of nodes per inch. the overall node amount doesn’t seem to make any problems, and it is not a software or transmission problem, it is a problem of the plotter itself.

what version of inkscape (the revision number, something like “r12832″) do you use?

if it is lower than r12816 you should update to r12832 and try again. i changed many things in the software, and r12832 is the most current version.

About the settings: On a Helo cutter you should activate software flow control with 9600 baud. you can leave the other settings mostly as is. The Helo cutters work with HPGL and DPML as well.

if that all doesn’t help feel free to contact me again, i will send you an email right now.

December 15th, 2013 at 04:10
roberto Says:

Hi,

first, let me thank you for your great work. I just checked the most recent Inkscape version with our Helo 720 cutter. I can also confirm the problem with random cuts through the drawing, making it impossible to finish even a single piece.

The generated HPGL output from Inkscape (via save as…) appeared to be clean. Could you add a “dump code” button?

After thinking about the problem for a while, I found there may be some other possible sources for the erroneous behaviour (besides a completely faulty firmware inside of the Helo):

a) the built-in serial-USB-converter is cheap and faulty -> test with a direct serial connection/an external serial-USB-converter
b) there is still a problem with the connection caused by wrong transmission parameters (9600 baud still too fast? other flow control, stop bits??)

I will also try it again with Linux instead of Windows, and by sending the code directly through a serial connection.

Maybe I will find some time tomorrow to look into it again.

Greetings,
Roberto

December 15th, 2013 at 13:55
TimeWaster Says:

hi roberto,

this extensions is already used by many people with a big variety of plotters without problems, only the helo plotters react funny sometimes.

i always use the following file for testing:
http://files.timewaster.de/forum/nukevader.svg
because it has a good combination of sharp edges, circles, 90° edges and so on. this file is always correctly plotted with my Helo HSP 360 NG.
please try to plot this file and tell me if it plotted
correctly.

a “debug” feature that dumps the code also is a good idea, i will add it to the code.

i think the usb-to-serial bridge is not the problem, it is a standard chip used a million times.

about the connection: i looked into the manuals for the helo plotters, and the connection settings are correct. you can’t actually go lower or higher than 9600 baud, the plotter needs this speed.
the data bits and stop bits are standard, no need to set them.

there is no difference in windows vs. linux. before i wrote this extension i tried to use inkcut on linux and got the same results with lines through the plot. i even got it with inkcut sometimes.

the only thing i found influencing this bug is the amount of nodes in a drwaing. if the number gets to high i get destroyed drawings.
and this is not a connection or memory problem, my cutter has 6MB of cache, which is enough for very big drawings.

if you find something else causing this bug please let me know!

regards,
TimeWaster

December 15th, 2013 at 16:16
roberto Says:

Hi TimeWaster,

I do not think this is the real problem, as it appears with my Helo already with a relatively simple snowflake (maybe 200? cuts if exported to HPGL). I will try your file and report back.

Of course it is a standard chip, but maybe the implementation or connection to the rest inside of the Helo is faulty. I also tried to disable the FIFO-Buffer for the USB-serial interface in Windows.

I think the total amount of nodes should be no problem at all, as long as the cutter processes every command on a one-by-one basis.
And 6MB of cache cannot be filled so quickly with 9600 baud. ;)

What happens if you send your testfile continously, as if it was a drawing with three, four or fifty times the nodes? If that is really the cause of our problem you should be able to provoke the faulty behaviour that way.

In my (short) experience the error always appears exactly in the same place of the drawing, which hints at either a code generation problem, or a special combination of characters, that gets misinterpreted by the Helo.

Regarding too many nodes at once (and maybe a progress bar): Why not try sending complex drawings in parts of maybe 10, 100 or 1000 lines instead of all at once? Maybe the Helo needs a pause, or a reconnect every x lines?

just my 2¢,
best regards,
Roberto

December 15th, 2013 at 19:19
TimeWaster Says:

hi,

well i am able to reproduce it, i have a document with many nodes and a simpler version with a reduced amount of nodes but everything else is the same, and the “big” version produces lines, the “small” one not.

you are right, the total amount of nodes is not the crashing factor, but the amount of nodes per inch is.

if your problem appears always at the same place, check the amount of nodes in that place please. try to reduce it.

sending the drawing in parts would have no effect, thats what actually the flow control is for, when the plotter is not able to receive any more data it sends a flag that signals the computer to stop sending data, and when enough buffer is available again the flag gets removed.

regards,
TimeWaster

December 22nd, 2013 at 21:11
Shez Says:

Hi,
I notice in the most recent versions of inkscape 0.9x in the repository the ‘Send to plotter’ functionality no longer appears?

Appears to have gone between these revisions:
— share/extensions/hpgl_output.inx 2013-04-28 11:16:17 +0000
+++ share/extensions/hpgl_output.inx 2013-12-20 19:27:50 +0000

Is there an alternative way of getting this functionality intended?

Looking to add support for Zing plotters, which basically boils down to ‘ZG’ instead of ‘IN’ for initialisation, and away to specify cutting force to be passed to a FSXX command.
Cheers
Shez

December 22nd, 2013 at 22:46
Shez Says:

Answering my own question – send to plotter functionality has moved to the ‘Plotter->Plot’ extension, which makes sense.
Cheers!
Shez

December 29th, 2013 at 15:05
TimeWaster Says:

This comments section is now closed, please add your comments to this post from now on: Inkscape and Plotters, the 2nd