Upgraded XY plotter - 6W laser

#37

It’s possible - 6W will make a definite mark in plywood, but I haven’t cut through yet.

I did some searching online, and using the same diode I have, here are suggested parameters for cutting different materials:

Note, that this speeds and parameters are effects of tests and can be different for some materials, cooling systems as well setting of the focus distance.

Vinyl 2mm: 100mm/min; 5W; 1 pass (requires smoke removal)
Wood 3mm: 200mm/min; 5W; 3 passes (1 pass for each mm)
Plywood 10mm: 300mm/min; 5W; 10 passes (1 pass for each mm)
InchJet Photographic paper: 400mm/min; 5W, 1 pass
Paper: 600mm/min 2W, 1 pass

When I was trying to cut plywood I wasn’t at full power yet, probably didn’t do enough passes, and my laser was probably a little too high above the material, which affects the focus size. I’ll have to try it again.

#38

wow impressive, I bought a more powerful laser, expected to just plug in and it would work “wrong”

I am using Benbox to run the laser at the moment do I carry on with that and add that code youve done ?

#39

I don’t use BenBox. I have a CNC machine and software for making cut paths for that, so I’m used to working with GCode. The GCode parser for the XY plotter is what I modified to run the laser, but as long as it’s patched through the M1 power connector then BexBox or MDraw should also work. Note that it won’t be as simple as just plugging it in - I had to do a bit of soldering to make mine work from the M1 motor output - the laser I use has its own power supply and driver board. I had to patch the M1 output into that to make the Orion control it.

#40

Is the zip in the first post still the latest version of your optimized GCodeParser?

I’m having quite some trouble making it work. Sometimes the steppers move, most of the time they don’t.
Did you by any chance change anything to the configuration of your plotter, besides the laser upgrade? Steppers? Limit switches?

(I’m working on a version of the GCodeParser which a bit more of Grbl-like responses and error codes (so it can easily be used with some of the popular free GUI’s available). I thought it’d be nice to use your improved code as a starting point instead of Makeblock’s original GCodeParser.)

#41

It might be noise in the limit switches. I believe that code is the most current, but I usually run with the limit switches removed, mostly because the stepper wires run alongside the limit wires, and the noise kept giving false triggers.

#42

check out my new thread…

#43

So, I’m late® to the game here, having just recently been given one of the xyplotter’s with the 0.5w laser… I compiled the code and have been trying to get something to move. Sadly, no luck.

I don’t have limit switches installed currently, but see in the thread that Jason doesn’t always have them either…

I’d like a bit of help calibrating on how to troubleshoot this. I believe the wiring is correct, but I’ve only had it a day, so I’m not entirely sure.

steppers seem to be powered on (they resist movement) but the G code commands sent through the makeblock gcode sending program don’t seem to do much (though they do get responses that indicate things are working, just no stepper movement).

thoughts?

thanks
-John

#44

Hi,
I am planning to make a dot peen marker for metal engraving. I am to control it using ardiuno. I need the source code to control the marker head. The text that is entered through the keyboard have to engraved using the markers head. The characters to be engraved include alphabets,numerals and alphanumerics. The characters must be able to be sized, rotated or tilted. If any one can help me with the code and making,it would be really helpful.

#45

Hi Jason,

I was wondering, does your firmware update for the Orion speed up G01 linear operations? I’m having a lot of trouble getting my gcode which contains almost all G01 commands to run fast and smoothly with the default GCode Parser arduino example. Any help you may have is much appreciated! Thanks!

#46

G0 and G1 are both dramatically faster to process, if that’s what you’re asking. G0 commands use acceleration / deceleration so they can hit a much higher max speed. G​1 commands don’t accelerate, so you have to be careful not to exceed the limits of the machine, but the processing overhead is about 1/10 what the original code was.

Is that what you’re asking? (Is there a G01 operation? My code speeds up G0, G1, G2, and G3 operations)

#47

oh wow, ok that’s amazing! Yes, sorry, I meant G1. I’m writing an application that streams point data to the xyplotter, and it’s simpler to write the commands as G0 and G1, but so far they have been very slow compared to G2 and G3’s.

#48

There’s a limit to how fast / smooth the Arduino can process this stuff. If the moves are really short the turn-around time going to the host PC for the next command starts to overtake the time spent actually executing the move, and you end up with “stutter”. Watch this video starting from about 1:27: https://www.youtube.com/watch?v=tsDqdIzdFCw

