Constructing Janus, by Dirk

Post your build logs here

Re: Constructing Janus, by Dirk

Postby dirktheeng » Wed Jun 15, 2011 11:19 pm

cpdude wrote:Dirk,

To comments...1) I think that 1000mm/min is probably way too fast for the Z axis. Just my 2 cents. 2) I'm not sure which motors you are using but most steppers--including the stock ones offered by Bart--are 200 steps/rev. I think that would make 1/2 micro-stepping equal 400 steps/rev.

Brian


1) I think it is probably about right for the rapid moves, feed moves can be much lower, there is plenty of room for slow moves as well. I want to install a homing switch on the z axis and don't want to wait 10 minutes for it to move down to find it (ok 10 minutes is an exaggeration, but still). I'd really like the speed of the axis to be somewhat close to the other axes (it's ok if it is slower by a factor of 2 or 3). If it isn't I really have to watch the feed rates if I do g1x--y--z-- moves or never move the z with x or y. If it is possible to design the system so that I don't have to worry about accidently giving it a bad command that causes a motion problem, then I would like to do that.

2) I got the motors from Bart. His engineering cut sheet says that they are 0.9degree steppers (400 stepps/rev). I initially thought that they were 1.8 degree motors too, but when I gave it a command for 100 mm, it only moved 50 until i doubled the stepps/rev in the controler from what I expected.
dirktheeng
 
Posts: 616
Joined: Thu Sep 09, 2010 4:49 pm

Laser Cutter G-Code interpreter (LCGCi) code link

Postby dirktheeng » Thu Jun 16, 2011 4:27 pm

Here's a link to the "Laser Cutter G-Code interpreter". It is based on grbl, but will have sereral very specific modificaitons for laser cnc's. It works well with our pololu driver board. Check the code regularly as I will be making several changes over the next while.

https://github.com/dirktheeng/grbl
dirktheeng
 
Posts: 616
Joined: Thu Sep 09, 2010 4:49 pm

All 3 axis working together now

Postby dirktheeng » Thu Jun 16, 2011 10:02 pm

Well, I finally got all 3 axis working! It was an ordeal, but it is done. I'm going to post a video soon. Thanks Ben! He had an extra pololu driver that he sold me when I burned mine up and there were no extras on any websites to buy.

Also, I found out that putting wires in the IC plug to jump them is not a good idea as it stretches the springs in the plug and the IC no longer sits well. I got some really crazy behavior out of my steppers until I replaced the IC socket. Fun stuff

Next up, programming the serial communication to make the headless controller. I'm really excited about that... follow and/or contribute to the code development at https://github.com/dirktheeng/grbl. I'm very excited.
dirktheeng
 
Posts: 616
Joined: Thu Sep 09, 2010 4:49 pm

open source firmare developments

Postby dirktheeng » Sun Jun 26, 2011 4:25 am

Well folks, it has been a very long week. I started a new project at work and I have had to learn some software and new programming so I have been working late. I have not given up on this project, but I don't have a lot of actual physical hardware progress to show. Right now, I have been working on developing a stronger verstion of GRBL. The code is good at it's core for the most part, but lacks options that make it convenient for setup and the homing was pretty bad. I fixed that stuff now and it works well as is for the 2.x hardware with barts driver board running on a UNO. I think the code space for a 128p is too small to hold this so you will need a 328 or better to make this work. The main development action is on github now. You can get the code at https://github.com/dirktheeng/grbl . I have posted a development plan and progress.

The next thing is to add all the options we need to configure the code correctly from a setup menu. This makes it very user frendly and easy to set up for a variety of hardware configurations.

After that, I will move the limit pins from the digital IO to analog in to free up 3 more digital IO pins for other purposes. Then I will get 2 arduinos talking to eachother and start developing the PC based interface software. I will also begin developing an image to g-code engraving option that can run on the same system. This should be fun and work well. If anybody is interested in helping please let me know.
dirktheeng
 
Posts: 616
Joined: Thu Sep 09, 2010 4:49 pm

Re: Constructing Janus, by Dirk

Postby BenJackson » Sun Jun 26, 2011 8:47 am

I googled a bit the other day but didn't discover: Is there a standard for gcode raster information? Trying to find "gcode engraving" information mostly turns up router/mill type engraving.
BenJackson
 
