Stitch Regulator for CNC Quilter

[_rushin_or_draggin_]

So I’m in the process of designing a CNC quilter since they’re rather expensive. My idea is to take a manual frame and add stepper motors to it to automate it for intricate designs. The CNC part itself shouldn’t be too bad, but what I’m working on now is a stitch regulator. As the CNC runs, straight lines tend to be faster than curves, so you need to vary the speed at which the sewing machine stitches to maintain equal stitch length (like the foot pedal). My plan is to use an arduino with a digipot and rotary encoders to accomplish this.

This is what I’ve figured out so far. My machine uses a rather complicated pedal but I have already reversed engineered it and made another and all I need to do is change a variable resistor to change speed. My thought process is I will use 2 rotary encoders (for x and y) in tandem with the drive belts for the CNC part to measure speed.

This is where I’m confusing myself. So if I use 2 encoders between the drive belts, do I just take the pulse count, convert that into distance (from circumference of the wheel attached to it) square that value (for both x and y), and then take the sqrt of the sum of those results and divide by my interval? That is, distance (using Pythagorean theorem) divided by time? And depending on this speed I can use a digipot to adjust the resistance for the sewing speed? I have some experience in coding for arduino but not a lot. Any help or recommendations would be greatly appreciated!

[moffy]

If at all possible could you substitute a DAC for the 'digipot', it might only take a small modification, to the 'stitch' circuit and a DAC is better suited to the constant variations. The stitch distance calculation will seldom be a perfect integer so care will be needed to accumulate the remainder for future calcs so that stitches are not missed.

[_rushin_or_draggin_]

I suppose I could. Do you have any recommendations on how to incorporate that? The sewing machine itself outputs a 5 VDC signal (with very tiny -5v pulses for a pedal detection circuit) and uses the resistance in the foot pedal to variate speed. I thought a DAC would only output a voltage? Is there a way to make it as a pot?

*edit* unless I can modify the circuit to take the DAC output voltage. The problem is I don’t think I could bypass the protection circuit that way. I can attach a schematic if you’d like.

[_rushin_or_draggin_]

Alright, so I’ve managed to get the machine to think there is a pedal attached while also varying the input voltage from 5VDC for no stitching, to 0V for the fastest stitch. I should definitely be able to use a DAC now.
The machine seems to have distinct steps in speed that change every 0.1 volts so making a stitch regulator should be much easier. I think my next step is to plot the changes in speed w.r.t. voltage because I’m not sure if it’s entirely linear or not. The machine starts stitching around 3V and is at max speed at 0.
Once I get those determined I guess I just need to setup some if statements and if the decoders detect a certain velocity range it will set the DAC at the voltage needed to maintain stitch length? Or is there a much simpler way to do this?

[moffy]

Alright, so I’ve managed to get the machine to think there is a pedal attached while also varying the input voltage from 5VDC for no stitching, to 0V for the fastest stitch. I should definitely be able to use a DAC now.
The machine seems to have distinct steps in speed that change every 0.5 volts so making a stitch regulator should be much easier. I think my next step is to plot the changes in speed w.r.t. voltage because I’m not sure if it’s entirely linear or not. The machine starts stitching around 3V and is at max speed at 0.
Once I get those determined I guess I just need to setup some if statements and if the decoders detect a certain velocity range it will set the DAC at the voltage needed to maintain stitch length? Or is there a much simpler way to do this?

Congrats on managing the modification so quickly.
I am not really familiar with the stitching side of the CNC, but the advantage of the Arduino is that it is easy to experiment with and find what does and doesn't work.

[jwet]

This is pretty fascinating- I've done a lot of CNC stuff but never with quilting- my wife is a quilter, at least used to be.  I'd like to help.


I'm going to back up a little- are you building this from scratch or modifying something?  From what I know about quilt overstitching, you use a sewing machine and follows concentric outlines in the patterns.  It sounds like you've gotten into the pedal controller for a sewing machine and are trying to drive the sewing machine and keep it in sync with you XY table that is driving the fabric around in x and y?

Here are a few other comments-

Going with a DAC is probably a good move- pots and dac's are almost the same but dacs are specified in ways that let you know what your errors are.

You might not need encoders as long as your stepper motors don't lose steps or get bogged down.  One of the nice things about stepper is you can run them in open loop and get good results.

