Exporting G-code

Is there a simple way to save G-code to a file and keep the line numbers? When we saved to a text file the line numbers were gone. We want to send the file to another printer which uses a controller that expects line numbers with the G-code like a typical machine tool controller. The format we want uses line numbers like N0001, N0002, N0003, N0010, N0020 etc.
We tried a short file where we manually added the line numbers to the text file and that ran just fine but it would be unbelievably tedious to do that with the longer print files. Does Slic3r or Repetier have a setting or a means of doing this? One of the other slicer programs if not?

Thanks for any help,
Jim

Line numbers are typically added by the host program (pronterface, repetier host, e.g.) at the time of sending them to the printer.

Here is a simple python script that will add the line numbers to a file. This just writes the output to standard output. It would be a simple matter to direct it to a file.

import sys

if len(sys.argv) != 2:
	print "Usage: addnumbers.py filename"
	exit(1)

try:
	lns = list(open(sys.argv[1]))
except:
	print "Unable to open input file: %s" % sys.argv[1]
	exit(1)

nbr = 0

for ln in lns:
	print "N%d %s" % (nbr, ln.rstrip())
	nbr += 1
	
exit(0)

Thanks for your help, that got us headed the right way. Steve has come up with a Perl script that he thinks will do the job for us.

We are grateful for your help.

Jim

We've run into another snag. We are trying to print the company logo in a single width line, mainly for a demo at the show next week and Slic3r isn't working in this drawing. It does output g-code after trying to download for a couple or three hours, but the file has no x or y coordinates. We widened the part thickness in an attempt to get it to work, and ran tha file through netfabb, which had worked for us on some of our other part drawings, but no joy. Anybody have an idea what we might be doing wrong?

Jim

Quote
Jim Blackwood
We've run into another snag. We are trying to print the company logo in a single width line, mainly for a demo at the show next week and Slic3r isn't working in this drawing. It does output g-code after trying to download for a couple or three hours, but the file has no x or y coordinates. We widened the part thickness in an attempt to get it to work, and ran tha file through netfabb, which had worked for us on some of our other part drawings, but no joy. Anybody have an idea what we might be doing wrong?

Jim

I don't understand. What is a "single width line"? You obviously cannot print a logo (or anything else) inside a single extruded line of plastic because that is the quantum of a FFF printer. It would be like trying to print something inside a single dot of a dot-matrix printer. You could print some sort of design as an outline (single perimeter) that is the same width as an extrusion, but will have to ensure that the design software does not reduce the width at any point to below the extrusion width, else Slic3r will not print those areas. You could try setting the width to 1.5 times the extrusion width in your design to try to ensure that no part goes below the extrusion width (or lower the extrusion width in Slic3r to use your existing STL).

Dave

Thanks Dave, I appreciate your advice.
The drawing does have width. Looking at an enlarged view we started with a square cross section but then increased the height to a factor of about 10:1 and I believe Tom told me he increased the width also. I also tried positioning the part partially below the plane of the bottom grid so that there would be no question of us trying to print the air between the part and the grid. This gave the same results, we get our z moves and our positional moves before and after the print but no x/y moves while printing.

So I tried reducing the filament diameter to 1 and extrusion multiplier to 0.5 and got the same thing again. So I cut the multiplier down even more then I got an extrusion width error so I cut that way down too. I'm running it again and will see what it does. It's spending a long time on infilling layers so I'm guessing that's a good sign. Next run I'll bump the sizes back up and try to get something more realistic. This is just a test run. Tom says no wall on the part is thinner than 1.4mm so at least that is a starting point.

Right now we are just trying for gross machine movement for demo. We will not be depositing any metal at the show, so we are shooting for a large pattern and somewhat exaggerated speeds.

Jim

Quote
Jim Blackwood
Thanks Dave, I appreciate your advice.
The drawing does have width. Looking at an enlarged view we started with a square cross section but then increased the height to a factor of about 10:1 and I believe Tom told me he increased the width also. I also tried positioning the part partially below the plane of the bottom grid so that there would be no question of us trying to print the air between the part and the grid. This gave the same results, we get our z moves and our positional moves before and after the print but no x/y moves while printing.