Posts: 522
Joined: Fri Apr 15, 2011 6:13 pm

Re: Constructing Janus, by Dirk

Postby bdring » Sun Jun 26, 2011 2:20 pm

G-Code is vector only. There is no realistic way to provide image information along the move. I suppose you could program the move from pixel to pixel with power information, but most controllers like to accelerate and decelerate on each move and often pause while power levels change. You could write your own controller to fix that, but by then things are so custom, you might as well use a more appropriate method of sending image information to the controller.

BTW: Does the GRBL code do constant velocity moves? Controllers without it do pretty badly on things like ellipses where it is really a set of lines. Fonts could be rough too.

Also: A long time a go I wrote a G-Code commenting app, so you see what is going on in G-Code. It is also a good general reference for G-code by clicking the "show all codes" button. There are a lot of flavors of G-Code. It is leans towards a Mach3 type flavor.

http://www.buildlog.net/cnc_laser/cnc/g ... mment.html
Bart
"If you didn't build it, you will never own it."
bdring
Site Admin
 
Posts: 2966
Joined: Sun Nov 22, 2009 7:33 pm
Location: Chicago, IL, USA

Re: Constructing Janus, by Dirk

Postby dirktheeng » Sun Jun 26, 2011 7:39 pm

bdring wrote:G-Code is vector only. There is no realistic way to provide image information along the move. I suppose you could program the move from pixel to pixel with power information, but most controllers like to accelerate and decelerate on each move and often pause while power levels change. You could write your own controller to fix that, but by then things are so custom, you might as well use a more appropriate method of sending image information to the controller.

BTW: Does the GRBL code do constant velocity moves? Controllers without it do pretty badly on things like ellipses where it is really a set of lines. Fonts could be rough too.

Also: A long time a go I wrote a G-Code commenting app, so you see what is going on in G-Code. It is also a good general reference for G-code by clicking the "show all codes" button. There are a lot of flavors of G-Code. It is leans towards a Mach3 type flavor.

http://www.buildlog.net/cnc_laser/cnc/g ... mment.html


GRBL does do constant velocity moves. There is a video of Simen (the developer) running his cnc to cut out a "Hello Kitty" stencil for his daughter. There is also several other videos of the code working with non-regular geometry. It also does acceleration planning up to 20 moves ahead. I'm not going to lie... there are a few bugs in it, but the code is fairly understandable and they aren't hard to fix usually. I haven't pushed the motion control system very much yet, but from others it seems fairly solid.

Bart, what I plan on doing is using gcode to create a roster pattern, but not stop at every pixel. What I mean is say I have a 100mm by 100mm engraving pattern to do. I would create the raster by gcoding something like this:

G1X0Y0 (STARTING POSITION)
F1200 (feed rate)
G1X120YO
G1X120Y0.01
G1X0Y0.01
G1X0Y0.02
G1X120Y0.02
....

here the engraving pattern corners would sit at 10,0 and 110,100 and be rastered in the x direction. This will create the base of the raster. To track the position so I know when to fire the laser, I am going to use cheap up/down counters to act as integrators. I will read that into the mega (the master controller not the slave g-code controller) and write a script to fire the laser at a given power level based on the position read from the counters. That way I don't have to stop at every pixel point and burden the g-code controller with calculating and setting the laser. I think this should work well. The max stepper frequency that can be produced via the grbl/arduino is about 30 kHz, so there is a lot of room to read and do a simple operations on the master during the constant velocity moves executed by the slave. I anticipate being able to go through the power set loop on the master several times before the slave moves to the next step. If the laser is fast enough or the velocity is slow enough, I may be able to send a single laser pulse for each step. I think the laser is rated at 1 miliseconds response time, which means I would have to set the feed rate to go about 1000 pixels in a second, so it would take about 17 minutes to do a 1024 x 1024 image. I am assuming that the laser response is so fast compared to the movement of the x axis, that the motion blur is neglegable. If I want to get really fancy, I can try to measure the dynamic response of the laser and plan for that in the control so that the position of the pixel is exactly centered with max power of the laser, but I really don't think that is necessary. Given the resolution of the steppers and size of the pulleys, we can easily reach 1000 dpi resolutions.

