BuildLog.Net - Document your builds!


Buildlog Title: 2.x for kbob's maker space

newest first oldest first
Builder: kbob
Member Since: 2012-07-09

Sunday, August 10th 2014 - 11:14 AM

It lives!

Yesterday I hauled the laser cutter out to the garage, wired up the laser power supply, screwed on the rest of the skins, did some last minute debugging, and burned marks on some cardboard.

I'll give the blow-by-blow in a minute, but right now I'm looking at two problems.

1. Focus. I can't find the focal point. The best I can do is about a 1 mm wide beam. I got my optics from Bart's Makerslide Store, which is down now. I don't remember what the nominal focal length is.

2. The Y motor is skipping steps. I have one example where it's a repeating pattern, skipping once every cm of travel. I have another example where it skipped about 3 mm at once. In other cases, it doesn't skip at all. The slower I go, the more it skips. I'm perplexed.

Here's the whole story.

Two weekends ago, I made a little daughterboard for the Azteeg. It sits in the position intended for the 2nd extruder motor driver. It routes the signals for the laser power supply, and it also holds an MCP4725 DAC chip which I use to set the laser's power level.

Then I wrote a bunch of software.

I got the status monitor software "finished" -- it's kind of a dashboard display for the laser cutter.

I redesigned the safety interlock software. The problem is that if you hit the E-stop switch in the middle of a print job, the print commands would continue to be processed, but the lasers and motors were shut off. If you released the button before the print job ended, it would resume at the wrong position. And there was no way to know whether the job had finished. Now, if you hit the big red button, the firmware discards all commands until it receives a Stop command. The Stop command resets the Emergency Stop state, and commands that follow that work normally again.

Finally, the MCP4725 is a 12 bit DAC with an I²C control interface. I learned about I²C, wrote a driver, and put in a new command to set the laser's power level. That part of the API is kind of hacky -- I may redo it.

Yesterday morning, I got my wife to help me carry the laser cutter down the stairs and out to the garage. I hooked up the water and air, verified the water doesn't leak, and tested that software control can switch the pumps on and off.

I installed the laser power supply. It is on a little plywood shelf above the rest of the electronics. I put it up there so it would be close to the laser tube, but then the power supply came with a connector on the + side, so there's about 12" of cable to accomodate the connector. Next time, all the electronics go on the same level.

I attached all the skins. That was straightforward.

I found a piece of scrap wood and placed it between the main laser and the first mirror. I closed the box.

Then I fired up the power supply for the first time. One second later, I used the Emergency Stop button for the first time. The laser came on as soon as I switched the power supply on. A few minutes later, I figured out why. My controller is using active-low logic for the laser pulse, but I'd mistakenly wired it to the power supply's TTL High input. Fixed that.

I had written a test program to fire the laser for 1/10th second whenever I press the computer's Enter key. I'd tested it with an LED standing in for the laser. That program did not set the laser power level, so I added the DAC support to it. Then I spent about 45 minutes debugging a missing initialization call. Link.

That resolved, I could fire the laser under software control.

I was surprised to see that the laser beam is quite wide, about 4 or 5 mm in diameter. I guess I'd read that once, but I'd forgotten.

Aligning the lasers required lots of trial and error, as expected. Having the red laser diode did make it a little easier. It took a while to get both lasers aligned and hitting the center of the first mirror. Then it was quick and easy to align the red laser by eye, and the CO₂ laser was aligned too.