So I tried reducing the filament diameter to 1 and extrusion multiplier to 0.5 and got the same thing again. So I cut the multiplier down even more then I got an extrusion width error so I cut that way down too. I'm running it again and will see what it does. It's spending a long time on infilling layers so I'm guessing that's a good sign. Next run I'll bump the sizes back up and try to get something more realistic. This is just a test run. Tom says no wall on the part is thinner than 1.4mm so at least that is a starting point.

Right now we are just trying for gross machine movement for demo. We will not be depositing any metal at the show, so we are shooting for a large pattern and somewhat exaggerated speeds.

Jim

The filament diameter and extrusion multiplier has nothing to do with it! They only determine the amount (volume) of plastic extruded and will not otherwise affect the slicing (XYZ moves). The parameter to adjust (reduce) is the extrusion width ("Print Settings" > "Advanced" > "Default extrusion width"). The default is "auto" and will usually give a perimeter extrusion width equal to the nozzle diameter. To end up with a single line of plastic the height of the design should be the same as the layer height you set in Slic3r. Does the design look OK in the Plater preview window after you import the STL?

Maybe attach your STL (or a similar one if it's confidential) and I'll take a look.

Dave


Dave

I'll confess to being a little lost. I'm using the version of Slic3r embedded in Repetier-Host v1.0.6 We are running a post-slice filter which is a Perl script to add line numbers, positional commands and layer numbers. I don't think it is particularly complex and we've been running it successfully.

In the configuration window under Print Settings / Advanced / Extrusion Width I had zeroed out all the entries (for default). The slicer hung on infill and stayed there for 20 hours. Obviously not the right approach, so I'm setting all values to 1.5 and resolution to 1 and will try that. Our line sizes in the file are supposed to be 1.4 and 2mm. On Printer Settings I have the nozzle Diameter at 1. I have the first layer height at 1 and Layer Height at 1.

The file is proprietary but not confidential. It is a logo for our company and for Parker Automation so I'd rather not see it abused by anyone but I see no reason why I can't attach it. Looks like it is small enough.

Now waiting on "Exporting G-code to C:..."

Thanks for all your help Dave. We really need to find someone who understands 3D printing and can devote adequate time to this but unfortunately I don't think I will ever be that person. I'm just doing the best I know how. I hope the company doesn't have to depend on my skills for it's success.

Edit: Also I scaled the file to .7 so it will be inside the print boundaries. I currently have it positioned somewhat below the bottom plane, a couple mm or so.

Jim

Edited 1 time(s). Last edit at 03/19/2015 12:10PM by Jim Blackwood.

Try cutting out the middle-man by running Slic3r standalone. You say you have set the extrusion width to 1.5 but are trying to print items of width 1.4 That cannot be done (if the extrusion is 1.5mm wide, it cannot draw a line of width 1.4mm).

Looking at your STL, I see that it is around 900mm X 900mm. Is your printer large enough, and if so have you set the bed size correctly in Slic3r?

Dave

Thanks Dave. I tried 1.3 with no greater success. Our printer bed is 900mm x 1200mm so that would be a little tight and is the reason I scaled the part to .7 which should have brought it down to 630 x 630mm and the image confirms this reduction. The preview at the 1.3mm size shows a 13m:25s print time,0 layer count, 644 lines.

OK, I downloaded and started Slic3r v1.2.6, changed the bed shape to 1200 x 900 and added the file under the Plater tab (is that right?) It placed the part in the bottom left corner and sliced off the corner and immediately began processing the part. I am attaching my config.ini file in case that helps. I tried loading the file with Quick Slice and am waiting to see those results. I really do appreciate you providing a sort of lifeline here. I have people counting on me and don't feel up to it but I'll plug away as long as there's a chance.

Jim

Well, I loaded your STL into Slic3r 1.2.6, scaled to 0.7, set the bed size to 900 X 1200 and it sliced fine in a few seconds (verified with a separate g-code viewer). I did not however change any of my other normal settings so it was using its default extrusion width of 0.5 (nozzle set to 0.5mm). Looking at your STL I see that the smallest line width is indeed 1.4mm in that STL When scaled by 0.7 therefore, that will become a width of 0.98mm which is too thin for an extrusion width of 1.3mm To duplicate my result, set your nozzle size to 0.5mm and leave the extrusion width default (which will be close to 0.5mm). Think of the extrusion width as being the width of a large decorator's paint brush (and assume it cannot be brushed sideways). You cannot paint an outline with a line thickness that is narrower than the brush, and you cannot print a line that is thinner than the extrusion width. (Well, actually you can to an extent, but that's not relevant to your issue).