It might be possible to fix with an interrupt service to update the serial data, but I don’t know enough about the Arduino to do it. I just ported the code to the Parallax Propeller chip - it handles the I/O in Parallel, so the turnaround time is a lot shorter - I’m basically always getting the next command while processing the current one, instead of processing, then getting. If a move is short enough I’ll still get stutter, but it’s considerably less.

#49

Thanks again for your help and videos. I updated the firmware on the Orion with your changes and while it definitely improved the speed a bit, I basically came to the same conclusion as you regarding the limitations of the Orion controller. I replaced the controller with a tinyG controller and now my plotter runs about the same smoothness as yours with the Parallax Propeller. Kinda a shame I had to move away from the Orion, but in case others are having the same issues take note that there are other modification options out there.

#50

Thanks for all your hard work on this. Can you also give a link to you Propeller port also are your sources for the makeblock improvements published on github or anywhere like that? Do you think the makeblock people would be receptive to a pull request?

#51

Hi! Any idea why this code run great on BenBox but makes mDraw freeze?

Regards / Jimmy

#52

The problem with some Aurdino-based 3D printers was that the USB software in them was slow.
They ran much faster reading data from a SD-memory card instead of the host through USB…

#53

I’d be surprised if this ran on either BenBox or mDraw - I was under the impression that each of those had different firmware requirements. This code is JUST for using with the GCode sender, not BenBox or mDraw.

#54

It’s unlikely that it’s the USB software, but the rate of the transmission - They’re setting the port to be 115,200 baud, which maxes out at about 11kb/sec, and that’s if you’re doing it right, which they aren’t. They only pay attention to the serial port when they’re not processing a command, which is much more likely to be the limiting factor.

11kb/second should be plenty of data even for relatively complex moves if you overlap the communication with the processing itself, but they don’t.

#55

Hello,

I’ve just tried making the same upgrade as described in the OP, with the NUBM44 laser diode.

I already had the XY plotter working fine with the 500 mW stock laser.

I successfully removed the resistor and capacitor from the new laser’s driver board and successfully tested the laser with a 12V direct power source (and 12V from the same source through a 10K resistor to the driver board’s enable pad). Everything worked fine - the laser is indeed powerful as it would burn wood even without being focused.

I then hooked the new laser up to the Orion board. The original laser was connected to the M2 connector, so I connected the enable wire to the new laser to the same output (i.e. the + pin of the M2) through a 10K resistor and the power to the same 12V power supply as the Orion board.

Unfortunately, seconds after I switched it on and ran a test program that would switch the laser on a low intensity (8 out of the possible 255), the new driver board simply caught fire (without switching on the laser, not even a flash) - more specifically, the black 8-pin chip on one side of it. I obviously removed power immediately, but the chip is partially melted now. The same test program has been used numerous times before and works fine with the stock laser.

The Orion board still has the stock Benbox firmware, which also works fine with the stock laser. I have made many engravings with that without issue so I thought I would get the new laser working with that before complicating things with a different firmware.

The only thing I can think of I’ve done differently than what is described in the original instructions in this thread is that I connected it to the M2 output instead of M1 - I did that simply because that’s where the original laser was connected, so I assumed it was just a difference in versions of the XY plotter or something like that when the OP mentioned M1.

Now I wonder if there is some difference between the outputs? For example, does the M2 output way more current than M1 or something? I always assumed that the Benbox firmware is made to work only with the M2 output, I never even considered that it would provide something else on M1.

I’m really hoping it’s just me who screwed something up that hopefully only cost me a driver board (I ordered a new one, but it’ll be a while before it gets here - in the meantime I’m just hoping the laser diode itself is fine). Before I start playing with the new driver, I’d just like to know if there is any known difference between M1 and M2? I haven’t been able to find anything on the forums.

Thanks for any help and kind regards,

Oxgernon

#56

There shouldn’t be a difference between the M1 and M2 output signals - I haven’t seen any reason you wouldn’t be able to use M2 instead of M1 in either the code or the hardware.

My guess would be that you either didn’t set the motor direction correctly, or just connected to the wrong terminal, and sent a negative polarity 12V signal to the laser driver. I doubt the laser driver has any sort of reverse polarity protection on those pads, and the motor outputs are capable of outputting either +12v or -12v depending on the motor direction and connection. Sending -12v to the driver would probably short something, which would explain the release of magic smoke.

I put diodes on the connectors for mine to make sure the laser driver couldn’t get a reversed signal, and verified the polarity of everything with a meter before connecting it.