Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Lob0426

Pages: [1] 2 3
Projects / Grbl 1.1f appears to be working on Mini-Mega2560 with BCL
« on: April 19, 2017, 08:42:45 PM »
Months ago I was playing with a Mini-Mega Adapter;
I built an adapter board that plugs into an Arduino Nano connector. The Idea was to add the extra memory and storage from the Mega2560 to the L7 style boards that were on the Laser kits. Ran into many problems. Firmware was the main problem as BenCutLaser and T2Laser were using were using grbl based, but not true grbl, firmwares to run their software. Both Ralph and Zax got some things working but, the grbl for Mega was not that mature as yet! The full size Mega worked decently but the mini-mega was not cooperating at all. The most luck was with T2Laser until later updates. The first Mega2560 1.1e was not any better. But Ralph and Zax have put a lot more time into their software and it appears to be paying off for my project!

Today I tried grbl-master-mega-edge (I believe it is 1.1f) BenCutLaser seems to be working with the Mini-Mega now that Ralph has grbl1.1e for Nano working. And T2Laser ran through also. I will have to do some more testing. Next is actually connecting it too one of the Laser kits and see if it is working in the real world!

General Discussion / repaired Printrbot Play, updated tablet
« on: February 01, 2017, 08:42:26 PM »
OK so I do not why there is no easy button for this stuff!

The cat knocked stuff over onto the printer. That knocked the mount and tablet off of the printer. That jerked the USB cable out and unplugged the tablet power connector I fitted. The cable end was bent. It broke when I tried to straighten it.

I updated the Tablet to Win10 update 1607. The tablet updated and worked for several restarts, trying to get the cable to connect, then it would not restart. That seems to be how these things go for me. After two tries at reset I finally got it back up, but now have to reinstall a bunch of stuff. Tried a different cable and have the printer/tablet working again. Ordered a new OTG cable. That will get it back to it's manageable length again.

The tablet is powered from the printers PSU. This setup is great when you need to make a part fast or need to take it with you.

Projects / Foam Board Size machine upgrade (20" X 30")
« on: October 28, 2016, 04:08:34 PM »
Well Misumi USA talked me into starting a new project. They gave me 30% for the next 30 days. So I bought some 20X40 rail.

