Gimbled laser head for 5 axis 2.X design

[dirktheeng]

All,

I had a bit of time and an idea rolling around in my head since last weekend. We went to visit Falling Water up in PA, and in the gift shop I saw a whole bunch of overpriced artwork which was cut out with a laser. One of the more interesting pieces was a lamp and it had mitered corners that were also cut with a laser. That got me thinking about how we could do that. Ofcourse, we can use a jig to hold the pieces at an angle, but that really limits the size and isn't very easy as it requires setting up a jig for every miter angle we want to use. So, I thought about it and came up with a gimbled design that we can cut with our lasers. Here is the initial sketch. I will probably change a bunch of stuff and need to add actuators, but this will allow us to cut up to 45 degree off vertical in any direction.

Gimble Vertical

The laser beam enters into the gimble through a 10mm hollow shaft in the upper right. The gimble is allowed to swing about the same axis as the incoming laser beam. The inner gimble is set up to swing on an axis perpendicular to the outter gimble. The mirror swings on the same axis as the inner gimble. The pulleys in the front of the design are set up so that the angular swing of the mirror will be exactly half that of the inner gimble assembly. The face of the mirror is adjustable and set to be exacly on the swing axis of the inner gimble. Therefore, no matter what the angle of the inner gimble, the laser beam will always hit the lense in the same spot and go through the narrow opening in the nozzle.

Here is another view showing both axes at an angle:

Gimble at an angle, both axes

Here you can see the hollow shaft that the laser comes through and the mirror which bisects the inner gimble swing angle.

The outter gimble stantions are what would attach to the gantry car. Of course we would have to make a different car too, but that isn't hard. Right now, I designed it with 1/4" HDPE plastic (all the black stuff). It gets a bit klunky and I may be able to reduce the size to 1/8" to make it smaller. Right now, the outter stantions are 4.85" wide. The current car is only 3.5", so we will loose an inch of travel in the X axis. I think I can make some of that up providing I can get some really good and flat 1/8" material to work with.

We are also going to have to put the Z axis on some sort of rail system as well because it has to move up with some accuracy when the head swings. If not, then the cut lines won't match up.

I was thinking about actuating this thing with hobby servos with an arduino to control it. I was going to set up the arduino to read the pulses and direction signal from Mach 3 and translate that into the appropriate PWM signals to control the servos. What do you all think?

[awesomenesser]

I can't speak on the how you would come up with the g-code.

But I can tell you that in order for you to use servos you are going to need to modify them quite a bit. The standard servo can move 180 degrees and has one byte of precision which would get you 0.7 degree steps. I do not believe this would be good enough by itself. But you can modify servos to be much more accurate.

Take a look at the link below:
http://www.01mech.com/supermodified

This modification would give you 360 degree control, you only need 90, and a step of 0.088 degrees through the use of a 12 bit magnetic encoder. The modification also includes a motor driver circuit and a AVR microcontroller (same as the arduino). So if you programmed everything correctly you wouldn't even need an arduino. Although you could use an arduino anyway and communicate with both servos at the same time using I2C.

[dirktheeng]

Wow... That looks really good. I may have to look into ways to control this directly from Mach 3 outputs. I don't know that much about Mach 3 at this point. I know I can do it with the arduino setup. I'm going to have to explore a better way to make arduino talk to mach 3 as well. Anybody got ideas?

[Knack]

What you are essentially doing is adding a 4th axis. I believe that Mach and EMC will handle a 4th axis. Now getting it engineered is another story.

[dirktheeng]

It is a full 5 axis solution. You have to incorporate the Z axis as well as X and Y as well as the 2 gimble axes. During the cut program, you have to move the Z axis up and down to keep the material in the optimal focal distance from the lense. Mach will do up to 6, but you have to use 2 parallell ports for most machines like that and we will have to use 2 for this as well because the revised PCB uses almost all the pins from 1.

[awesomenesser]

The arduino code should be rather easy. The communication between mach3 and the arduino should also be fairly easy if you use the second parallel port. Mach3 communicates to each axis with 2 parallel pins one for step and one for direction. So all you need to have is 2 counters which are incremented and decremented depending on the status of the step/direction pins for each axis. Then this count is send through a I2C(serial) to the servos which will rotate to the necessary angle. I would also add a physical button that clears the counters in the arduino this way you can zero mach3 and ensure the laser is zeroed.