Doing things this way, I think I can create a very good general purpose laser controler for under $100 (actually, if you build a board that holds a couple AVRs on it, it could be only $20 or so) that can be completely headless and interact with a computer via USB.
dirktheeng
 
Posts: 616
Joined: Thu Sep 09, 2010 4:49 pm

Re: Constructing Janus, by Dirk

Postby bdring » Sun Jun 26, 2011 7:58 pm

Good news on GRBL. I assumed that was the case

your proposed method....

That is basically how my XMOS controller and the Mach3 plug in works, but where is the image data coming from? You can either have it already in memory or you can stream it in, but I don't think it is realistic to get it in via G-Code. I decided to stream it in because the memory could not hold a big image. Telling the controller the general raster parameters is rather simple (speed, width, stepover, number of rows) so I did that upfront once, rather than telling it at each row.

If you are just doing an on/off per pixel you will find that the laser will probably react acceptably. Most images usually have a few on then a few off anyway and you just leave it in the previous state if the next state does not change it.

The nice thing about an XMOS controller is the multiple cores. The pulsing engine will never be affected by anything else like interrupts or communications issues. You might want to do as much pre-processing as possible before each row so that it runs smoothly.
Bart
"If you didn't build it, you will never own it."
bdring
Site Admin
 
Posts: 2966
Joined: Sun Nov 22, 2009 7:33 pm
Location: Chicago, IL, USA

Re: Constructing Janus, by Dirk

Postby dirktheeng » Sun Jun 26, 2011 9:02 pm

bdring wrote:Good news on GRBL. I assumed that was the case

your proposed method....

That is basically how my XMOS controller and the Mach3 plug in works, but where is the image data coming from? You can either have it already in memory or you can stream it in, but I don't think it is realistic to get it in via G-Code. I decided to stream it in because the memory could not hold a big image. Telling the controller the general raster parameters is rather simple (speed, width, stepover, number of rows) so I did that upfront once, rather than telling it at each row.

If you are just doing an on/off per pixel you will find that the laser will probably react acceptably. Most images usually have a few on then a few off anyway and you just leave it in the previous state if the next state does not change it.

The nice thing about an XMOS controller is the multiple cores. The pulsing engine will never be affected by anything else like interrupts or communications issues. You might want to do as much pre-processing as possible before each row so that it runs smoothly.


The image data as well as any cut files are going to be read from an SD card. I got an sd card shield from spark fun and can use it with the MEGA. Here's a pic.

DSCN3574.JPG
SD card setup


The only problem is that this sheild blocks one of the pins on the MEGA. I'm going to have to use my dremmel to unblock it if I need it, but that's ok. I think this was developed for the UNO form factor, but it will work just ine.

This is how I also plan on doing headless cnc controll. The system will read and stream code from the sd card as needed without need for a computer during a run. I will write a PC script to process engraving information into a (set of) text file(s) that can be loaded onto the controller. Then all I have to do is select the file and set the mode and go. The arduino's will take care of both engraving and vector cutting on their own, even if I unplug the usb from the computer.

I looked at the XMOS controller and found that programming could be very challanging because you have to worry about parallel issues (that's part of the advantage, but seemed harder). Plus I think you need to buy a bootloader to load the programs (not that that's a big deal). The main thing is that the GRBL looked fairly developed and solid for motioin control and seemed like a good basis to build a general purpose controller from. If the team that developed Maple makes one that uses the parallel version I might start to look into tranferring the code, but that could be a LOT of work. I think I would rather develop my own PCB that houses 2 AVR's that I can load the code on.
dirktheeng
 
Posts: 616
Joined: Thu Sep 09, 2010 4:49 pm

Re: Constructing Janus, by Dirk

Postby bdring » Sun Jun 26, 2011 9:31 pm

Well, my original response was to Ben's engraving with G-code question. There is more going on than just G-Code. You should profile the read time for the SD card. You may need to adjust the code around that timing.

The XMOS is a better chip for the problem if being a popular open source platform is not part of the problem. That is why I stopped working on the project. There was no collaboration interest.
Bart
"If you didn't build it, you will never own it."
bdring
Site Admin
 
Posts: 2966
Joined: Sun Nov 22, 2009 7:33 pm
Location: Chicago, IL, USA

PreviousNext

Return to Build Logs

Who is online

Users browsing this forum: No registered users and 25 guests

cron