Dollar Tree Foam Board (DTFB)
Is used by us R/C modelers for building inexpensive aircraft. It cost $1 for a 20"x30" board that is 5mm thick (about 3/16") It has paper on both sides and a foam (styrene) filler.

There is a newer version that has water resistant brown paper skins. Unfortunately you can only buy it from right now. It is about $2 a board. but much more durable. It is only sold in a 50 board box at about $90 plus shipping. If me and my brother can get these Lasers to work satisfactorily with the board we will probably go in together to buy a box. Currently I can cut through the top paper and all of the foam. But the bottom does not cut. This means you can "cut" the lines and use them like  a stencil. Then just follow the lines with a sharp razor. Ultimately we would like to find the right settings to cut all the way!

Clear Anodized all 2040. I almost bought the Black anodized! It is about 30% more expensive.
(3)2040 x 900  $20.40   
(2)2040 x 650  $9.82

shipping/tax     $10
Total                $40.42

I also bought my Brother 5X1 meter rails for his project. So the shipping is higher than it should be. They also charged tax.

I have an A5 machine to donate the electronics. I have some other stuff coming in for the project.

List of changes needed.
1. swap out stock rails for new rails
2. swap to T-nuts during upgrade
3. extend laser and X stepper cables
4. extend Y stepper cables
5. extend Home switch wires
6. new GT2 belts for X and Y axis
7. add drag chain for wires to Laser/X stepper

Some decisions I have not made yet.
1. Move all electronics to the gantry, makes all the wiring simpler, but adds weight (inertia) to the Gantry system. I have successfully done this on an A5 system that I currently have. It seems to have little effect. Will it work out on a gantry that is 35" long rather than 10" long.The X carriage is going to be an A5 style rather than an A3 style I do not think this is going to be an issue.
2. add limit switches along side the homing switches.
3. A cover plate for the controller board. I have 12' x24" transparent red acrylic I can use for this.
4. shield for the laser. I am considering making a shield that hangs real close to the work to cut down the splash of the laser.
5. switch to 3W NDB 7875? Not sure If I should waste it for here, cutting, or use the stock 2.5W unit

Parts should tart arriving next week. Some are already here, ordered for other projects, I always order extra.

As Always, everyone is welcome to the discussion!

I thought some of you might like to see this:
The important words for us "LASER MODE" LOL!! Be sure to Thank any of the grbl Developers that you run into for their work. My testing of Laser Mode shows it to be right with J-tech in speed and better accuracy. Waiting for word from some of the others trying it out. This gives us a firmware that can be compiled for options like Limit/Homing switches and Z movement that we could not do with some of the other firmwares. That code hiding in the microcontroller is very important to the operation of our Laser machines!

This grbl 1.1 (1.1c3 our internal name for it) allows both T2 Laser and BenCutLaser to run equally well on one firmware. In the past if you wanted the best performance from these two software you needed different firmware, J-tech for T2 and grbl0.9i or j for BCL. Unfortunately Benbox software will not run on this firmware as it uses proprietary firmware to operate!

I believe @Zax is getting ready to make this firmware available in his next release of T2Laser and I am sure Ralph will also in BCL once he has completed his testing!
From Sonny Jeon, AKA chamnit.
This has been a long time coming and it's finally here! Grbl v1.1 is available for public beta testing at this new project site ( ). The new version has some huge features:
Real-time overrides for rapids, feeds, spindle-speed, spindle-stop, and toggle coolant states! All of these alter the running state within tens of milliseconds for instantaneous feedback. It feels totally different than how others do it, where you have to wait several seconds to a minute for a change to go through. It's awesome. You can have your CAM program generate a conservative feeds and speeds and then alter them on the fly at the machine to optimize your job. You can also feed hold and stop the spindle and coolant (vacuum) mid-job to inspect how your part is coming along or to clean out swarf!

Laser mode! Grbl now officially supports laser cutting and it works with spindle speed overrides (aka laser power) too! It's just a simple $ setting to change and Grbl will then move continuously through consecutive G1/G2/G3 motions when an S spindle speed word is present.
Jogging mode! This new jogging command is different than feeding Grbl g-code commands, mainly because you can cancel it and Grbl will automatically feed hold and flush the buffers. It also doesn't alter the g-code modal state, so you no longer have to track them. This helps reduce inadvertent crashes when you forget and start you job.

There's a bunch more features, but those are the big ones. Keep in mind that this is a BETA release. There most certainly are some bugs here and there. So, please use this if you'd like to help out with the testing. Please report issues at the NEW SITE, rather than here.

IMPORTANT NOTE: Grbl v1.1 altered some of its interface to cram more data into the status reports and make it easier for developers to maintain their GUIs. Grbl v1.1 only works with GUIs that support it. So far, this includes (in order of most v1.1 support):

Grbl-Panel: Just about full compatibility.

UGS Platform Nightly Build: Click the bottom-most link. The overrides pane is enabled via a menu item. Only new minor features not yet implemented.

bCNC: Operational, but no override controls yet.

PicSender: Status unknown, but they are working hard at it!

The Wiki is not yet up and operational, but there is a lot of documentation that I've written in the /docs/markdown ( ) folder. You can navigate to it through the Github website or click the link. Github will show it in markdown form.

Thanks everyone for being so patient! It's been a tough couple of years for me and my family, but we are finally seemingly in the clear. That and with this beta release finally out, it's a huge weight off my shoulders. Cheers!

General Discussion / This is a pretty good price!
« on: September 24, 2016, 05:07:51 PM »
A3 2500mw from Banggood.

You can choose expedited, instead of 8 to 20 day free shipping.
Expedited Shipping Service Free shipping
5-8 business days

Projects / Convert stock Benbox laser unit to higher power diode.
« on: September 22, 2016, 04:06:51 PM »
Opening thoughts;
It took 5 days for me to get the stock "host" out of the heat sink. My host is aluminum. I had to soak it in finger nail polish remover. And I only was able to remove it with snap ring pliers. Even then it took some work to get that first movement, then it came out relatively easy. Those were suggested by a fellow forum member @kn4ud. The pliers probably would have worked a couple of days before.

This unit was a 500mw stock laser diode/host/heat sink. The stock laser diode was 3.8mm sized package (TO38). I intended to use the lathe to open the host up for a 9mm (TO5) diode. After I removed the host I knocked out the diode. I saw that there was a brass adapter from 5.6mm (TO18) down to 3.8mm. I knocked that adapter out and it exactly the right size for a 5.6mm diode.  There are a number of diodes in this size from 1W to 2W. And these are inexpensive to buy.

I have decided to use one of the M140 2W diodes in this housing. There are two reasons for this change. One is the host is aluminum. The higher powered NDB7875 (3W) needs more cooling. The fact that this will give those with these low powered unit a path, that does not need machining, for a major power upgrade. This should be true of many of the stock units.

I have a 1.8A Super-X Drivers to use with the M140 diodes.

If you have disassembled a stock Benbox laser unit, or another kit laser unit, please report on the diode size, host material (aluminum, copper, brass) and wattage. This will help others to know what they can do to upgrade their units. See link below if you need help in figuring the size.

I will post some pictures later. I hope this will help others upgrade their units for better performance.

General Discussion / Microstepping article from Hackaday
« on: September 03, 2016, 01:13:06 PM »
I thought some of you might want to see this. It is about accuracy and micro-stepping accuracy from drivers.

Projects / Project: Mega2560 to L7 board test.
« on: August 28, 2016, 11:41:12 PM »
If you have been following the TTL board posts you probably have read most of this already.

I am proposing to test the Mega2560 board (here after called Mega) using an L7 Eleks Maker board as a "Sheild". I will use bread board wires to make connections from the headers on the Mega to the the headers on the L7 board. The Arduino Nano board will be removed from the L7 board. This means that the stock cabling in our Laser kits will be able to be used without modification. The Stock Laser will operate just as it does with a Stock L7 board. I hope!

As an aside the L1, L2, L7, L8 or L6 boards should all work exactly the same.

This is not a "permanent" solution. This is a test as to the performance of the Mega versus the Nano controllers. Hopefullly I can come up with a "sheild" that uses the advanced features available on the Mega as an upgrade for our machines. This would mean drawing up a board designed for these laser kits.

The real goal would be to get a ARM powered solution that will really improve performance over these Arduino boards. Grbl is headed that way but not there yet. The Mega would be an intermediate step to better performance and the firmware is available now. It is in BETA but has been out for about 5 months and is based on grbl edge, the precursor to grbl 1.0, the end step of the Nano/Uno work. Grbl 1.0 is supposed to be out "soon" and supposed to support a Laser mode that will enhance laser performance. these updates will also be applied to the Mega branch.

As you can see from this comparison chart both have the same clock speed of 16Mhz. The Nano, with 328P, has 1KB EEPROM, 2KB SRAM and 32KB Flash storage. The Mega has 4KB EEPROM, 8KB SRAM and 256KB Flash storage. There is a lot more resources available on the Mega. Many will see the 16Mhz and think you will not see any speed advantage from the Mega. This is not the case, grbl firmware allocates twice the the Block Buffers on the Mega and 40% more Segment buffers. This means that the Mega accepts more code into memory at each read. So less time is spent reading and writing to memeory. So less of a load on the processor for the same amount of code. This "comparison" will not compare the added "pins" that are available to be used by the Mega. We will use exactly the same number of pins as the L7 board uses, though they may not be the exact same pins!

In my earlier ramblimgs I had thought that re-doing the cpu_map for the Mega firmware;  Mega version        Nano/Uno version

was the way to go. meaning re-allocating the mega pins the same as the Nano pins used. This would have worked. I now believe for simplicities sake the better route is to use the default mega pin mapping to run the tests. This means people will not have to fool with cpu_map at all. And if we find a solution to using the Mega in our machines people will not have to remember what they changed. I would like everyones thoughts on this!

I plan on posting plenty of pictures of this Frankensteins mess in case any of you wish to follow along.

@Zax pointed out to me that T2Laser does not necessarily need grbl to operate.

"T2Laser supports G-code, it doesn't need to be Grbl in particular. I can write an interface module for a different hardware setup if there's enough interest. The concept of being modular allows me to have a different sender / controller for other systems.

I'm also very interested in the other ports (ARM) that seems to be the future for Grbl. It sounds like the Nano version is dead once 1.0 is released."

BenCutLaser I believe does need grbl to operate, but I am decently sure @Ralph could change that if need be.

To Do List:
Remove Nano from L7 board, leave everything plugged into the board, Motors, drivers and Laser. (sshhhh,,, I have an extra if it catches on fire!)
Compare the cpu_map.h from grbl Nano to cpu_map Gnea/Grbl-Mega and draw up a map of where to run wires from and to.
Use bread board wires to make connections from the Mega's headers to the headers on the L7 board.
Double check everything.
Power it up!
Watch for any Magic Blue Smoke being let out!
Run timed tests between boards at engraving.

Many of the 3D Printer firmawares could be used to make our Laser kits work. And that opens up many boards that could be used. But most people want something that they know will work. Not something they have to fool around with to make it work. We know Grbl works for the software (BCL and T2Laser) and for the hardware that we are currently using.

There is no "Benbox" version for the Mega. If you like using Benbox software, then this post is not for you. Benbox is it's own little world. I have been playing with it on the 500mw machine and it actually works ok. I kind of ignored it at first. But it does work even if it has very few features and is relatively simple. There is no source code for the firmware to make adjustments to use the resources available on the Mega. You would get similar if not exactly the same performance as the Nano, if you could make it work!

NOTE 2: The Mega will not be here until at least Tuesday from Amazon.

Trouble Shooting / Here is a good one for you!
« on: August 15, 2016, 06:40:12 PM »
So the 500mw from GearBest came in today. I have been putting it together all day. Taking lots of pictures. Documenting assembly.

So I get it all together and decide I just need to Burn something, after about 6 hours of work. I connect power, and USB to the tablet. As soon as I push the power button the Laser comes on. I turn it off and check all the wiring again. Power on, Laser on. I play around and finally the Laser stays off when I power on. I thought maybe the Low Laser button was sticking. I try to burn an outline and the Laser works just fine. Worked several times. Then the Laser would not come on at all. Motors continued to work through all of this.

I power off as I see I forgot to tighten the screws on the carriage and the belt is way too loose. Power on, Laser on again. I screw around with the Low Laser pot. I finally get the Laser off and then it will not come on again.

Ok this is getting disturbing. I remove the board. Check it for solder balls, dry joints etc. Looks good. Plug it in hanging free. Power on, Laser on. Disconnect it again. Try a different Nano. Tried changing the jumper. No difference. Pulled the Nano again and the drivers, see nothing wrong. All of this is with Benbox and Benbox hex. Tried GRBL .09i from @Ralph. Same thing in BCL on two different Nano's.

So I look the board over again. The back of the board looks kind of cloudy/gummy, not bad, but not clean, like there is some left over flux. I dig out a toothbrush and give it a good scrub. I take a Q-tip with alcohol, rub the board down. Let it dry. Now its clean.

The Board works every time now. I knew that lasers can be triggered by very low voltages, but that low. It had enough power that it was lightly burning the wood.

So I guess if you are having Laser ON troubles you need to clean the dang board!

30 minutes I will never, ever get back LOL!

T2 Engraving / Laser support in GRBL 0.9j not working.
« on: August 09, 2016, 05:21:12 PM »
I just compiled GRBL 0.9j with Minimum Junction speed set to 20mm/min the engraving finished faster and was cleaner. So Laser Support may already, at least partially, be implemented in GRBL. I think it is going to take some playing around to see what it needs to be set at. Definitely had the carriage moving faster. @John63303 was playing with this already.

#define MINIMUM_JUNCTION_SPEED 20.0 // (mm/min) was 0.0   in config.h

Unfortunately the only way to set it that I can find is to re-compile each time. Hopefully that will change with the release of GRBL 1.0.

Scorpions; one on left new settings on right old. neither very good needed better focus. Both at laser 158 speed 1000. very soft pine, burns really easy.


Assembly Help / Assembly tip, Use a square!
« on: August 06, 2016, 04:18:21 PM »
I just went over my machine with a "square" similar to this one;

And I found several issues.
My frame is square, no issue there
My gantry was not square, the beam was tilted and each end was tilted a different direction. loosened up the four bolts and realigned the ends. and made sure the beam was straight up and down. Now the Laser is straight up and down.
My Laser was tilted clockwise. Used the square to set it right.

Now the ends of my circles meet up and there is not a gap in the meeting point of the Squares or round corner squares.

So buy one of these relatively cheap squares and go over your machine. better yet buy a machinist square


To carry out limit switches you will have to get GRBL-Master files.

download the GRBL-Master files. You should also read this from GRBL about how to get GRBL loaded and ready for compiling.

You will also need to visit:

download the Arduino IDE.

First of all you need to install your limit switches. There are various methods and switches to use. Most likely you will find a solution from a 3D printer. You could also make your own switches and harnesses. Then you have to install them in a place where they will contact the X axis (Laser Carriage) and the Y axis (Gantry) Again there are several ways to accomplish this. These switches can be Normally closed type or Normally Open type. GRBL allows either to be used.

Connection to controller board:
If you have an L6 or L8 style board, 3 axis controller with pins brought out for limit switches then you just need connector to plug your switches into the header pins. If you have an L2 or L7 style board then you need to have at least moderate soldering skills to add the limit switches to your kit. I wold reccomend the L6 or L8 boards. L6 or L8 boards use pin D9 for all the limits. Again GRBL is very accomodating as to how you set up limit switches. These accomodations mean you will need to compile a hex file to use you r switch setup if it is not the default style already setup in the default config.sys,cpu_map328p settings. These are what is called firmware. Firmware is installed on the Controller, in this case an Arduino Nano clone. More on this later!

First we need to decide which end is which. The end that the controller board mounts on is the BACK. So the other end is the FRONT. X axis is movement of the "Laser carriage" that slides left and right if you are looking from the front. Y is the movement from back to front, a part I call the "Gantry". If you want to conform to the available programs such as BenCutLaser and T2Laser then your "home" position is going to be towards you and to your left. The left front corner. If you use other programs that have firmware that supports homing they may call for a different home position.

As touched on before this is the software installed onto the Arduino Nano controller that commands the operations of your Laser kit. The Firmware is a gcode interpreter, GRBL. The controller receives "gcode" from the software, like BenCutLaser or T2Laser, and turns those commands into movements by your stepper motors and turns your Laser on and off etc.. These gcode commands do dozens of other things Like tell the steppers how far to move, what speed to move at, Metric or Inch, plane of operation (X,Y G17, in this case) and to carry out more advanced movements like Arcs. luckily your programs write most of this without your intervention, but you can write the gcode yourself.

The Firmware has to be compiled from a set of files that tell everything how to operate. Important to us is the commands "#define" that allow us to get our limit switches operating, and running in the correct direction or type. So we will have to edit the default settings IF we do not use the default settings for our limit switches.

COMMENT: I use windows WORDPAD to edit these files. it breaks the lines of text into readable files. Notepad is just a big single block of text.

The defaults are;
These are the cpu_map pin assignments for 328P.
X limit     D9   (1)
Y limit     D10  (2)
Z limit     D12  (4) or D11 (3) depends on version jumper position

#define HOMING_CYCLE_0 (1<<Z_AXIS)                // REQUIRED: First move Z to clear workspace.
#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))  // OPTIONAL: Then move X,Y at the same time.
// #define HOMING_CYCLE_2                         // OPTIONAL: Uncomment and add axes mask to enable

So those are the default pin settings and the default limits switches settings.

So your X switch is supposed to operate on pin D9
Your Y switch is supposed to operate on pin D10
We do not use the Z normally but it would be an either pin 12 (D12) or pin 11 (D11) depending on if you set the PWM jumper.

These settings actually cannot be used without modification on our staock makchines as we do not have a Z axis to set off the appropriate switch. this means the "homing" operation would fail every time without you at least commenting out Z limits.

note the // and a space this tells the system to ignore anything after it! it is "commented out"
// #define HOMING_CYCLE_0 (1<<Z_AXIS)                // REQUIRED: First move Z to clear workspace.

And this would still not cure your porblems as it needs a HOMING_CYCLE_0. so we change to;
#define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS))  // OPTIONAL: Then move X,Y at the same time.

This will send both X and Y looking for their limit switches simultaneously. So if we have separate limit pins assigned (X as D9 and Y as D10) to our X and Y switches then we will now complete a homing operation. BUT, the L6 and L8 boards combine all limit switches (X,Y and Z) on D9. So we will end up with the controller stalled if we use the default settings with those boards. what we have to do for those boards is separate the X and Y homing cycles and go into cpu_map_atmega328p.h and put X and Y on the same pin

this is the section we are looking for in cpu_map_atmega328p.h. this is the defaultwe need to change!
    #define LIMIT_DDR        DDRB
    #define LIMIT_PIN        PINB
    #define LIMIT_PORT       PORTB
    #define X_LIMIT_BIT      1  // Uno Digital Pin 9
    #define Y_LIMIT_BIT      2  // Uno Digital Pin 10
    #ifdef VARIABLE_SPINDLE // Z Limit pin and spindle enabled swapped to access hardware PWM on Pin 11. 
      #define Z_LIMIT_BIT      4 // Uno Digital Pin 12
      #define Z_LIMIT_BIT    3  // Uno Digital Pin 11

We need to change these two lines to;

    #define X_LIMIT_BIT      1  // Uno Digital Pin 9
    #define Y_LIMIT_BIT      1  // Uno Digital Pin 9

We also change the notation at the end so we know what we changed later. We are not worried about Z. Always make a backup of any .h file you intend to change. If everything goes bad you can copy them back to start over!

Now that both X and Y are on the same pin. We need to set X and Y to home as separate operations. Back to config.h
#define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS))  // OPTIONAL: Then move X,Y at the same time.

we are going to searate these in to two cycles. I know there is a fancy way to do it, but i am goig to do this the easy way.
#define HOMING_CYCLE_0 (1<<X_AXIS)  // Move X.
#define HOMING_CYCLE_1 (1<<Y_AXIS)  // Then Y.

Especially note the parenthesis () compared to the upper example. The upper sets are nested and will cause you problems if you do not pay attention to them!

Now you compile GRBL and upload to your Arduino Nano. Now your limit switches should be ready to work to work. we still need a few more things changed to get the limits working. These are EEPROM settings. I use Universal-G-Code-Sender to edit these. These are from @Ralph the Administrator of changed to have the right settings to get our switches working.

$0=10 (step pulse, usec)
$1=25 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=2 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=3.000 (junction deviation, mm)
$12=0.020 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=500.000 (homing feed, mm/min)
$25=2500.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=80.000 (x, step/mm)
$101=80.000 (y, step/mm)
$102=80.000 (z, step/mm)
$110=4000.000 (x max rate, mm/min)
$111=4000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=450.000 (x accel, mm/sec^2)
$121=400.000 (y accel, mm/sec^2)
$122=400.000 (z accel, mm/sec^2)
$130=300.000 (x max travel, mm)
$131=300.000 (y max travel, mm)
$132=200.000 (z max travel, mm)

The important ones

I would change any that do nOt match as reported by your Nano in Universal-G-Code-Sender.

Now your limit switches, on one pin should work. X should go to the left and bounce a couple of times, then Y should come towards you and bounce a couple of times. It should now be ready to get down to business.



General Discussion / Sizing pictures for the forum
« on: August 05, 2016, 05:41:18 PM »
Most of us use Windows of one type or another. You can resize your pictures using Microsoft paint very easily.

Right click on your picture, click edit, that will open paint. In paint left click "Resize" then click the bullet for "pixels" then in the top box type in a normal screen size like 1024 or 800. These will be converted to 1024X768 or 800x600. you do not need to specify the second half it will figure it out for you. Then save it under a descriptive name so you do not ruin your original picture This also reduces their overall size so they send faster and open faster. It makes your pictures much aeasier to view when they are not 3264x2448 pixels and 1.5MB in size!

I find 800x600 to be the best for most pictures to this forum. Sometime 1024x768 if you want to see it a little bigger for detail.


General Discussion / The Need for SPEED
« on: August 02, 2016, 01:12:01 PM »
So I was playing around a bit ago. I wanted to see what top speeds this Laser could handle. IT WILL GO FAST. I found that if I went above F12500 I could hear low grade grinding noises. You hear these some times when moving the gantry by hand if your machine is like mine.

Homing quits working right about F7500 you can extend this be raising the homing de-bounce, but how accurate do you think homong is going to be when the machine slides around from such high speeds. An interesting fact is that acceleration management doe not have an effect in the homing cycle. It moves at whatever speed you set until it hits the switch, because it does not know where the switch is until it hits it.

On the other hand acceleration/deceleration makes a dramatic appearance at these high speeds (F1250) you can actually see the X carriage and the gantry slow as they approach the limit you sent.

$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=2 (dir port invert mask:00000010)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.010 (junction deviation, mm)
$12=0.020 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=500.000 (homing feed, mm/min)
$25=7000.000 (homing seek, mm/min) Homing unreliable above F7000 hits switch so hard it does not bounce back!
$26=300 (homing debounce, msec) homing debounce moved to 300 help with reliable home at high speed. Was 250
$27=1.000 (homing pull-off, mm)
$100=80.000 (x, step/mm)
$101=80.000 (y, step/mm)
$102=80.000 (z, step/mm)
$110=15000.000 (x max rate, mm/min) grinding noise above F12500
$111=15000.000 (y max rate, mm/min) grinding noise above F12500
$112=4000.000 (z max rate, mm/min)
$120=450.000 (x accel, mm/sec^2)
$121=400.000 (y accel, mm/sec^2)
$122=10.000 (z accel, mm/sec^2)
$130=146.000 (x max travel, mm)
$131=201.000 (y max travel, mm)
$132=75.000 (z max travel, mm)

$H = perform homing cycle. the speeds for this are set only in the EEPROM settings

G1 X146 Y201 F12500; G1 linear move, X146 moves carriage to far side from home 146mm, Y201 moves gantry to far end from home 201mm. F designates speed 12500mm/minute (feed rate) You have to set the max federate settings for X and Y.

You send $H and it goes to home position switches, X first then Y. Then you send  G1 X146 Y201 F12500 changing the feed rate until it starts making noise. That will be the maximum your machine can handle. You can home by hand by moving the X carriage over then the gantry down.

WARNING: I do not recommend that you operate your machine at these speeds. If decide to you are responsible for any damages that YOU cause. You will loose accuracy even with deceleration working properly. You may increase wear as well. these speeds are just for giggles as there is no way your Laser can cut this fast,,,, EVER. Your machine can move between "cuts" points at these speeds but again is not recommended due to loss of accuracy.

It is humorous to watch this little machine run this fast. with some work these things could be even faster, but unless you have a 100W Laser in your back pocket to use with it, it just is not practical.

So what did I find out?
you can run homing seek to F6000 and it will probably not effect accuracy as far as I can tell. The homing feed check the switch again. To be safe I will probably go no more than F5000. @Ralph has limited BenCutLaser to EDIT: F4000 jog speed in the .ini. It is partly his fault I decided to see what the machine could do. I did not think it would operate that fast, I was wrong. But @Ralphs figure is probably very accurate for the typical operation speeds of this machine. You could probably hit F8000 in the bigger frames and not have problems. Maybe higher with more acceleration tuning.

Most of our machines are set to about F3000 in the EEPROM setting of GRBL. And I have not tried Benbox to see what it will do but I think it around F3000 max as I saw no gains above that.

Engraving speeds are probably all well below F2000 even in the 5.5W machines. And the 2.5W machines are probably below F1500 for anything except balsa. And cutting speeds are probably half of those. @Ralph or @Zax, and some of you, could probably say better than a FNG like me.

So have fun and don't destroy your machine, but you will get a laugh at the speed these really can move at!

So now I have to go return my settings to something safe and sane, Like fireworks!


Pages: [1] 2 3