Upgraded XY plotter - 6W laser

#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.

#57

Ah, you may be right about the wrong terminal. I didnā€™t know that it could switch the polarity; I just assumed that the side that says + in the writing on the Orion board would be the positive side, but if it can be switched around thereā€™s obviously no guarantee of that. Iā€™ll make sure to check with a meter before connecting the next driver board :slight_smile:

Iā€™ve also ordered some rectifier diodes to be a little safer in the future, but it will take a while before they get here as well. Oh well, better try to be patient for once :slight_smile:

Out of curiosity, which current setting do you use on your driver? The first one I had (that caught fire) was set at 4.5A, which is the maximum DTR recommends. Iā€™ve read many places that there are overheating issues with this board, so the new one I ordered is only a 4A, just to play it slightly safer. Iā€™m also going to heatsink the driver itself and place it under a fan.

Thank you for your help and time :slight_smile:

Kind regards,

Oxgernon

#58

Iā€™m pretty sure I got it at full power (5.5A). I put heatsinks on the driver with thermal epoxy, put the LED module in a round aluminum heatsink with fins, then mounted a fairly strong fan inside a 3D printed shroud around the whole works, and even then I had to be careful not to use the laser at full power for more than a minute or so at a time or the driver shutoff would kick in. I didnā€™t have the driver placed very well in the airflow, and the heatsink on it was smaller than Iā€™d like, so I still think itā€™s possible to run it at full power for longer, possibly indefinitely, if you cool it properly. Itā€™s just a variable resistor, so you can change it after youā€™ve run it for a while. If you PWM the 5A driver at 50%, youā€™re only pulling 2.5A, so cooling isnā€™t an issue.

If itā€™s any consolation, I fried a diode AND a driver (at different times), so I feel your pain. Itā€™s an expensive mistake, but it does teach one to be more patient, or so I hear. :slight_smile:

Good luck - let me know how it goes.

#59

The new driver board arrived and after removing the resistor and capacitor and attaching it to the laser, I was pleased to see that the laser diode itself was not damaged by my previous mistake as it lit up and scorched a strategically placed piece of wood immediately when I applied power to the enable pad :slight_smile:

I canā€™t see any way to adjust the current of the driver board, though - the one I have is an X-Drive bought from DTR. Looking at the pictures on the site, it seems that some of them have what looks like a variable resistor that can be adjusted with a screwdriver, but not all of them and mine doesnā€™t. Oh well, 4A should still result in 6.2 W output according to DTRā€™s measurements, so still a massive upgrade over the 500 mW stock laser. I suppose Iā€™m also less likely to hit the thermal shutoff if itā€™s hard capped at 4A, which makes it a more robust albeit somewhat less powerful system.

I havenā€™t attached it to the Orion yet though; Iā€™ll wait for the rectifier diodes to arrive and will also make sure to confirm which terminal is positive before attempting that again :wink:

#60

Your firmware is nothing short of night and day better than stock. Thank-you! I hope you donā€™t mind but Iā€™ve made some very small modifications of my own and published it on github as the JasonDorie branch of my project.

The differences are very minor:

  1. Made the pin layout match my machine.
  2. Removed all z axis stuff from the dda_move in favour of a simple servo.write in process_string.
  3. Recalibrated the steps/mm for my setup.
  4. Since I removed references to MeDCMotor (no laser for me at least until bionic eyes are as good as the real thing) and so was able to remove the Makeblock.h include. This cuts compile time significantly.

I also noticed that it doesnā€™t seem to respect G92X0Y0Z0 (reset zero) but thatā€™s no big deal as I just turn off the steppers and move it to my desired 0 by hand now.

Thanks again and I hope you donā€™t mind that I published it on github.