Your Pythagorean formula sounds correct but using sort of a polar scheme (radius and theta) might make more sense. XY control would have X and Y and a speed, in polar you'd have an angle you're advancing in and a speed.  This angle might be arctan (y/x).  Arduino's can do trig but are not real fast at it.  There are work around like look up tables and there are faster compatible alternatives to basic arduinos if necessary.

I'm impressed with your progress, please post more if I might help.

[_rushin_or_draggin_]

So you can buy quilting frames that you can set a regular home sewing machine into and use that for free-motion quilting, meaning you control where the needle goes via some handles and the speed the machine stitches with the foot control pedal. This is a great option for someone that doesn't want to purchase a dedicated longarm quilting machine. My plan is the take one of these existing frames and computerize it. The cool thing about computerized longarm quilting machines (in the neighborhood of $16k USD) is they have something called a stitch regulator. Since it's rather hard (at least as far as I know) to make sure every step is at the same exact speed, these machines utilize a stitch regulator to vary the speed at which the machine stitches with respect to how fast the material is moving. They usually use optical encoders directly above the workspace so they can work on pretty much any machine, but they're super pricey. Essentially, the stitch regulator is entirely separate from the CNC part. Imagine getting rid of the motors and you move the machine by hand and the machine will still stitch at the same length despite you not keeping a constant speed.

These stitch regulators plug into where the foot control plugs in, so I figured I would have to match that. Once I bypassed the protection circuit, I found that varying my input voltage (0-5VDC) I am able to adjust across the entire range of the machines stitching speeds. I figured if I can measure the velocity at which the "tool" is moving across the work, I can input the correct voltage to make sure I am stitching at the correct speed.

I have had another thought though, say I want my stitch length to be 8 stitches per inch, or about a 3mm stitch. If I attach a pulley of known diameter to an encoder that is attached to the same stepper motor (either between the existing belt for the axis or tapping off the same motor), I can take its circumference, divide it by the P/R of the encoder, and that will give me the distance per each pulse, correct? I can then, in a given time interval, take the amount of pulses and multiply it by this "distance per pulse" constant to get my total distance covered in that period for both axis. I could then divide it by my stitch length and that would give me how many stitches I would need in that given instance. I could then have a "table" with these values and it would pick the value closest to the calculated value.

Obviously, this wouldn't be super, super precise, but that's okay, it doesn't have to be. I believe if I can keep the interval short enough, say 50ms or maybe even 100ms, whatever works, it will get me close enough to matching speed.

That being said, I'm not using the encoders as a way for the CNC to track the tools location, but rather as sensors to measure the speed at which the material is moving in a given time period. I'm sure a polar system would be faster (given it is just a angle and magnitude), but I am not sure how I would easily implement it. The quilting frame already only moves in an x and y direction and I will already have drive belts to run these axis for the full length of the frame, but maybe I am missing something?

I think if I can get this stitch regulator implemented correctly then the rest should be a walk in the park!

Also, check out this guy's design. It's pretty much exactly what I plan to do, but his wife's machine already has a stitch regulator installed.
https://youtu.be/tQJAv6M2AA0?si=0SHT0jbt1t0ONCii

[_rushin_or_draggin_]

I have done some more tests and found that the current draw on the pedal jack is less than a milliamp. I happen to have an Arduino Due that has 2 DACs onboard that go to 2.5VDC roughly and supply around 3 mA at best. The machine does demonstrate a weird characteristic in that while decreasing from 5 to 3 volts is enough for the machine to stitch at it's lowest speed, increasing to, for example, 3.3 volts will not cut it off...at least I don't think it will. I am going to mess with some code on the Arduino Due and see how the machine reacts. If all is well I will source some rotary encoders and see if they will play nicely. If not I will source a DAC and see if I can make it work.I'm currently feeling really good about this project!

Turns out my due is fried...dang. Well, I suppose I'll just order a dedicated DAC to use with my Uno that I know works!

[ajb]

Neat project!  Definitely one I've daydreamed about whenever I've had to do any sewing 

The sewing machine itself outputs a 5 VDC signal (with very tiny -5v pulses for a pedal detection circuit)

Depending on how the pedal is wired and how that -5V pulse is generated by the machine, this could have important implications for how you connect your circuitry -- it could also be the reason that your arduino died.  For example if the machine creates that -5V pulse is by swapping the 0V and 5V terminals, that could make interfacing with the rest of your circuitry tricky. 

The machine does demonstrate a weird characteristic in that while decreasing from 5 to 3 volts is enough for the machine to stitch at it's lowest speed, increasing to, for example, 3.3 volts will not cut it off...at least I don't think it will.

