G-Code, Embroidermodder .TXT

[tatarize]

@jameskolme If you actually need that sort of formatting it's not that hard to add. The old .txt was an export from Embroidermodder which I neglected to port. If you'd use G-code instead I'd have to know what commands you used for that. There's not a 1 to 1 for embroidery as such. But, the actual command structure is pretty easy to follow.

[tatarize]

I went and promptly added .txt writer a few moments after I saw your post. Though, if the goal of the .txt is simply to write g-code. Why don't I just write the g-code? It'll have the very pronounced additional advantage that with the pyemb.py command line interface you could very easily convert any embroidery file to the type you actually use quite directly.

And if you want to add such a thing to InkStitch the file I wrote should be entirely compatible (though the NEEDLE_SET command might raise an error, that line could just be removed though. And it would be compatible with the obsolete version in InkStitch.

[tatarize]

There is generally no standardized G-Code for this utility as such the conversions methods are quite arbitrary. As G00 W5 (relative Z) for cut, is dependent on a particular method of making a gcode modded embroidery machine. There's a lot in common with 3d printing in this realm so some of those codes might be relevant.

https://reprap.org/wiki/G-code

However, properly the correct method would be to simply extend the G-Code with relevant and correct methods that more directly relate to CNC machines with sewing machine heads on them. Using G00 and G01 for stitch makes a lot of sense. Other codes like G90 and G91 as well as using X,Y U,V are fine and things like G28. But, other questions like should M00 be used for stop as it does exactly that (STOP) but what about M06 (tool change) for thread change, or just T? M30 is a pretty good parallel for END. Activating trim for example would just be a set command, so some command would need to be decided for that invocation in case. Writing such things would depend heavily on how somebody setup their seemingly hobbyist machine. So generally any exporting would require a dictionary conversion routine, to express the embroidery commands in terms of relevant Gcode.

[jameskolme]

Hello, now I realize this is completely separate topic from inkstitch G-code topic, should have spot sooner.

Nearly done https://github.com/inkstitch/inkstitch/pull/336#

Sample of G-code `(STITCH_COUNT:7709) (EXTENTS_WIDTH:53.3) (EXTENTS_HEIGHT:39.1)

G0 X0.0 Y0.0 G0 X15.231 Y-18.482 G0 Z5.0 G0 X15.310 Y-18.482 G0 Z10.0 G0 X15.390 Y-18.482 G0 Z15.0 G0 X15.310 Y-18.482 G0 Z20.0

ETC,ETC,ETC.... M30 ` There is only G0 rapid movement used, it is controlled from controller to suit current machine, no need to go slower.

Other codes like G90 and G91 as well as using X,Y U,V are fine and things like G28. But, other questions like should M00 be used for stop as it does exactly that (STOP) but what about M06 (tool change) for thread change, or just T? M30 is a pretty good parallel for END.

I highly recommend not to use anything outside X,Y and Z. Hobby machines normally start with absolute coordinate system and predefined measuring system with correct plane, X,Y,Z. So program can start directly as shown, if G1 is used there must be predefined feed for it.

If M00 is used, there is resume button for going forward, but not sure why to stop. M6 can be used for thread change, but tool change does not exist on hobby level CNC. If there is tool change, it simply means there is second program for it. M30 is actually must have at the end, it resets controller for manual use and idles all the motors.

Program starts and stops on manually placed origo, this is normal to CNC without homing switches. Again without homing, this keeps on simple side and normal sewing machine pressing food does not rise high enough for free moving.

It seems I have first arduino/GRBL CNC powered embroidery machine sofar. Using only G0 for feed and stitch movement is 5mm on Z axis. This makes most cense and it is sort of obvious to do it like this. This 5mm is of course machine related, I just geared down my sewing machine to find bugs and currently Z movement needs to be 10mm. If I ever do multicolor I have more than one program at that point.

[tatarize]

W isn't a different axis it's often the relative Z value, so it's the same axis but non-absolute. So rather than G0 Z5 ... Z10... you could consistently use W5 for relativistic movement. At least depending on the controller. Also, if you told it to do Z0, Z5, Z0 would it work? Wouldn't it just spin the other way which in a sewing machine won't change much with the feed dogs disabled.

There's a couple other systems that work vaguely in the way yours does.

http://www.legoism.info/2014/02/nxt-embroidery-machine.html https://openbuilds.com/builds/embroidery-machine-with-xy-belt-and-pinion-drive.691/

In general it seems like rotating the handwheel is a pretty solid plan for doing such an embroidery machine. I could see properly useful mod kits for that.

You'd stop to do things like change the applique, or to change the thread if you don't have multiple needles in the machine. For reading I'll just code it up to map the commands to the other commands, and take solid guesses what people might use going the other direction. It shouldn't be too hard to read .gcode files, and make some solid assumptions as to what people might be doing with some of those commands.

In theory a solid implementation needs something to indicate a new color, in case you wanted to do something like take an embroidery in .dst and convert it to gcode. It would need methods to do color_change, and trim, jump_stitch, and stitch. There's so many different ways for a hobbyist to do something there that it's not simply a 1:1 with a mapping people could properly map commands themselves is they wanted for their own hobbyist project to work.

Imagine somebody wanted to do a trim. And the way they want to do that is to put a cutting blade on the device. It would be entirely possible to do a cut by sending it gcode to move the XY location so that moves around the cutter, to do the cut. Like a post with a razor blade on the outside attached to the hoop. Or basically anything.

I can't necessarily predict all hobbyists going forward. I'll properly make sure it writes the stuff you use, though, so you could do something like use pyemb to convert a bunch of embroidery files to .gcode or .gcode to a .png or back to .dst or whatever.

I see why the 3d printer folks have a nice long article on supported gcode commands etc.

[jameskolme]

if you told it to do Z0, Z5, Z0 would it work? Wouldn't it just spin the other way which in a sewing machine won't change much with the feed dogs disabled.

With old sewing machines, it will spin on both directions, there is nothing to prevent that. It is good practice to wire stepper driver such a way it only goes forward or idle. When hard wired it only needs correct distance.

It shouldn't be too hard to read .gcode files, and make some solid assumptions as to what people might be doing with some of those commands.

As long as there is enough flexibility to modify things. There needs to be space to add lines before and after this specific command, then it will work.

Trim is quite doable to code, not sure how to do mechanically but with my contraption, there are spindle command lines and mist control free for imagination.

With hobbyist it is every time the case, nothing is standard and there are too much variations.

[tatarize]

Yeah, with embroidery there's only a few core commands that relate to actually doing things on the machine.

• Stitch is stitch.
• Jump is stitch but block the needle bar so it doesn't stitch. So that it's all timed and goes at full speed and the distance change occurs while the needle is up and if you can't get to your destination in time you gotta stop it from sewing.
• Sequin mode, turns on the sequin device so all the jump stitches from that point count as sequin eject commands.
• Sequin eject, tosses a sequin in there to be sewn down.
• Color Change: typically stops the machine but sometimes the machine is programmed with the sequence of which needles to use.
• Needle Set: changes to a specific needle.
• Stop. Stops the machine so you can do something, sometimes add applique sometimes change the thread.
• Trim. Actually physically trims the thread.
• Slow. Barudan and a few others have slower speed so some operations that can't quite move that fast get slowed down.
• Fast. Goes back to full speed.

There's also some machines with things like laser cutters for the applique, but no format, as best as I can tell, uses that. But, It's pretty easy to see how such things could use Gcode for all of that in a much more standard and reasonable way. But, for the hobbyist parts, what the machine does depends on how it's built, I could make reasonable guesses from the milling and lathe commands for what people would tend to use. Though really it would need some standardizing for the formats to be properly exchangeable.

So as 100% of the gcode sewing machine embroidery community, which commands would you use if you were using commands? Mostly if you were going to do a multicolored designed what command would you use while you switched the thread? What about if you wanted to trim the thread? Internally I'll code it up to map gcode->embroidery allowing multiple commands for either. So 1 gcode command could turn into 4 embroidery commands or 1 embroidery command into some number of gcode commands. And just parse the format accordingly.

In theory a hobbyist would only need to rewrite that mapping to issue different commands, or read/write the commands differently. And all the rest of the code would be fine. So something like pyemb -i *.dst -o %f.gcode could convert all the dst files into gcode versions. Or pyemb -i *.gcode -o svg to convert some gcode data into an svg file.

Though really it seems a bit like to properly deal ambiguity it might be best to simply make a file that easily maps embroidery commands to gcode commands, and back. Then it would be pretty easy to just edit that without having to recode the gcode stuff yourself, just change the file it uses to tweak the mapping.

STOP: M00
COLOR_CHANGE: M00
TRIM: (no trim)
NEEDLE_SET: M00
END: M30
STITCH: G01 X%x Y%x\nG01 Z%(z+10)
JUMP: (skipping jump)
SEQUIN_MODE: (skipping sequin)
SEQUIN_EJECT: G01 X%x Y%y

It could just check for a gcode mapping file, and if one exists use that, or use the default mapping. I'll give it a bit more thought, trying to make sure it gets written once and doesn't need to be rewritten might take a bit of thought but could certainly be worth it.

[jameskolme]

So as 100% of the gcode sewing machine embroidery community, which commands would you use if you were using commands? Mostly if you were going to do a multicolored designed what command would you use while you switched the thread? What about if you wanted to trim the thread? Internally I'll code it up to map gcode->embroidery allowing multiple commands for either. So 1 gcode command could turn into 4 embroidery commands or 1 embroidery command into some number of gcode commands. And just parse the format accordingly.

Changing thread, it is either next program or info text for next color with M0. My current controller does not support M6. Trimming I would assume first move to location and execute something that actually trims, it could be M4 M3 M7 M0 delay or some other on lower end commands.

Though really it seems a bit like to properly deal ambiguity it might be best to simply make a file that easily maps embroidery commands to gcode commands, and back. Then it would be pretty easy to just edit that without having to recode the gcode stuff yourself, just change the file it uses to tweak the mapping.

This is exactly how it is done on professional CAM software's. https://en.wikipedia.org/wiki/Post_processor This works really well and are very simple to modify. Post processor makes it possible to program different machines with same CAM program, just simple select correct post processor.

[tatarize]

@rlee05

We're retrofitting a Singer 4432 to be an automatic embroidery machine with a custom hoop controller and speed controller.

Are you just setting the speed up within the hobby elements or are you incorporating speed commands into the actual controller like one might find on the FAST and SLOW commands of a Barudan format? -- Typically this allows on the fly speed tweaks to avoid thread breaks etc.

[tatarize]

Added a working gcode reader and writer. Should likely be compatible with other gcode you've written as such. So something like pyemb could convert those gcode files to pngs or any of the nice other functionality that become available.

Worked on some of the gcode spec too, I'll consider some of the basic functions going forward. But, not sure anybody would care. Likely it should have parameters and there might be an easier way to convert the code over to something that fits the standard a bit more concretely.

https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374

[rlee05]

@tatarize

Are you just setting the speed up within the hobby elements or are you incorporating speed commands into the actual controller like one might find on the FAST and SLOW commands of a Barudan format? -- Typically this allows on the fly speed tweaks to avoid thread breaks etc.

I'm not really sure what you mean by "setting the speed up within the hobby elements". We were planning on setting the speed within the controller. I.e. ignoring any speed commands from the gcode instructions. It depends how well we can actually control the speed. We want to be able to plug our controller and send an analog signal into the 3-prong connector where the foot pedal would usually be plugged in. Does that answer your question?

[tatarize]

I mean within the gcode. Yes, it answers my question. There's clearly gcode elements to set the speed for various controllers and there's some embroidery formats which overtly support speed changes. Like rather than going at full speed they crank down the speed at one particular part of the design to avoid a thread break. I asked because there's both gcode codes for that, embroidery commands for it, and potentially reasonable reasons to have it. So if somebody else is doing gcode embroidery and wants speed commands, I wanted to check if I had my bases covered.

EmbrodePy already does direct stitch edits and tweaks so it wouldn't be hard to load up a dst, throw in a slow command and a fast command a bit down the line and save that out to gcode. Generally intended for @wwdrew to do exactly that but with u01. So if there's some need for per stitch edits of the gcode that's plenty doable, or to view already saved gcode files.

Yes. Answered. Bases covered.