Before I was done, I ended up writing another test program to streamline the process. both-lasers: when the lid is open, it turns on the red laser. When the lid is closed, it fires the CO₂ on the Enter key. I wrote that after about the 10th iteration of reflashing the firmware to do one or the other. (-: Link.

Then I started cutting some shapes. I started with a simple rectangle. Tried various speeds, power levels, pulse speeds/durations, and focal lengths. I never did cut all the way through the cardboard. I'm pretty sure that's because I didn't have a good focus.

I cut some more complicated shapes too, but because of the focus and the skipped steps, none of them completed successfully.


So I'm stoked. And I'm also frustrated. (-:

add commentadd comment in the forum

reader comment Comment from: mpeele on Tuesday, July 29th 2014 - 9:50 PM
The "we" is actually 2 people and we are not part of any organization or organized open source project.

We started on a project in 2009 that required a XY motion mechanism and control soft software. That lead us to Bart sometime in early 2010 and resulted in building a 1.x laser as tool and test platform of software. Last year a ShapeOko 2 was added as another test platform and tool for other projects.

So I guess you can say we are working on three projects, a laser cutter, router and control software running on a Beaglebone/iMac and Beaglebone capes. There is also an IOS app in the near future.

Monday, July 28th 2014 - 8:00 PM

You say, "we." What project are you working on?

add commentadd comment in the forum

reader comment Comment from: mpeele on Monday, July 28th 2014 - 5:49 PM
We have a manual interface because its one of the the first things we did just to be able to fire the laser. But we found a manual fire function really made alignment easy and we use it to check and realign. We use the manual laser enable a lot to verify motion without modifying soft configuration. Manual power level setting I use a lot to, it makes it easy to do a cut on paper by turning the power way down and then let the controller control power on the actual material.

The PRU controls all of the realtime I/O during a cut such as motor controls, laser firing, fault detection and laser power level. The ARM processor controls all other I/O such a fans, pumps and nozzle air and provides a data interface between iMac application and PRU.

Currently we have a prototype virtual pendant function in our iMac application which allows for mouse or touch pad controls. This is just a prototype and we are going to do a IOS application based on the prototype pendant. So many projects, so little time. If you just try to replicate a button based pendent on a touch device it can be awkward but if you use the capabilities of a touch device like a iPhone/iPad you can end up with a very nice intuitive interface. Our approach is not to replicate an old implementation with new technology but analyze it to see what can be done with current technology.

With a 100 BaseT network there is not a network issue with either pendant operation or CNC control for our 1.x machine with Nema 17 motors from Bart, 18 toot pulleys and Gecko 351 stepper drivers powered with 24 V and 1.8 amps. It starts to lose steps at about 80 uSec on the heavy axis so we use 100 uSec as the min step timing. Bone will step much faster than our mechanical configuration will support.

Monday, July 28th 2014 - 4:28 AM

Cool!

I saw that in one of Bart's wiring diagrams -- using TH for software actuation and TL for manual firing. Are you using the BeagleBone's PRU processor to drive the GPIO or doing it through the main CPU?

I'm kind of thinking of an iPad as a pendant someday -- if the web interface is good enough, that should be viable. So I'm not thinking about manual control. Touch screens aren't as good as hard buttons, but they're easier to configure.

add commentadd comment in the forum

reader comment Comment from: mpeele on Monday, July 28th 2014 - 4:12 AM
We are doing a laser controller also but instead of using a Raspberry Pi we are using a beaglebone and have a front panel which allows for manual control for laser power and laser firing.

TH is connected to a beaglebone GPIO pin for bone control of laser firing.
TL is connected to a front panel push button fire switch which is connected to a toggle switch(open or ground presented to fire switch) to enable manual laser firing
WP is connected to a toggle switch to enable laser power supply.
G is connected to digital ground point
IN is connected to a toggle switch which selects either a beaglebone PWM output or a front panel pot which is connected to 5V
5V is connected to +5V supply.

I think ours is wired very simular to Barts 1.x design which is what we have built.

Saturday, July 26th 2014 - 7:15 AM

I've been trying to decide how to wire up the laser power supply's control signals. My power supply has six signals. I think it's the same as most. The labels are cryptic; have are my best guesses.


I am planning to drive TL and leave TH unconnected. I am using a 12 bit D/A to drive the IN signal. I am leaving the WP hardwired to ground for now. Software stops the laser when it detects lid open or the big red button, and I don't have a water flow meter yet.

That gives me four unique signals: +5V, ground, TTL Low, and power level.

Rather than run individual wires to spots all over the Azteeg board, I decided to use the 2nd extruder motor connectors. There are four of them. I am making a daughter board that fits where the stepper driver would be that routes the wires and holds the extra circuitry. I'm using perfboard. I got it about half soldered this morning.

It's kludgey. Maybe I'll come up with something better later.

add commentadd comment in the forum

Thursday, July 17th 2014 - 1:14 AM

Here is my second-generation back panel. I 3D printed it in ABS.

IMG_0851.JPG
back panel


The lower center connection is another 110V power plug like the one at center top. The upper right is a USB port with a Wi-Fi adapter.

I printed the panel in three sections. The sections interlock, and they are also held together by plastic pins.

Back Panel Exploded.png
back panel sections


I printed plastic pins in two lengths. The long ones (shown) hold the sections together. The short ones hold the panel tight against the laser cutter's skin.

Screen Shot 2014-07-16 at 5.43.47 PM.png
split pin


This actually worked really well. The panel is stiff enough to plug and unplug the power cords, and it holds together pretty tightly.

IMG_0846.JPG
inside view showing the pins


I had already used this technique to make the top panel. Right now it just has an ammeter. I may add some buttons later, or I may implement manual control through the web interface. For now, there is no manual control.

IMG_0841.JPG
top panel with ammeter


IMG_0842.JPG
top panel, inside view


The big insight I got from this subproject is, when designing complex assemblies for 3D printing, make the fasteners big. Really big, like a child's toy.

I used the neon blue color because it was at hand. But now I sort of like that color scheme. I guess I just have no taste.

add commentadd comment in the forum

Thursday, July 17th 2014 - 12:01 AM

This morning before work, I got the negative lead attached to the laser tube. As Bart suggested, I bound the two together with a thin tinned wire, then I buried it in enough silicone tape that it won't pull apart. (Well, not easily. I tested it with about 3 oz. of force. (-: )

The back panel came out well too. I have photos to post.

add commentadd comment in the forum

Monday, July 14th 2014 - 3:18 AM

My eighth grade math teacher had covered the clock at the front of the classroom with a cardboard sign that read, "Time passes. Will you?" My dad taught in the same school and was good friends with him. But I digress.

It has been OVER A YEAR since I updated this build log. And I've been working on this laser cutter all that time, and I still don't have it working.

Okay, I bought a 3D printer last May, and that distracted me for about three months. But the real distraction is that I've been writing my own firmware stack from scratch. It's been a blast, but it hasn't actually resulted in a working laser cutter yet.

Recap: I am using an Azteeg X3 as the back end, and I'm using a Raspberry Pi as the front end. The Raspberry Pi is headless, and the laser cutter is accessed over the network.

I have working software to start with a line drawing in a PDF file, convert that to G-Code, convert the G-Code to my own command language, called S-Code, send the S-Code through the USB port to the Azteeg, and the Azteeg can trace the outlines and pulse the laser to cut the lines. That much works.

Things that work. Most of these are new in the last year.

Things that are not done yet:


Today's subproject has been to design and fabricate Mk. 2 of the rear panel. The first one was 3D printed in 7 pieces, and was flimsy and wouldn't stay in place. The second one is on the printer now. I'm making it in 3 main pieces with 8 printed fasteners. When it's finished, I'll post details.

Here is a teaser for the software. This is the monitoring app I mentioned earlier. It runs in a terminal window. The idea is to make it easy to pinpoint why things are disabled.

It would be useful to add an LCD display that just displays the Status, Laser, and Motors lines.

kbmon sample.png

add commentadd comment in the forum

reader comment Comment from: TLHarrell on Thursday, May 16th 2013 - 10:53 PM
I really like that little green "breathing" light there at the end. Pretty cool way to be able to show machine status.

Thursday, May 16th 2013 - 10:13 PM

bdring wrote:I need to see that lite up in the system.


No problem. Here's some You-Tubing.

add commentadd comment in the forum

reader comment Comment from: bdring on Thursday, May 16th 2013 - 1:15 PM
Gantry LEDs...that is awesome.

...added to my TO DO list.

I need to see that lite up in the system.

Thursday, May 16th 2013 - 6:44 AM

Wow, it's been a long time since I updated this build log. I've been working on the laser cutter nearly every day. But I never feel like I'm at a good milestone to report progress.

After working through some wiring issues, I've gotten some serious work done on the firmware. This project looks like it's going to be 90% software. That's certainly the way it's been lately. You can check out my firmware at https://github.com/kbob/kerfburn . It still does not actually move any motors or pulse any lasers, but it's getting closer.

But here's a hardware thing that came out pretty well. I put a strip of LEDs on the bottom of the gantry. This is the LED strip I used. http://www.adafruit.com/products/306 They're addressable RGB.


IMG_9560.JPG


I printed little clips to keep them in place. The holder engages both slots of the Makerslide and holds the LEDs between the slots.

LED Clip.png


There is a hollow slot on the tab that goes in the slot so a wire can pass under it. The wire to the X limit switch runs through that slot. (Not visible in this picture.)

LED Clip - wire slot.png


I used a strip of double sided Scotch tape to hold the strip against the Makerslide, then put the clips on to hold the weight of the strips.

add commentadd comment in the forum

Saturday, March 2nd 2013 - 2:54 PM

Just a quick note. I just created a repository on GitHub to write my laser cutter firmware. There is nothing there yet except a three line README.

https://github.com/kbob/kerfburn

I'm on vacation all next week, so I'll try to flesh it out a little.

Oh, and I thought of a name for the firmware. Kerfburn.

add commentadd comment in the forum

Monday, January 14th 2013 - 7:50 PM

BenJackson wrote:
kbob wrote:I do not understand how Marlin et al do flow control on the serial (USB) line. I need to understand how to do flow control in my own serial driver. I don't see anything that looks like software flow control or hardware flow control in the Marlin sources. I don't have an Azteeg schematic to see whether there are hardware flow control lines.


They don't do HW or SW flow control. The AVR hardware has 1 byte of buffering and the firmware implements a deeper buffer in software with the UART interrupt. If this interrupt is held off (and unfortunately it's very low priority) you will lose bytes and the half-baked reprap "checksum" algorithm might detect the line is wrong and demand a retransmit. There were older firmwares (the original "5d") which did so much math in timer interrupts that the fw would lose bytes if you went much over 38400 baud. Newer firmwares are much smarter about this and basically never lose bytes.


That explains it. Thanks. It looks like the firmware (I'm looking at Marlin) prints "enqueueing \"(command)\"" after it has successfully received each line. I'm guessing the host side looks for that and doesn't allow itself to get too far ahead.

The FTDI chip on the Azteeg has a 512 character buffer, but AFAICT, that buys me nothing -- there's no way for the ATmega to slow the FTDI down.

add commentadd comment in the forum

reader comment Comment from: BenJackson on Monday, January 14th 2013 - 7:20 PM
kbob wrote:I do not understand how Marlin et al do flow control on the serial (USB) line. I need to understand how to do flow control in my own serial driver. I don't see anything that looks like software flow control or hardware flow control in the Marlin sources. I don't have an Azteeg schematic to see whether there are hardware flow control lines.


They don't do HW or SW flow control. The AVR hardware has 1 byte of buffering and the firmware implements a deeper buffer in software with the UART interrupt. If this interrupt is held off (and unfortunately it's very low priority) you will lose bytes and the half-baked reprap "checksum" algorithm might detect the line is wrong and demand a retransmit. There were older firmwares (the original "5d") which did so much math in timer interrupts that the fw would lose bytes if you went much over 38400 baud. Newer firmwares are much smarter about this and basically never lose bytes.

Monday, January 14th 2013 - 9:18 AM

My last substantive update was two weeks ago. Since then, I've made progress in a lot of small ways.

The two computer boards are mounted and screwed down. I made a wiring harness so they're both getting power, but it is messy. I started with the harness that came with the power supply, and cut off all the wires that I didn't need. But the wires I kept are generally a little too short. I might relocate the power supply rearward to correct that. I need to find some way to keep the wires out of the way -- maybe I can find some of those little P-shaped cable clamps.

I received the red laser diode from LightObject. I attached it to two AA cells to and played with the focus a little, but haven't started to install it yet.

I don't think I've talked about Raspbian here yet. Raspbian is a version of Debian Linux optimized for the Raspberry Pi. It is pretty slick. Initial installation was entirely painless, which is not at all what I expected of Debian. The AVR-GCC toolchain installed perfectly and works fine, too. I am running the Pi headless; I log in to it using ssh and do everything through virtual terminals. (Sorry, but the old habits are well-ingrained.)

This weekend, I copied some Arduino sketches over to the Pi and got them to compile outside the Arduino IDE. First I got the Arduino runtime library to compile with AVR-GCC, then I started replacing the Arduino runtimes with my own. This weekend I wrote drivers for a millisecond timer, the on-board LED, the first serial port, and the ATX power pin. I've expunged the Arduino code.

I do not understand how Marlin et al do flow control on the serial (USB) line. I need to understand how to do flow control in my own serial driver. I don't see anything that looks like software flow control or hardware flow control in the Marlin sources. I don't have an Azteeg schematic to see whether there are hardware flow control lines.

I described this earlier, but here's a recap. I'm using a PC power supply. It is a TFX form factor supply, smaller than ATX but electrically similar. The 5V standby circuit supplies 2 amps, which is more than enough to drive both the Raspberry Pi and the Azteeg's 5V circuits. I'm using the Azteeg's ATX power pin to drive the PC power supply's Power On lead to ground and power on the supply. When the supply is on, the Azteeg's 12V input is powered, and that powers the stepper motor drivers and the heater outputs. I should be able to leave the computers running and automatically switch on the 12V supply when the laser is in use.

The bad part about the power distribution is that the Pi gets power through a micro-USB connector, and the Azteeg gets its 5V power through a mini-USB connector plugged in to the Pi. So I'm drawing both devices' power through the micro-USB connector. It is working, but I'd rather there were a more substantial conductor carrying the power.

I put an LED and a resistor across the 12V terminals on the Azteeg so I can tell when 12V power is on. Then I wrote the few lines of code to drive the line low and switch the supply on. I inserted that code into the test program I'd written back in November called One Axis Random. After a little futzing and a lot of compiler warnings, I had the carriage running back and forth along the gantry. (I posted a video of One Axis Random back here. It is the last video in that post.)

So that's a milestone of sorts. Pi and Azteeg are powered, Pi and Azteeg are talking, software toolchain is working, Azteeg controls ATX power, Azteeg controls one stepper motor.

I need to start wiring the chassis now. After all the limit switches and the other two motors are hooked up, a lot more software will be possible.

add commentadd comment in the forum

Tuesday, January 1st 2013 - 8:14 AM

BenJackson wrote:I think the other thing you want to do there is flip the M5 bolt on the back wheel around so the excess bolt isn't sticking down (for maximum Y clearance).

The other suggestion I'd made to Bart back when I built mine is to drill a hole in the right front of the carriage to pass the air assist down to a right-angle fitting.

BTW in case you don't know, the top of the lens assembly unthreads from the bottom part so the whole thing can rotate in the diamond-shaped plate. You may need this adjustment to make sure the final mirror is square to the gantry.

My X idler is a little left of yours and I definitely had to chamfer it to keep it out of the beam path. But my beam geometry might not be the same as yours.


Invert M5 bolt: check.

Right angle barb: check. (I had already read that discussion in your build log; I was saving that mod for a future update.)

I did not know I could rotate the mirror, thank you.

If the idler bracket is in the beam, I suppose I could trim it a little with a laser. :twisted:

If I'm going to take the X carriage out to drill a hole for the air assist, I could also cut a notch in it where it contacts the idler bracket so it could slide further to the left. That would give back the lost X travel. (That's also a good future mod candidate. I'm getting antsy to get this thing finished.)

add commentadd comment in the forum

reader comment Comment from: BenJackson on Tuesday, January 1st 2013 - 7:40 AM
kbob wrote:I forgot to include this photo. It shows the X idler bracket's new location. I think it needs to move further to the right to be well clear of the laser.

Also, this photo shows a mirror-right-of-center (mroc) mirror mount. That should disambiguate that.

IMG_9438.JPG

I think the other thing you want to do there is flip the M5 bolt on the back wheel around so the excess bolt isn't sticking down (for maximum Y clearance).

The other suggestion I'd made to Bart back when I built mine is to drill a hole in the right front of the carriage to pass the air assist down to a right-angle fitting.

BTW in case you don't know, the top of the lens assembly unthreads from the bottom part so the whole thing can rotate in the diamond-shaped plate. You may need this adjustment to make sure the final mirror is square to the gantry.

My X idler is a little left of yours and I definitely had to chamfer it to keep it out of the beam path. But my beam geometry might not be the same as yours.

Monday, December 31st 2012 - 11:45 PM

I forgot to include this photo. It shows the X idler bracket's new location. I think it needs to move further to the right to be well clear of the laser.

Also, this photo shows a mirror-right-of-center (mroc) mirror mount. That should disambiguate that.

IMG_9438.JPG
Gantry Left

add commentadd comment in the forum

Monday, December 31st 2012 - 1:03 PM

In the last four work sessions, I've done several things.

I printed Ben Jackson's laser pointer holder, got the right screws, and affixed it to the chassis.. I thought I'd ordered this laser pointer from Lightobject, but failed to do so. I've placed a second order, but I think they've shut down for New Year's.

I did order and did receive a big red E-stop switch, a two-axis joystick, and some silicon tubing from Lightobject. I don't need any of them immediately; I just wanted to fill out the order with the laser pointer. You know, the laser pointer that I forgot to put into the order. (Grrr...)

I cut the aluminum eggcrate to size on a borrowed bandsaw. Cutting aluminum eggcrate on a bandsaw is just like cutting butter with a chainsaw, only not as messy. The bandsaw is completely oblivious to the piece it's cutting.

IMG_9419.JPG
Eggcrate in Place


The eggcrate was 600×600 mm (23⅝ inches). That's a little short for the 2.x bed. I cut it as wide as possible, and cut out notches around each of the Z lift screws. After cutting everything, I cleaned up the rough edges with a Dremel and then folded and burnished them with a piece of pine 2×4.

IMG_9416.JPG
Cutout Around Z Screw


Question: How are you guys securing your eggcrate to the platform? Mine is just resting on the aluminum rectangle, but I want to secure it somehow.

I also printed a bracket to hold the Raspberry Pi. The Pi's designers neglected to put any holes into the board, so you have to find a way to clamp it. I printed this bracket. (I also printed this one, but it didn't fit as well.) The Azteeg X3 has the usual mounting holes at the corners, so I'm using conventional standoffs for it.