Overall this should be fairly easy to do on the electronics and hardware level. I can see it now a Mach3 gimble shield for the arduino.

[dirktheeng]

I was just reading up on modbus with the arduino. do you think we could control an axis with modbus? It gets used mainly for IO, but could it be used this way too?

I like the strait up hardware solution. We could use a counter and a PWM generator with a way to scale the pulse width to a particular value.

The other thing is that the arduino (i think) has that stuff on the board. I know that it has PWM generators on at least 6 of the output digital IO pins and I2C... we should probalby use that. I don't recal if the counters are implemented in software or hardware. it would be beter if they were hardware. At any rate, the arduino can't update the output any faster than 16 Mhz, realistically 2 mhz. That is still much faster than we need. We will have to prioritize which functions we need in fast, medium, and slow loop execution.

Do you recall if the arduino has hardware counters? How about i2C hardware counters?

[dirktheeng]

I'm no EE, but i do remember making this circuit from my EE class in college (about 8 years ago now). I'm going to have to dig up my notes and study, but this looks like what we could use. I would be surprised if they didn't sell a multi register counter somewhere. I would really like to find an IC2 solution though.

http://www3.telus.net/chemelec/Projects ... ter-UD.htm

[awesomenesser]

You could do this with straight hardware but I don't think that would be the easiest approach. First off I would just use an AVR for this project, it would be far more cost effective than buying an arduino and having a board/shield made. I would build a small PCB with a parallel port and a ATtiny2313 which costs less than 3 dollars and runs at 20Mhz. The AVR would have the two step pins connected to the external interrupts, then the two direction pins attached to some free IO. We then have two options which we could go. One would be to use standard hobby servos using two PWM outputs, which I do not believe would be accurate enough. Or we could go with two super modified servos which would cost a little over $100 for the two of them. For how simple this application is you wouldn't even need to use the I2C communication you could just stick with basic serial. With serial the RX and TX lines would run into each of the supermodified servos.

The program would consist of two interrupt service routines, two global integers for storage of the rotation values and a function that can send the rotation values over the serial lines. The main loop would check for changes in the integers if there was a change then it would trigger the "send" function. The main loop would also watch for a change in the "zero" button if there is a change then it would clear the integers. The interrupt functions which would trigger on rising edges of the step pins would check the direction pin and if high increment otherwise decrement the proper angle integer. Each of the servos would be programmed to receive their angle values then immediately turn to them. In the standard servo implementation the "send function" would change the PWM values.

This might seem fairly complicated but it would be one of the simplest programs I have ever written, should only be 30 or so lines. And its use of interrupts should make it run as fast as the little AVR can go.

[dirktheeng]

Well, that may be very simple, but I plan on using an arduino in my project anyhow (see barts notes on laser power control using modbus http://www.buildlog.net/blog/2011/02/mo ... ins-oh-my/). I was thinking of going this rout:

1) Find/make a good 12-16 bit up/down counter. The direction signal from the parallel port will control the up/down behavior and a manual reset will be available and also tied to the homing switch.
2) connect the ouput of the ocunter to this parallel to I2C connector http://www.sparkfun.com/products/8130
3) run code on the arduino to check the I2C bus for the bit value of the counter, do the math, and send a position signal out via I2C to the modified servo
4) in the same loop read any other data read the serial buffer from the USB and communicate via modbus to Mach3 if necessary.

I like this approach because the counter is sure to catch any bit change up to several tens megaherts and will act as an on demand integrator so that no stepps are missed in case the arduino gets busy with something momentarily. The above code should also run very fast on the arduino, so this isn't likely to hurt anything anyhow, but it's best to run a hardware based integrator. This is especially true when I want to use a smoothstepper which can run up to 2 MHz signals to the steppers. At that point, an arduino may have problems keeping up, but it shouldn't make much difference becuase the counter will not miss the steps and the servo's will get updated at whatever the max frequency of the loop is and get sent the most up to date position value at the time it gets read. This approach should keep everything up to date up to about 400khz or so. I think that is the limit of the I2C communication protocol.