It's pretty common to have different on and off thresholds, aka hysteresis, for circuitry like this -- without that difference, voltages near the threshold could cause the circuit to switch on and off rapidly due to noise or offsets induced by the circuit itself turning off and on, which leads to self-oscillation.  You might just need to have a larger voltage step between your minimum speed and off.

This is where I’m confusing myself. So if I use 2 encoders between the drive belts, do I just take the pulse count, convert that into distance (from circumference of the wheel attached to it) square that value (for both x and y), and then take the sqrt of the sum of those results and divide by my interval? That is, distance (using Pythagorean theorem) divided by time?

That's pretty much it, but some care will be needed in the implementation.  For example, consider what happens as the speed reduces towards zero: the effective resolution of your calculation becomes more coarse and noisy as the number of pulses per period decreases.  Rather than just counting the pulses in a unit of time, you probably want to track the absolute position of each axis, and calculate velocity from there.  That will make it easier to handle changes in direction, and by doing the pulse-to-position conversion first you can do the rest of the calculations in more natural units.  You will probably need some filtering in there somewhere in any case. 

The other option would be to flip the problem around entirely and treat the sewing machine as another axis and control its speed via the program.  This is basically how 3D printers work: to extrude a certain width of line, the extruder has to advance at a certain speed relative to the XY speed of the print head, so the program can tell the controller to move the X,Y,E axes from (x1,y1,e1) to (x2,y2,e2), and the controller computes the speed of all three axes through the whole move based on whatever acceleration parameters.  (I know there are more sophisticated extruder control algorithms these days, they're not relevant here.)  In the same way, to get a certain stitch length, you need to spin the machine at a certain speed relative to the XY motion, so the machine motion can be calculated at the same time as the XY motion and appropriate speed commands baked into the generated program.  I don't know if any of the existing tools for generating/executing CNC programs you might use would be able to generate the required speed commands automatically, so that part might be a bit tricky. 

Directly controlling the sewing machine's motion would make the software side of these even simpler, at the expense of somehow replacing the sewing machine motor with some sort of servo.  That would probably be a destructive operation on a modern electronically controlled machine, but might be pretty easy with an older mechanical-only machine -- often seen in relatively good shape in second hand stores around here -- where you might be able to drive the handwheel.   Then it can be programmed exactly as above, which puts it right into the paradigm that existing CNC controls and software are designed for, so you could directly use a ton of existing software, hardware, and open source projects both to run the machine and to generate toolpaths for it.   An encoder or position switch would let you program needle up/down for stops as well. 

[Someone]

flip the problem around entirely and treat the sewing machine as another axis and control its speed

This is the answer, where rather than controlling speed you want the stitch axis to be controlled with a synchronous position relative to the x-y axis.

[_rushin_or_draggin_]

it could also be the reason that your arduino died.

Actually my due was fried from a previous project as I wasn't even able to upload the code to it! I must've shorted one the the pins awhile ago because neither the programming nor the native ports were recognized in device manager.

flip the problem around entirely and treat the sewing machine as another axis and control its speed

This would be ideal, however I have not been able to find many software options that would easily allow this. You can find profiles for routers, torches, 3D printers, etc. all day, but not so much one that would fit a sewing machine. Unless I am completely overlooking something. The extruder option of a 3d printer does sound like it could potentially be a good match however, I just don't know where to start to implement the stitch command in place of the extruder command.

What's strange is even the high end machines along with their dedicated software seem to not incorporate this either. Pretty much all machines I can find use a dedicated stitch regulator and I'm not entirely sure why. I'm sure there are machines out there that treat the machine as a dedicated axis, but I haven't had much luck in finding one.

You might just need to have a larger voltage step between your minimum speed and off.

That makes sense. My current plan is to use a DAC with an Arduino to step through the voltages (both increasing and decreasing) while having a push button count the amount of stitches in a minute. This way I can fully map all speeds of the machine (There seem to be 25 or so distinct speeds). I should be able to find points in both directions where the voltage graphs overlap and I can use that to switch to a different stitch speed accurately.



Unless there is a way to easily implement the machine as a 3rd axis, my current thought process is to map these speeds, figure out how many stitches they do in whatever period I decide on, and store them in an array. Then, as I previously stated but this time ignoring velocity, calculate the distance the encoders have measured and divide that by my stitch length (say 8 stitches per inch). Then, that will tell me how many stitches I need in that given period and I can access the array and send the closest value to the DAC. I think this would also make it much easier to change my stitch length if I wanted to (just change the variable, whether in code or setup a prompt for the user to input a value).

Of course going this route means the machine stitches will very slightly lag the stepper motors, but that is completely fine. The machine itself moves at a (relatively) slow speed and the sampling period would be (again, relatively) small. I think that should be okay.

I do agree that replacing the machines motor with a servo would aid in making it a dedicated axis, but, like you said, newer machines will be much more difficult to do. I think I would prefer to go the route that preserves the machine in it's current state (especially so I can have the flexibility of switching to other machines because most seem to use the same pedal logic).

I don't have a lot of experience with CNC, so I currently have no idea where to start to implement the stitching as a dedicated axis.

[ajb]

flip the problem around entirely and treat the sewing machine as another axis and control its speed

This would be ideal, however I have not been able to find many software options that would easily allow this. You can find profiles for routers, torches, 3D printers, etc. all day, but not so much one that would fit a sewing machine. Unless I am completely overlooking something. The extruder option of a 3d printer does sound like it could potentially be a good match however, I just don't know where to start to implement the stitch command in place of the extruder command.

It doesn't necessarily matter what the software or controller thinks it's controlling, as long as you can get it to generate the right motion commands, so it doesn't necessarily require you to implement anything.  If you were to set it up as a 3D printer, with the extruder axis mapped to the 'stitch' axis, then a program that would extrude a constant-width line along some path on a 3D printer will give you a constant-length stitch along that path just like you want.  It's mostly a matter of figuring out what workflow is the easiest to adapt to what you need. 

G-code programs are mostly a list of coordinates on one or more axes that the machine should move through, like the below, taken directly out of a 3D print program:

Code: [Select]

G1 X93.259 Y64.692 E.0321
G1 X94.303 Y63.95 E.04016
G1 X95.891 Y63.429 E.0524
G1 X97.5 Y63.272 E.05069

'G1' means 'move at a defined constant speed', and the X, Y, and E values are the X,Y, and extruder axis positions to move to.  If you can get something to generate G-code for the basic XY moves for your desired path, it would be pretty straightforward to calculate the required position of the stitch axis based on the XY move distance and append it to each line of the program.  I would look at software designed for pen plotting, as that should generate pretty simple G-code, and the post processing could be done in Python or just about any language you like.  Lots of ways you could go to leverage existing tools to simplify the software side of things, but of course this all depends on some possibly significant mechanical modifications to a sewing machine. 

What's strange is even the high end machines along with their dedicated software seem to not incorporate this either. Pretty much all machines I can find use a dedicated stitch regulator and I'm not entirely sure why. I'm sure there are machines out there that treat the machine as a dedicated axis, but I haven't had much luck in finding one.

Presumably they need the stitch regulator to support manual movement of the machine/workpiece anyway, so it's simpler just to use that all the time -- and means the sewing mechanism itself doesn't need to be any different from the standard machines. 

[_rushin_or_draggin_]

I have made a ton of progress on this project as of late. I used an MCP4725 along with a simple Arduino program to simulate all possible ranges of the machine. I have found that the off state and the slowest speed state have wide ranges (as expected). However, once past that, the speeds change linearly. Decreasing and increasing states differ between each other by 0.1 volts (meaning, if you are in say state 5 at 1V and go to state 6 at 0.95V, you must increase by 0.15V to get back to state 5). This makes it much easier as I can use a few if statements for the special cases and then map the rest of the speeds to the 12-bit DAC thus eliminating an array for a lookup table. There will also be an if statement to take care of the 0.1V gap between states.

I have also gotten the encoders to work rather well with the Arduino. I have made the code fully adjustable to whatever size pulley is to be used on the stepper motors, whatever stitch length the user desires, and is fully mappable to any modern machine with this digital pedal input. I have also started messing around with circuits utilizing triacs and using the Arduino (opto-isolated of course) to control the phase angle the triac fires off at. That way I am not limited to just modern machines. Whether I will continue using triacs I don't know, but it is a start.

Back to the first part, I plan to take the fastest speed and the second slowest speed (all of the non-special states) and determine the stitches-per-minute rate, take the difference, and then divide by the overall voltage difference to get the slope. Then I can write a program that multiplies whatever stitch rate (determined by the encoders) by this slope to achieve the correct voltage sent to the machine.

Attached below are the plots with all the test voltages and there respective states. Notice the end of the increasing voltage graph has a dip, this is caused by the 0.1V shift I mentioned earlier.