I mounted the two mirror holders. I had not noticed that they are different — one has the mirror left of center (mloc), and the other has the mirror right of center (mroc). You might say that they are mirror images of each other. (-: The mroc one lined up with the carriage mirror better, so I put that one on the gantry. Bart's drawing, D30025 rev 8, shows two mroc mirrors.

I originally put the X idler bracket where the X carriage would hit it just before it would hit the gantry end, and adjusted the X limit switch to match. But that puts the idler bracket in the path of the laser. It looks like there's room to put the idler bracket to the left of the laser's path, but that puts the belt into the laser. So I've put the idler bracket to the right of the laser's path, and I've lost about an inch of X travel. My assembly matches the drawings, but it seems like I must be doing something wrong.

Question: Where did you put your X idler bracket?

On 12/22 and 12/23, I overanalyzed the orientation of the Y cable carrier and the layout of the electronics bay. (Link 1, link 2) Now I have made the big decisions. The Y cable carrier will go loop-at-the-front, exit toward the back. The electronic components will go as shown here. Not shown: the Raspberry Pi snaps into the black bracket; the DIN rail will go just in front of the back panel, oriented laterally; and the air pump will go on the table beside or behind the laser cutter. (Thanks, BenJackson, for talking sense to me there.)

IMG_9426.JPG
Electronic Modules Placed


In this photo, the power supply is screwed down. The Azteeg and Pi have holes drilled and screws sitting in the holes, but I don't have any nuts. Hopefully the local fastener emporium will be open tomorrow.

I printed some brackets to attach the power supply to the Misumi rail. The one in front is straightforward .

IMG_9427.JPG
Power Supply Front Bracket


The rear bracket was trickier because the hole in the power supply is just 9 mm above the floor. I copied Bart's trick of intersecting screw holes. I doubt I would have thought of that if I hadn't just seen Bart do it.

I attached the Y cable carrier to the gantry end and marked holes in the bottom skin. But I did not get around to drilling them yet. (Also, no nuts.)

That is where I am now. What's next?

Attachements...
IMG_9429.JPG
Power Supply Rear Bracket

add commentadd comment in the forum

comment Buildlog Author Comment: kbob on Thursday, December 27th 2012 - 12:02 AM
Comment From Buildlog Author
Oops, you are correct. Pins D4, D5, D6, and D11 are used as outputs.

The ATmega datasheet says the internal pull-ups are 20 kΩ minimum, 50 kΩ maximum. That is very high, but not surprising.

Cre8ivdsgn, thanks for the book reference. It is available in the local university engineering library. (It's $81 on Amazon!)
reader comment Comment from: cvoinescu on Wednesday, December 26th 2012 - 9:25 PM
kbob wrote:I wonder whether the Azteeg has conditioning on its limit switch inputs like cvoinescu suggested. Roy hasn't posted the Azteeg schematic, has he? He did mention that some of the inputs have MOSFETS. (link)


Those seem to be outputs, not inputs (or, at least, the MOSFETs are used as outputs). Many controllers simply enable the internal pull-ups of the microcontroller, but that's not enough. Stiffer pull-ups are needed to reduce susceptibility to noise. I don't know what any of the Azteegs do, but even if they have external pull-ups I doubt they go lower than 4.7 Kohm or so (which, by the way, may well be plenty).
reader comment Comment from: Cre8ivdsgn on Wednesday, December 26th 2012 - 6:08 PM
Kbob, I thought there was a post in this branch where someone was looking at how to go about rolling their own software/firmware controls. Perhaps I am mistaken, but just to have this information somewhere, there is the book "Stepper motors and their Microprocessor Controls"

Here it is on Amazon: http://www.amazon.com/Stepping-Motors-T ... r+controls

I apologize for injecting this into your buildlog but perhaps I am going crazy and this isn't where I saw it. Rolling your own is not for the faint of heart and your build is looking great!
comment Buildlog Author Comment: kbob on Tuesday, December 25th 2012 - 11:50 PM
Comment From Buildlog Author
I wonder whether the Azteeg has conditioning on its limit switch inputs like cvoinescu suggested. Roy hasn't posted the Azteeg schematic, has he? He did mention that some of the inputs have MOSFETS. (link)
reader comment Comment from: jv4779 on Tuesday, December 25th 2012 - 4:00 PM
I have all the same stuff running in my Y axis cable carrier (minus the LED strip control line, mine is just a dumb 12v white strip). The limit switches run in a 4 conductor shielded cable and have not had any spurious limit errors on X or Y. Motor power and LED power are just unshielded wire.
reader comment Comment from: BenJackson on Monday, December 24th 2012 - 9:01 AM
This is the post from my buildlog where I show my electronics tray: viewtopic.php?f=16&t=557&start=40#p5741

The image is big enough you can read off the part number of the blower relay (you can't miss it!). It's a DIN mount relay that Bart sold me when I told him what I wanted to do. It's 3-phase (I only use one) and rated for inductive loads. I use it to switch the dust collector I use to exhaust air. It's way more powerful than necessary.

I may end up buying another small DIN relay to split up control of the air/chiller (currently I have those together on one relay, automatically activating when the laser is enabled and for 20s after). Some jobs don't really want assist air (cutting paper, engraving LaserMAX) so it would be nice to be able to enbed that in the job instead of doing it manually.

Monday, December 24th 2012 - 7:41 AM

BenJackson wrote:I wouldn't put the air compressor inside... It vibrates a lot. Even on its little feet. If you really had to I'd go for some extreme isolation, like hanging it from bungies. You can also cut the vibration and noise with an output reservoir and some backpressure.

For power switching I got a 15A lighted rocker from a HW store and put it in the front panel. That switches the main PSU and the laser PSU. The main PSU is the power for the relays, so the blower/air/chiller current don't flow through it but the front switch still turns them off (the blower switching might kill it if the switch actually controlled it).


I agree, the air pump would be better outside. I'll have to figure out where to put it.

What relays did you use for the blower?

Thanks.

add commentadd comment in the forum

reader comment Comment from: BenJackson on Monday, December 24th 2012 - 7:28 AM
I wouldn't put the air compressor inside... It vibrates a lot. Even on its little feet. If you really had to I'd go for some extreme isolation, like hanging it from bungies. You can also cut the vibration and noise with an output reservoir and some backpressure.

For power switching I got a 15A lighted rocker from a HW store and put it in the front panel. That switches the main PSU and the laser PSU. The main PSU is the power for the relays, so the blower/air/chiller current don't flow through it but the front switch still turns them off (the blower switching might kill it if the switch actually controlled it).

Monday, December 24th 2012 - 6:38 AM

I am deciding where to put all the things in the electronics bay. Here are two possibilities. I'll call them Configuration A and Configuration B. First, here's A.

IMG_9404.JPG
Configuration A, Top View


IMG_9405.JPG
Configuration A, Side View


And here's Configuration B.

IMG_9402.JPG
Configuration B, Top View


IMG_9403.JPG
Configuration B, Side View


The two configurations have some things in common. The main power plug is always at the back right corner (not shown). The mains power distribution block, represented by a silver bow, is right in front of it. The PC power supply is along the side of the box. I will cut a hole in the skin to let its fan breathe. The water pump is not shown. It will be outside the chassis. The laser power supply is not shown. It will be on a shelf above all these bits, at the same height as the laser tube. So there are really three components to place.

The air pump has power and air in and out. The air outlet is the brass barb on the end. The air inlet is a black screw fitting sticking out the side of the opposite end. I powered on this air pump for the first time today. It sounds like a freakin' jackhammer. I want a quieter pump. But its connections are very simple.

The Raspberry Pi is the front end processor. It will have these connections.

The Azteeg X3 is the real time processor. It will also handle manual mode operations. It will have lots of connections.
The Azteeg has three high current outputs (for bed heater and two hot ends) that I can use for a power relay. It already has inputs designated for thermistors. Just about everything labeled (optional) will be done later, after I get the basic laser running. Because it has wires going everywhere, it's really impossible to optimize its placement.

So. Back to configurations A and B.

Configuration A puts the CPUs up front where they're near the control panels and the PC power supply's output, but they're far from the back panel and the sensors and motors in the back. In configuration A, the Y cable carrier would exit toward the front of the chassis.

Configuration B puts the CPUs closer to the rear. It is possible to reach in and change the SD card in the Pi there. The Azteeg is closer to the motors and sensors in the rear. In configuration B, the Y cable carrier would exit toward the rear.

Now that I've taken time to describe all this, I'm envisioning Configuration C (no photo, sorry). Start with B, switch the Azteeg with the Pi so the Pi is closer to the front of the case, and rotate the Pi so its SD card slot is facing toward the laser bay for easy access. The Pi has many fewer connections, so it can be out of the way. The Azteeg's orientation is less obvious. It has power connections coming off both short ends of the board, gantry connections coming off both long ends, and connections to the front panel and rear chassis coming off everywhere. I might as well just orient it so its lettering is right side up. (-:

I've used the term "power distribution block" above a few places. I don't actually know what that should be. It will take in 110V power and redistribute it out to several other places. It's sort of a power strip. (-: I would also like it to have some outlets that are switched by a relay (or solid-state switch?) What do I need? Bart's BOM calls for a "DIN Rail" and several "DIN terminal blocks". Is that what I should use? Can I get a version of that that also has relays? (I hope that last question conveyed how very far I am from my areas of expertise here. (-: )

And while we're at it, what are some good ways to keep all these cables (and air hoses) tidy?

Thanks for all suggestions.

add commentadd comment in the forum

Monday, December 24th 2012 - 5:15 AM

cvoinescu wrote:Good cabling practice would be to keep the low-voltage digital stuff (limit switches, LED data, and even LED strip power) well away from the stepper wires...

That not being a choice, you could do some of the following:
  • Reduce the impedance of the limit switches. Either use ridiculously low pull-up resistors (e.g. 220 ohm), or, even better, have the microswitch changeover from VDD to GND and input into a low-impedance Schmitt trigger (for instance, a CD4050B or 74HC244 with 470 ohm resistors between the input and the output of each buffer). I'm about to do the latter for my milling machine/3D printer. In theory, it should also completely eliminate bouncing.
  • Reduce the impedance of the LED data lines. That is simply a matter of using a hefty buffer (e.g. the CD4050B with three buffers in parallel for each line).
  • Decouple the LED power supply at both ends with ceramic capacitors.
  • Use twisted pairs for the motor (one pair for each coil); you can twist it yourself, it doesn't have to be a pre-made cable.
  • Shield the motor cable and the low-voltage stuff, although that's a last-resort solution because it makes the cables bulkier and stiffer, and unlikely to be necessary.


Thank you. Now I have things to try. I will do the low-Z pull-up resistors and ceramic caps on the LED strip initially, then if I see issues that could be noise-attributed, I'll do more.

So are we supposed to ground the gantry?

add commentadd comment in the forum

reader comment Comment from: cvoinescu on Sunday, December 23rd 2012 - 1:47 AM
Good cabling practice would be to keep the low-voltage digital stuff (limit switches, LED data, and even LED strip power) well away from the stepper wires...

That not being a choice, you could do some of the following:
  • Reduce the impedance of the limit switches. Either use ridiculously low pull-up resistors (e.g. 220 ohm), or, even better, have the microswitch changeover from VDD to GND and input into a low-impedance Schmitt trigger (for instance, a CD4050B or 74HC244 with 470 ohm resistors between the input and the output of each buffer). I'm about to do the latter for my milling machine/3D printer. In theory, it should also completely eliminate bouncing.
  • Reduce the impedance of the LED data lines. That is simply a matter of using a hefty buffer (e.g. the CD4050B with three buffers in parallel for each line).
  • Decouple the LED power supply at both ends with ceramic capacitors.
  • Use twisted pairs for the motor (one pair for each coil); you can twist it yourself, it doesn't have to be a pre-made cable.
  • Shield the motor cable and the low-voltage stuff, although that's a last-resort solution because it makes the cables bulkier and stiffer, and unlikely to be necessary.

Saturday, December 22nd 2012 - 11:14 PM

Bart's original design had the Y axis cable carrier going to the front right corner of the work volume.

Image

At several early builders' suggestion (e.g., Ben Jackson, Bill Meade) he made the design reversible. The carrier can go either to the front right or the back right corner..

The fixed end of the carrier bolts onto the bottom skin. (That's what I thought I remembered.) There are supposed to be attachment holes both at the front and at the back of the skin. Last night I turned my chassis over and looked for holes in the bottom skin. I did not see any holes at all. I'll double-check next time I'm at the maker space, but I think I'll be drilling new holes. No big deal.

Both sets of holes are clearly present in the drawings. And I'm pretty sure I oriented the bottom skin correctly because the holes marked A and B line up.

bottom-skin.png
Detail from C51004 rev 7


Once the Y carrier is installed, I will run the following items through it.


That's a total of 6 conductors high current, 6 conductors low current, and a hose. The carrier will be kind of full.

LED strip? Yes. I'm getting old and blind, so I'd like to have a good light on the work piece. I bought a strip of RGB LEDs which I intend to glue onto the bottom surface of the gantry. I got RGB LEDs, individually addressible, so I'll have yet another software project to play with. At first, I'll just switch them on and leave them on, full brightness. But I have a few ideas for lighting games. The gantry is long enough for 22 LEDs at 60 mA each, so 1.3 A total. A total of four wires is needed, but the other two wires just have to carry a data signal to switch the LEDs.

Here is where I have to ask for advice. Do these wires need to be shielded? Do they need to be twisted pairs?

I thought that for the limit switches, I could just run a 4 conductor ribbon cable. It would bend very well and not take up much space in the carrier. But maybe ribbon cable will pick up too much noise?

The serial signal for the LEDs is more interesting. It's also a 5V low current signal, but it's fairly high speed. (Could be up to 2 MHz; could be lower.) So what do I need? Can I add them to the ribbon cable?

And the motors. Design current is 1.68A. Max voltage is 24V. Full step sine waves could be as high as 30 KHz, but that's probably beyond the motor's mechanical limits. The microstep frequency would be 16× higher, or 480 KHz. Does that need to be shielded? Twisted? Other?

I have some Molex Micro-Fit connectors for the high current leads. I'm thinking about mounting a tiny PC board or perf board on the end of the gantry so all the wires can unplug for disassembly. Any reason that's a bad idea?

I have to decide which way to mount the Y carrier, too.

I'm thinking the most important factor will be electrical noise from the laser and its power supply. If I make an upper shelf of ferrous metal for the power supply and ground it, that should help a lot. The positive lead could be very short, maybe a couple of inches. But the negative lead will run the length of the laser tube and wll be a big antenna in the back of the box. So I'm thinking the front of the box will be less noisy. (But I am not an EE. Is this a valid line of thought?)

If I use the original configuration, loop at the rear, exit toward the front, then I can put the electronics in the front of the box, but the signals to the gantry will be fairly close to the tube. I will also have to run cables for externally accessible Ethernet, USB, or SD card to the back panel. (Maybe USB and SD should be on the front panel?)

If I use the alternate configuration, loop at the front, exit toward the rear, then the controllers will be at the rear where it is noisier, and if I install USB or SD, I'll have to run long cables to the front.

The air hose just doesn't matter. I'm planning to put the air pump wherever it fits inside the chassis and run a second line to the grommet on the back. The line will just stop at the grommet.

I have a feeling I'm overanalyzing this. Is electrical noise a serious concern or will good cabling practice make it irrelevant?

add commentadd comment in the forum

reader comment Comment from: greenvandan on Saturday, December 22nd 2012 - 12:51 PM
Looking good, mine's been on the back burner as of late.

Anyway, I think the second cable carrier attaches to the bottom skin. I haven't put mine on yet but can see two holes with the same spacing as the other attachment points.

Saturday, December 22nd 2012 - 8:07 AM

Since the last update, I've installed the gantry. I set it in place on the four upper wheels, verified the alignment and rail spacing, then attached the bottom wheels with the gantry in place. There was very little slack between the wheels. I didn't tighten the eccentric nuts at all. That makes me wonder whether something is misaligned.

Tonight I attached the min Y limit switch, which I'd forgotten to do, and attached both Y belts. I tried for a while to ensure that the gantry is square, but really couldn't. When the laser is operational, I will cut some squares and measure them for squareness. The gantry moves with very little friction. Before I attached the belts, it would roll easily whenever I tilted the frame 20° or so. With the belts on, that doesn't happen, of course.

My X cable carrier is installed. I don't see where to install the Y carrier. I see screw holes on the right gantry end (motor end) at the bottom. But I don't see where the other end can go. I vaguely remember that Bart explained it a few months ago; I'll have to track down that post.

I got some air assist tubing at the local aquarium store. I don't know exactly what it is, but it is nice and flexible. I test fitted it into the Kabelschlepp tonight, and it bent just fine. Here is the reel it came from.

IMG_20121123_131255.jpg


There are a lot of pieces to align in this chassis. Most of them are pretty close, but none are perfect.

I received an aluminum eggcrate floor this week, and am making arrangements to use a bandsaw to cut it to size. (See post in other forum.) I think I will leave the plastic eggcrate in for a while -- the aluminum seems to be much more fragile.

Also this week, I planned out a water cooling system using PC overclockers' components: pump, radiator, fans, quick disconnects, flow and temperature sensors, etc. It came to about $250. Then I checked Bart's recommended submersible pump. It's $13. Tonight I stopped by Harbor Freight and bought the $13 pump. I already have a bucket. The radiator and quick disconnects can come later, I guess.

While there was a crowd of kibbitzers at the maker space tonight, I got out the electronic components and started placing them in the chassis. It looks like there is plenty of room. I will have:

It is not clear how I'll route the wiring. That's another part I've never had to do before. I will start on the wiring as soon as I've gotten the Y cable carrier installed.

Here's what it currently looks like. (Gratuitous Christmas lights/LED strip in the background)

IMG_9389.JPG

add commentadd comment in the forum

Sunday, December 9th 2012 - 6:23 AM

I'm back from a business trip, and I got to touch the hardware for the first time in over two weeks today.

I cut my Makerslide plank to length and started building the gantry. Cutting and tapping the slide took longer than I expected. (We have a crappy metal chop saw at the maker space. I do not recommend this product.) Then I built the carriage and screwed on the end plates. I'm trying to track Bart's 2.x plans pretty closely for the mechanicals.

Here's how far I got.

IMG_9339.JPG


Kabelschlepp. I love it. It's fun to watch it bend, and it's fun to say the name. A sales rep from Kabelschlepp called me when I placed my order. He pronounced it Cobble-Schlepp. Now I do too.

add commentadd comment in the forum

Saturday, November 24th 2012 - 1:34 AM

Here are three videos I threw onto the Yoot Yoob.

The first one just demonstrates a repeating pattern of three movements. It demonstrates acceleration and deceleration. It's not much to look at.



Inside, the program has two components. The mainline (the loop() routine in Arduino runtime) iterates through an array of stroke descriptions. Each stroke has a direction, plus or minus, a length in mm, a maximum V in mm/sec, and an acceleration constant in mm/sec/sec. The mainline uses that info to calculate the info needed by the real time portion to control the motor.

That info is:

The mainline puts that info into a ring buffer. The real time component reads entries from the ring buffer and uses them to control the motor.

The real time component runs from the counter overflow interrupt. When the counter overflows, the hardware s[youtube][/youtube]ets the step pulse HIGH and triggers the overflow interrupt. 1 microsecond later, the hardware sets the step pulse LOW. Whenever the interrupt service routine gets to run, it uses the info above to calculate when the next timer overflow should happen. It loads that value into the appropriate register.

There's a whole lot of bookkeeping to handle too, of course. Are we done accelerating? Is it time to start decelerating? If we've finished decelerating, is there another stroke to start on? Etc. But there's plenty of time — at worst, the interrupt service routine has about 12 microseconds, since it has until the next counter overflow to load the register, and most of the bookkeeping happens after the register is loaded.

So far, I've been limited by the mechanical speed of the stepper motors, not the Arduino. But I'm only calculating one axis. When I add the Y axis and the laser pulses, the CPU will be busier.

Here's the second video. In this one, I ran a test pattern where the carriage makes successively longer movements until it's moving about 30 cm (1 foot) at a time. The longer motions are pretty smooth and fast. The acceleration looks kind of sluggish to me, though. Vmax is 500 mm/sec. Amax is 1700 mm/sec².



I ran this for a couple of hours last night. Whenever the stepper stalled, I lowered Vmax or Amax and restarted it. The above values appear to be reliable. Obviously, if I change the mass of the carriage or the voltage or amperage of the stepper driver, I will want to re-tune those.

The third video is my favorite. In this one, the direction, distance, maximum velocity, and acceleration rates all vary randomly.



I can sit and look at this one for hours. (-:

add commentadd comment in the forum

comment Buildlog Author Comment: kbob on Friday, November 23rd 2012 - 10:06 AM
Comment From Buildlog Author
And limit switches. I can wire in the limit switches and write them into my software, too.

Friday, November 23rd 2012 - 9:37 AM

I've made some progress on motor control software. I can change the acceleration and velocity profiles on the fly, and have been writing exercise programs that cycle through various speeds and distances. I will shoot some video in the daylight. (Yes, we still get scattered daylight in the US Pacific Northwest at this time of year. Occasionally.) I'm still driving a single stepper motor which is on a bare piece of Makerslide.

Thanks to Roy's explanation, I was able to find alternate output pins to drive all four channels — X, Y, Z, and what I'm calling P for laser Pulse — from the ATmega's four 16-bit timer/counters. I've tested all of them except P.

I've done about all I want to do with a single stepper motor. In December, I will finish the mechanical assembly and start writing software to control the motors on both X and Y axes simultaneously.

The mechanicals are coming along nicely. I redid the Z table using Bart's aluminum table brackets with PEM nuts. They work better than the printed plastic pieces, because the PEM nuts float with some slack and don't bind up. I installed a plastic egg crate insert for the floor. I know plastic will burn, but I haven't been able to source any metal egg crate. During my day off tomorrow (It is Thanksgiving weekend in the US), I am going to try the local electrical and plumbing supply houses. I've already tried the home centers like Home Depot, and I've even hunted through the junk piles at the local building supply recycler.

I got the gantry ends from Bart's Batch #7, but haven't done anything more than admire them. Now that I'm done with my single motor software development test bed, I can build the gantry. I'm going to try to cut my gantry a little long -- as long as I can without keeping the Y motor shafts from reaching their bearings. I think I can probably get an extra 5 mm in the X dimension. Not a significant difference, I know. But I'm starting to wish the laser cutter were bigger.

The downside of putting the electronics into the laser cutter is that I will only be able to work on it when I'm at the maker space. These late night debugging sessions will have to stop. :-(

add commentadd comment in the forum

reader comment Comment from: StigOE on Thursday, November 22nd 2012 - 1:04 PM
kbob wrote:My motors are Keling KL17H247-168-4B. The datasheet is here. http://www.automationtechnologiesinc.co ... 168-4B.pdf

The datasheet lists these.
  • Phase 2
  • Rated Voltage 2.8 V
  • Current/Phase 1.68 A
  • Resistance/Phase 1.65 Ω
  • Inductance/Phase 2.8 mH
  • (and some other stuff)
I guess that calculates out to 1 phase (at a time) × 1.68 A/phase × 2.8 V ≅ 4.7 watts when the motor is at rest. Right? That number, as you said, isn't very useful because of back EMF when the motor is turning and losses in the driver chip and who knows what else.

FWIW, if my calculations are correct, the fastest I've seen the motor turn under Arduino control is about 2100 RPM. Above that, it would stall. But my stepper drivers don't have heat sinks yet, so I'm using ~1 A, not 1.68A. But I digress... (-:

The standard for calculating PSU for steppers to get the best efficiency, is 2/3 of the rated current times number of motors running simultaneously and sqrt(inductance) times 32 for voltage. For steppers, current equals torque and voltage equals top speed. So for your motors, if you use 2, it would be 2/3 * 1.68A * 2 = 2.24A and sqrt(2.8) * 32 = 53.5 would give you the best torque and best speed without overloading the motor. Depending on your drivers, this voltage may overload your drivers, though.

Wednesday, November 21st 2012 - 5:34 PM

cvoinescu wrote:Your calculation for the motors is a bit misleading. First, it's 1.68 A per winding, and exactly how much your motor can take when two windings are energized should be in its datasheet. Second, the driver works as a chopper; together with the inductance of the winding of the motor, it forms a buck supply, so it can deliver a higher current (1.68 A) at a low voltage (likely 2 to 5 V, check your motor specs) drawing a lower average current from a higher voltage supply (24 V).


Interesting. "Buck Supply" was a new term to me. Wikipedia defines it, though.

My motors are Keling KL17H247-168-4B. The datasheet is here. http://www.automationtechnologiesinc.co ... 168-4B.pdf

The datasheet lists these.
I guess that calculates out to 1 phase (at a time) × 1.68 A/phase × 2.8 V ≅ 4.7 watts when the motor is at rest. Right? That number, as you said, isn't very useful because of back EMF when the motor is turning and losses in the driver chip and who knows what else.

FWIW, if my calculations are correct, the fastest I've seen the motor turn under Arduino control is about 2100 RPM. Above that, it would stall. But my stepper drivers don't have heat sinks yet, so I'm using ~1 A, not 1.68A. But I digress... (-:

The standard answer here would be to grab an old PC power supply off the discard heap. But I'm unique, I think, among PC hobbyists because I never have any old ATX power supplies sitting around. My servers eat them and I have to replace them every couple of years. I think it's because the servers are in a room that gets very warm in the summer. There is nothing to be done — the house was built with an undersized air conditioning unit.

So is the TFX supply I listed complete overkill? It's hard to find quiet, reliable supplies in low wattages.

add commentadd comment in the forum

reader comment Comment from: cvoinescu on Wednesday, November 21st 2012 - 3:19 PM
Your calculation for the motors is a bit misleading. First, it's 1.68 A per winding, and exactly how much your motor can take when two windings are energized should be in its datasheet. Second, the driver works as a chopper; together with the inductance of the winding of the motor, it forms a buck supply, so it can deliver a higher current (1.68 A) at a low voltage (likely 2 to 5 V, check your motor specs) drawing a lower average current from a higher voltage supply (24 V). So you don't need 1.68 A times 3 motors from the power supply; you need only what the drivers draw to supply that current to the motors, which you can't calculate exactly because you don't know the efficiency of the chopper/winding combination. The efficiency is not very good at high speed because of back EMF and what not, but still you don't need the full 1.68 A at 24 V. It doesn't hurt to have a beefier power supply than needed, but my best guess is that 3 A for the motors is plenty.

Standard disclaimer applies. I may or may not know what I'm talking about. Warranty void if opened or seals broken. Past performance does not guarantee future results. May cause nausea, vomiting, headache and warts. Consult your doctor or pharmacist. Laser radiation when open and interlocks defeated.

Tuesday, November 20th 2012 - 9:04 PM

I'm thinking about a power supply for the controller and motors. (Not the laser. I will probably get the laser tube and power supply together.) The 2.x BOM calls for a 24V power supply from Bart; Bart doesn't appear to be selling power supplies any more.

My Azteeg has a 12-24V boost converter, so I actually need 12V for the motors. The motors are rated for 1.68 amps. 1.68 amps × 3 motors × 24V = 121 watts. The computers, the Azteeg and a Raspberry Pi, run on +5V, probably well under an amp for both. I also am planning to put some LEDs somewhere in the case for illumination, but they will be another fraction of an amp. Call it 150 watts total.

I'm thinking a PC power supply is the way to go. The computers can run on the +5V standby line, and I can switch the main power on and off under software control.

PC power supplies normally exhaust hot air at the end with the power plug. The power plug won't be exposed on the laser cutter; instead it will be wired to some kind of internal power bus. I'm thinking I should position the power supply against the side of the case and cut a hole in the skin so it can draw in fresh air and exhaust the hot air into the enclosure. There won't be a lot of heat -- if it outputs 150W at 80% efficiency, that's 37 watts of waste heat. And when the laser is running, the exhaust fan will be moving a lot of air through the enclosure and the heat shouldn't build up.

If I go that way, I'll have to ensure that the exhaust fan flows much more air than the PC power supply. If the PC PSU is the lowest resistance path for fresh air to enter the enclosure, the PC PSU may not even need to run its own fan. I should get a PSU with a fan thermostat.

An alternative is to let the PSU suck inside air and exhaust it back into the box. The bad thing about that is that the PSU will inhale smoke and particulates and get grody inside. Another alternative is to put the PSU outside the box and run the cables in.

This power supply has caught my eye. SeaSonic SS-350TGM Bulk 350W TFX12V It is high efficiency, thermostatted, and small. 350W is comfortably above my requirement. And this review says the fan doesn't come on below 200W. Because the cables unplug from the PSU, it'd make the wiring a little easier. The downside is that it's not the cheapest at $75 US shipped from NewEgg.

Is the electronics side of the box crowded? There will be a motor/electronics power supply, a laser power supply, a Raspberry Pi, an Azteeg, a power distribution panel, and some wiring. It seems like there's plenty of room -- is there?

Also, did I see something about keeping the laser power supply isolated or shielded from the other electonics?

add commentadd comment in the forum

reader comment Comment from: royco on Saturday, November 17th 2012 - 7:18 PM
"I'm writing my own software from scratch" I want to know more :-)

The D4, D5 D6 and D11 are mosfet driven switches and not directly connected to the corresponding pins. If you need access to those pins you may have to tap from the resistor pad connected to the gate of the Mosfet. I would suggest maybe using the J11 expansion header instead if possible for your application. It was placed there for an additional stepper driver control. Which reminds me to finish cleaning up the schematic so I can place it on the wiki.

Roy

Saturday, November 17th 2012 - 8:24 AM

I ran into a setback tonight. I think I have a workaround for it.

If you've been following my story, you know that I'm using an Azteeg X3 (Arduino Mega 2560 + RAMPS compatible) for motor and laser control, and that I'm writing my own software from scratch. Furthermore, I've designed the control program so that the stepper pulses (and later, the laser pulses) are all driven off the timer/counter circuits in the ATmega.

I've been doing development so far using a single stepper motor driven by the Z stepper driver. I chose the Z because the Z STEP pin happens to be one of the timer-controlled pins. That is not true for any of the other four stepper drivers on the Azteeg. A week or so ago, I soldered a 2 inch lead onto a SureSteppr's STEP pin, and also put some female headers on pins D4, D5, D6, and D11. The plan is (well, was) to use D5, D6 and D11 for X STEP, Y STEP, and laser pulse, respectively. Those pins are all able to be driven by a 16 bit timer/counter.

So tonight I hooked it up, just to verify that it works and that my code to parameterize pin assignments works. It did not work. It appears that pins D5 and D6 are not connected to anything. It's possible that I burned through a trace while soldering on the header. But I identified the through hole where the trace goes through the board, and I can't see any voltage there either. I don't think I've shorted the pins to ground, but I'm not certain -- the battery in the multimeter died while I was working tonight.

If I can figure out how to resuscitate D5 and D6, I will. I would like to use those pins, as they're in a tidy group. If I can't, though, I can fall back to pins D2 and D7. D7 is on the EXP3 header and D2 is the X MAX limit switch, which I don't need.

And that's how I spent my Friday night.

add commentadd comment in the forum

Monday, November 12th 2012 - 12:11 AM

Here's a short video on the Ewww-Toob.



Here are some more photos of the test bed I made. It was a completely unnecessary diversion but a good chance to learn a little about OpenSCAD and 3D printing.

The blue plastic carriage was an attempt to create the gantry end in plastic. I think it would have worked after a couple of iterations, but the other end with the motor was going to be tricky since it has overhangs in every orientation. Also, the printer I have access to is too small, so I was going to have to impose on a friend who has a bigger printer for every iteration.

IMG_9288.JPG


IMG_9264.JPG


IMG_9269.JPG


IMG_9272.JPG


IMG_9274.JPG

add commentadd comment in the forum

Sunday, November 11th 2012 - 10:23 AM

Tonight I reached a milestone on the software side of this project. I'm able to drive a stepper motor, accelerating, decelerating, and reversing. This is my own software stack running on an Azteeg X3 with Allegro stepper driver chips.

I'd done this earlier using the Arduino library. The part that is new is that I'm generating the stepper motor pulses directly from one of the timer/counter circuits on the AVR. That means that the step pulses are controlled very precisely by the counter/timer. The counter/timer is clocked at 16 MHz, the AVR's CPU frequency. When I have three axes going (X, Y, and laser pulses), the precise timing means that the X and Y will track each other closely and the laser pulses will be evenly spaced. Right now, it's just a single axis.

I mentioned acceleration. Each time the counter overflows, it pulses the Allegro chip, and it also triggers an interrupt. The interrupt service routine loads the counter with its next overflow limit. By varying the overflow limit, I increase or decrease the motor's speed. At present, I am using a canned acceleration ramp.

I will shoot some video when it's daylight.

add commentadd comment in the forum

Thursday, November 1st 2012 - 8:12 PM

garyacrowellsr wrote:Yes, I'd appreciate it if you would post your .scad files somewhere; Thingiverse, whatever.

Gary


It took me a couple of days, but I put it up on Thingiverse.

http://www.thingiverse.com/thing:33579


Have fun!

add commentadd comment in the forum

reader comment Comment from: garyacrowellsr on Tuesday, October 30th 2012 - 6:35 PM
Yes, I'd appreciate it if you would post your .scad files somewhere; Thingiverse, whatever.

Gary
reader comment Comment from: bdring on Tuesday, October 30th 2012 - 12:50 PM
Those look pretty good. I like the way you cheated the max size. I have printed sideways holes before with pretty good results. I usually run a drill through to clean them up, but in this case the size of the hole is not critical. You should post them on Thingiverse with a title like "2.x Laser Tube Brackers for Small Printers".

Tuesday, October 30th 2012 - 5:38 AM

Last night, after a little encouragement from Bart, I looked again at the laser tube support brackets. My recollection was that they were way too big for the four inch printer at my makerspace. I had tried laying them out diagonally, because some other long parts fit in that orientation, but the tube support brackets do not. They almost fit, though, in the regular orientation. We installed a new glass bed on the printer last Friday night, and it measures 110mm in the long (Y) dimension. The tube support bracket is nominally 120mm wide.

My first idea was to chamfer away the bottom corner so that the bottom surface is only 108mm. That looked like this in OpenSCAD.

Chamferred.png


After taking away material right where the post holes go, I thought I'd better add some material and move the post holes away from the chamferred corner. So I came up with this. There's no reason why the holes have to be on the part's center line.

Pillars.png


This morning I printed it. The print was pretty bad. The print shifted over as the printer reached the tops of the chamfers. That means, I think, that the printer has a full 120mm range of movement, but it is not centered over the table.

Misaligned Layers.jpg


Then I tried to drill out the post holes. The printed material split. Apparently, it's sort of like plywood. If you drill through the plies, the alternating grain direction of successive layers holds it together pretty well. But if you drill parallel to the plies, it's just pulp. Er, it's strings of plastic that aren't stuck together very well.

That piece was ruined, but I decided to drill out the holes for the alignment bolts anyway. I found that the dimples in the model aren't big enough to attract the drill bit on the rough surface of the plastic. Also, 8.5mm thickness with a 7/32 hole leaves very thin sides, especially in pulpy plastic. So I decided to go thicker near the alignment bolts and to print the holes instead of drilling them. I could have just made the whole piece thicker, but I was in a plastic saving mood.

It is conventional wisdom that you can't print a horizontal hole. But I've been printing horizontal holes with no problem on this printer. I don't know why it works, but it does. Anyway, those changes led to this model. Note that I also cropped 3.5mm off each end, leaving a fairly thin wall between the post hole and the end.

Version 2.png


I made two, and I made them mirror images of each other. That way, the "legs" will protrude to the outside on each piece. Tiny thing, but it would bug me if I hadn't. (-:

The nuts were a tight press fit — I had to push them into place with needle nose pliers. The bolts slipped right through their holes, no cleanup required.

Version 2 Printed.jpg


Here they are holding up an old fluorescent tube I found in the junk pile.

IMG_9297.JPG

add commentadd comment in the forum

reader comment Comment from: canadianavenger on Tuesday, October 23rd 2012 - 6:26 PM
I always do a test pass with cardboard first to ensure that there are no errors in the generated g-code. [my laser runs on LinuxCNC]
reader comment Comment from: mattrsch on Tuesday, October 23rd 2012 - 6:13 PM
Cardboard cuts great. I usually try more complex assemblies in cardboard first since it cuts fast and it's cheap... And I'm prone to silly mistakes :-\
comment Buildlog Author Comment: kbob on Tuesday, October 23rd 2012 - 5:37 PM
Comment From Buildlog Author Here's a dumb question for you who already have laser cutters.

My UPS driver brings me about a cubic foot a month of corrugated cardboard wrapped around various items. Can you cut that stuff on a laser cutter? I have a nearly infinite supply available for free, so it seems like it would be better than buying plywood or acrylic sheets, especially when just starting to test/calibrate the machine.

Does that work? Or is it too flammable/too thick/too variable/other?

Tuesday, October 23rd 2012 - 5:30 PM

It's past time to update this build log. Progress is very slow, but enough has happened that I can write a couple of posts.

All the parts I ordered in August arrived. The last item to arrive was the Azteeg, and I've had it for a month now. Others have already said it, but I'll chime in too: the Azteeg X3 is a very good looking little board. That really surprised me -- most semi-hobbyist designers don't put much thought into their projects' appearance. Now I'm thinking I want to build an ORDbot just so I can put an Azteeg (and Roy's heated plate) front and center.

I've been getting into programming the ATmega chip. I didn't realize how limited the AVR architecture is. Eight bit arithmetic. No divide instruction. No hardware floating point. And the version of Arduino + GCC I have appears to be generating broken code for the software floating point.

I am still going to try to use the Azteeg to control the laser cutter. I've figured out how to pulse a stepper from one of the counter/timer compare registers, so that means I can time step pulses to the resolution of the timer, up to 16 MHz.

I've spent the last two weeks proving that linear acceleration ramps are computationally infeasible on the Arduino. :-( So I'm thinking about either a stepwise approximation or trying to program an S curve. A S curve would be better, as (a) it minimizes jerk when starting, and (b) it reduces acceleration near max velocity when the motor is running out of torque. I'll have to find out whether that's computationally feasible.

add commentadd comment in the forum

Thursday, September 6th 2012 - 6:04 AM

Here's a gratuitous photo of some Makerslide so this build log can have an image.

IMG_9237.jpg


Or maybe this photo instead.

IMG_9229.jpg


Since yesterday, more parts have arrived from Econobelt, and I have a tracking number for my Raspberry Pi.

And I'm writing another build log on Eugene Maker Space's web site. That one will assume a lot
less familiarity with lasers in general and the 2.x in particular, but more familiarity with the
maker space and with me.

http://www.eugenemakerspace.com/?cat=14

add commentadd comment in the forum

comment Buildlog Author Comment: kbob on Wednesday, September 5th 2012 - 2:55 PM
Comment From Buildlog Author
bdring wrote:I don't expect to ever see an Arduino based board doing any high speed engraving, but I think in vector cut mode it should go fast enough to do anything you need.


And that's okay. If I replace the Azteeg, it will find a home in a 3D printer.
reader comment Comment from: bdring on Wednesday, September 5th 2012 - 12:43 PM
I have preordered an Azteeg X3. I will use that for as long as I can. If it can't spin the stepper motors fast enough


I don't expect to ever see an Arduino based board doing any high speed engraving, but I think in vector cut mode it should go fast enough to do anything you need.

Wednesday, September 5th 2012 - 2:04 AM

Parts are trickling in.

I found one mistake with the parts I ordered. I got stepper motors with ¼ inch shafts instead of 5 mm. I naively assumed that NEMA standardized that stuff -- it turns out NEMA only specifies where a motor's mounting holes are.

So the couplers for the Y motor won't fit. I don't have a lathe to turn the shafts down, so I will order a replacement stepper for Y.

Fortunately, Stock Drive was back ordered on the 5mm toothed pulleys, so I haven't ordered those. I'll just order ¼ inch pulleys for X and Z.

Speaking of pulleys, Econobelt has pulleys in the right sizes, but they are metal, not plastic. Those should work, right?

Aside from the motor and pulleys, I've ordered all of the core mechanicals, optics, skins, and a quorum of electronics parts. I'm deferring the cooling system, ventilation, air assist, laser, and laser power supply until the chassis is built and the motors are moving the gantry and carriage.

I have received parts from:

I have tracking numbers from:

I don't have tracking numbers yet from:

add commentadd comment in the forum

Monday, August 27th 2012 - 5:39 AM

I have started building a laser cutter for my local maker space. Today I placed the big parts orders from Misumi and McMaster Carr.

I'm planning to follow the 2.x design as closely as possible for the mechanical assembly. For the electronics and software, I feel confident enough to step a little off the established path.

I found this site just a few days after Bart sold out the most recent batch of 2.x kits, unfortunately. So I'm going to have to improvise on those parts. I will buy a kit from Bart if/when he makes another batch. If I get to the point where I need the kit parts before Bart makes more, I will 3D-print them. That will work fine for some of the parts, I think. Others will just be temporary to get the assembly done, and I'll hand-fab them in aluminum later. I don't know what I'll do about the Delrin V wheels - modify the design to use Inventables' dual bearing wheels, I guess.

For the electronics, I have preordered an Azteeg X3. I will use that for as long as I can. If it can't spin the stepper motors fast enough, I will look at upgrading to either a BeagleBone or a commercial DSP.

So far, I've placed orders with Inventables, Automation Technologies, RadishWorks, Makerslide Store, Panucatt, Econobelt, McMaster Carr, and Misumi. The goodies have arrived from Inventables, Automation Tech, and RadishWorks. I have many more orders to place.

I'm building this for the maker space partly because we need one, and partly because I'm much more keen on building a laser cutter than on using one. It will be a challenge to get this finished to the point where it's not a "project" but a "production machine". But none of us would be here if we didn't like challenges, right?

add commentadd comment in the forum

About Us | Contact | 2010 BuildLog.Net