I'm new to Arduino and only have a general grasp of programming but I've engineered and built quite a few things. Here's what I want to do:
Record motion of an incremental encoder that has a resolution of 2048 pulses per revolution. Save that data inside a sketch where it is used to operate a stepper motor that will duplicate the same motion at the push of a button.
Is this possible?
I've seen examples where people have done direct control of a stepper with an encoder, but I've yet to see my specific implementation.
I just want to know if it is possible and a general idea of how to do it, but if there is already code out there that I haven't come across, maybe someone here knows.
I don't even have the motor shield yet, but I do have the UNO, and an LED/button shield, and the encoder and steppers for my project.
Yes, it is possible. You need to monitor the encoder and every time a transition is observed, note the direction of rotation and the time since the last transition. If you save this information, later a stepping motor could be programmed to imitate the behavior.
To duplicate the encoder motion, you will need a stepper/driver combination providing 2048 steps/revolution.
I think although its technically possible, it may not be practical to implement easily.
Encoders that have 2048 steps per rotation cost $$$, and I think getting reliable 2048 step resolution from normal hobbyist stepper motors may be hard.
i.e the sort of stepper motors that most people use give 1.8deg resolution, you require over 20 times this value.
Even with micro-stepping, I think getting that sort of resolution is going to be technically challenging
Yes, it would be much easier and cheaper to start with a lower resolution encoder. Even then, matching encoder resolution to stepper resolution is not trivial.
Just to be clear, I already have the Baumer encoder. Yes it was expensive @ over $500. Also, it will be used to measure distance via an O-ringed roller on the shaft. So it will just boil down to steps per unit of distance conversion. That doesn't scare me since I've already built a production CNC from scratch and am running it via Mach 3 with gecko drives.
The encoder/stepper combination is pretty much a standard feedback loop in motion control to verify correct operation so I know that they will work just fine together with the right microstepping and feed ratios. I'm hoping the Arduino can handle a simple two axis pickup winding machine with one axis being rotation only and the other one the X axis.
What I'm trying to accomplish is to guide the wire via hand motions to a linear slide with an encoder attached, store the those movements, then have the machine duplicate those movements later with the press of a button. In this manner, a machine wound guitar pickup could be wound with the same pattern as a hand wind.
So, is this a feasible project for Arduino, or should I pursue setting up another PC based CNC machine? The latter would actually be easier for me, but I'd really like a stand alone machine when I'm done. If it means I get to learn some programming, that is part of the gig, and I'll know my machine inside and out when I'm done. interface is planned though an LCD and button shield whereby preset patterns and wind counts can be chosen.
Is that too much for an Arduino, or is it just too big a project for a noob to take on.....What say ye?
Arduinos have very limited RAM memory, so if there are complicated moves to store, you would need to write them to an SD card or some other external storage. There are standard interfaces and libraries for that, but expect a learning curve.
I don't think the moves would be complicated, just basically back and forth for about ten minutes , but I imagine that resolution would be a problem on the RAM because it would be storing a ton of pulses. Maybe I need to dumb down my encoder..... I think I can leave one of the three pulse train wires off for lower resolution.
Using Mach to do it would be too easy, but I'd actually like to have two of these winders set up. I've already got two different PC's in my shop running motion control and I'd rather not set up two more for such simple processes. I've already wound a few coils with Mach and custom G coding. It is not to just wind a few coils and be done, I'd like to develop a pickup winding machine that is my ultimate goal. Not having to tie it to a PC would be great.
look at the arduino based cnc controllers then if you can g code it why not go the cnc rout.
its the process you need. simple make up a controller with a screen have speed, feed, and movement control
that can be adjusted as needed, (like a lathe control as an idea) have it save to a sd card to be loaded later.
if your capable of building cnc machine this should be easy for you not being smart.
if your coil winding something, a A axis set up with an over head gantry for back and forward movement of the wire would do it.
you could have the wire coils on a over head set up depending on how big the coils need to be you could do many at a time so only one command to do many coils at once.
you would just need to work out a maths formula for setting speed and feed once you have that done just change setting on the controller or pre load from a sd card.
if I was doing a straight out coll winder that's how I would do it
daniellyall:
look at the arduino based cnc controllers then if you can g code it why not go the cnc rout.
its the process you need. simple make up a controller with a screen have speed, feed, and movement control
that can be adjusted as needed, (like a lathe control as an idea) have it save to a sd card to be loaded later.
if your capable of building cnc machine this should be easy for you not being smart.
if your coll winding something like a A axis set up with an over head gantry for back and forward movement of the wire would do it
Pretty much as I envision it. On the menu: Number of winds, then have stored winding patterns for different bobbins to choose from. SD card would be fine.
Yes, building the machine will be easy as you say, but I haven't done much programming and my goal here is to find out if I'm going down the wrong path before I waste a bunch of time on it. I do aerospace engineering, build CNC's, guitar pedals, etc. Lots of practical experience, but not much programming. That's why I'm here asking questions.
Speeds and feeds would all be determined before setting up for a "recorded" session. Wind one coil by hand and store all parameters, save to SD then duplicate later. The goal is to duplicate "hand winding" rather than "hand coding".
I'm assuming not many people here play electric guitar or bass, but hand wound pickups always sound better than machine wound. This is an attempt to capture the hand winding process and duplicate it by machine.
daniellyall:
sounds very doable how many different winds would you have to
Not too many at least at first, but I suppose they could be stored on SD cards.
Here's my thoughts on the workflow, but it is a bit convoluted:
Interface the encoder with the UNO, run the winding session and store the data on PC. Convert that data to G code. Then transfer that file to the UNO with grbl shield. Not sure how many files the Arduino could hold, so it might be better to store the files on SD card for more storage.
What sort of resolution are you looking for ? The data rate is what makes the project feasible or not.
Capturing every pulse change and recording the time interval may not be possible on an Uno. I would guess that sampling the position about 100 times a second would reproduce the hand movement accurately enough?
I think for winding, the X axis does not move very quickly. Therefore I would sample the position at a fixed interval, eg. 100/sec. This would give a manageable 120kb of data over 10 minutes. (1060100*2 bytes).
If you have an incremental encoder, it produces two pulse outputs out of phase, so you can tell the direction. The Uno CPU does not have a hardware decoder, but it is easy enough to do with an interrupt on change. Each interrupt increments or decrements an internal counter. (The direction is determined by the state of the two encoder lines).
With a timer running at 10ms interval, the internal counter is sampled and written to a buffer. At 10ms rate, you would generate 200 bytes per second, so you could transfer that over serial to a PC. (Assuming 2 bytes per sample, +/-32767 counts).
To generate G-code from the data file, you would need to convert the count values to a position in mm, and the feedrate = dist moved/0.01 * 60 (mm/min).
If 10ms is not enough, you could probably go down to 1ms on an Uno before running into performance problems.
I think as a project it's quite doable, if you are realistic about data rates.
bobcousins:
Capturing every pulse change and recording the time interval may not be possible on an Uno. I would guess that sampling the position about 100 times a second would reproduce the hand movement accurately enough?
I think as a project it's quite doable, if you are realistic about data rates.
Awesome response, thank you for your input! Yes, 100 times a second would be more than enough, it could probably be much less. Hand winding is not known for precision or quick changes in speed or direction anyway.
For calculating feed, I'll have to convert the wheel encoder data to distance by measuring the wheel diameter x rotation (or possibly just count pulses per inch or mm) then set up my steps x leadscrew pitch and verify it.
Now if I increase the rpm of the bobbin via XL pulleys and a belt I can cut the time per coil down even more which will help with the file size. Steppers don't turn fast enough. I'm shooting for 1200 to 1500 RPM but might be able to go faster with the right tensioning system. @1500 RPM we'd be looking at only storing about five and a half minutes of data.
I think I've got a pretty good handle on the mechanicals. Not sure what program to use to convert the encoder data to linear though...... I picked a pretty ambitious first project for sure.
Maybe Labview can do what I need regarding data capture of the encoder and scaling it?
I think I've come up with a way to scale the encoder data to the distance moved. Build the machine, command it to move 1" see how many encoder pulses that is per inch. Simple. Beats trying to do the math, then redoing it after the machine is built anyway. Actual data beats theoretical any day.
So I've got a plan to move forward, on to the learning curve.....Thanks everybody for the input!