Note also that Slic3r may not allow layer heights that are bigger than the nozzle diameter, so set your layer height accordingly also. My quick test (to prove Slic3r could slice your STL) was done with a layer height of 0.25mm, so maybe start there.

Extrusion widths that are much smaller than the nozzle diameter will not print too well, so to get an output that will actually work on your printer, you will need to set the real nozzle diameter of the printer and adjust the size of your design (STL) to use widths that are the same or slightly wider than your nozzle diameter after any scaling factor has been applied

For a single perimeter pattern such as you want to print you could cheat and set the nozzle diameter smaller than your printer's nozzle (with extrusion width set to default) so that Slic3r produces valid G-code. The XY moves in that code will be correct, but the extrusion amounts will be incorrect unless you also scale by an equivalent amount in either the filament diameter variable in Slic3r or the extrusion multiplier. So if your printer has a nozzle diameter of 1mm but you have set Slic3r to have a diameter of 0.5mm to accommodate the STL, you should set the extrusion multiplier to 2.

Note however that if there are any lines that are twice the extrusion width or more, Slic3r will lay down two lines side-by-side and that will not be correct because they will be spaced apart by what Slic3r believes is the extrusion width rather than the width your printer is actually printing.

The concepts are not difficult to understand if you think about what Slic3r needs to achieve.

Dave

Thanks Dave, i have applied your recommendations and am running another test. Everything looks OK so far.

I guess we probably need much more RAM as it slows down greatly while exporting G-code. We have 4GB installed. I seem to remember seeing a much higher recommendation somewhere, but I also think I saw some reference to that being caused by improperly set parameters, which no doubt fits this scenario perfectly.

I hope to see a result in an hour or two and will post results then.

Jim

Good news, that did the trick, and as a benefit I understand a bit more about how this works. But realistically I'm a hardware guy and we really need a 3D printing software guy to work with in order to get the best results with this machine. There is an opportunity here if you want to help or know someone who might be a good fit.

So it's on to the show, Automate 2015 at the McCormick center in Chicago. The printer should already be there and we're headed up tomorrow to set up.The machine will be in Parker Automation's booth at #1139 and we have a complimentary booth at #598 if anyone would like to see what we've built and/or meet us.

Thanks again,
Jim

The "Avoid crossing perimeters" is the box that usually slows down the export if it is ticked.

I'm on the other side of the pond, Jim, so can't help at the show, sorry. The boundary between software & hardware (mechanical and electronic) gets a bit blurred when dealing with CAM machines, so modern engineers need to have knowledge of software as well as hardware - certainly to the extent of being able to drive the various CAD/CAM packages. Computer applications are pretty much like any other tool, and an engineer would not be much use if he didn't know how to use a screwdriver!

Dave

Well stated.
I've always leaned more towards the mechanical side of things just because I found it came easier to hand, whereas the electronics and programming side always required a lot of hard work to make even minimally acceptable progress and it always seemed I took the long way around the barn to get to any goal. Perhaps you see some of that in the above. I know i'm not the dullest tool around but I'm not so full of myself that I miss the clear evidence that there are others who see the picture much more clearly than I do when it comes to these things. As a result, I find myself often in the category of knowing just enough to be dangerous. I try not to let that spoil things though, and when, as now, I find the task falls to me despite my incompetence, I try to hold up that end as well as I can manage. Usually I do OK if I can find help.

Tomorrow we'll have the machine up and moving and I expect to be able to try this file and see how it runs (without depositing, we aren't throwing sparks at the show). I'll let you know how it turns out.

Jim