LMN Marlin is driving me nuts!

[ajf]

Ugh.  I'm having a lot of trouble getting Marlin to perform.  Seems to work okay when running tests on cardboard with laser intensity at 10%.  However, when I try to cut the same part with intensity at 100%, it will stop during the run and display "waiting for user..." on the LCD.  When I click the encoder, often times it will start doing a traversal move with the laser on.

I've ordered up an Azteeg X5 from Panucatt.com, hoping that Smoothieware will perform better.

[Andy Carter]

I sometimes get the waiting for user message on my delta printer, but only if I have a host program connected.

[ajf]

That's interesting, I've never had it on my deltas (currently running three with Johann's fork.) I never have a host connected directly though, one does have a raspberryPi with Octoprint, the others always run from SD.  The laser also always runs from SD.

[Jeremy G]

Let me know how that x5 works out. It's a little expensive for my budget right now but maybe next term I will try it out if it works well.

[Tim Schmidt]

Hey guys,

I did the firmware modifications for the LMN laser.  Let me know if you have questions or issues.

What LCD are you using?  We've done all our testing with the RepRap Discount Full Graphic Smart LCD, and made some modifications to that code to work with the laser functions.  I pulled a patch from someone adding some support for the non-graphic model, but I don't have hardware to test it, and am unsure it works well at the moment.

--tim
timsc...@gmail.com

[Jeremy G]

Do you mean you updated the marlin fw on the lmn repo?

I am using a full graphic lcd. I just let my friend borrow Mt non graphic or I would tetest it out for ya.

You are talying about the ramps fw right or the smoothieboard?

I have my unit almost all setup and really don't want to change micro's but I will if I absolutely have to..

[Jeremy G]

... sorry about the typos, my phone seems to be drunk...

[Tim Schmidt]

On Fri, Nov 21, 2014 at 9:44 PM, Jeremy G
<jeremy.goss@weistekengineering.com> wrote:
> Do you mean you updated the marlin fw on the lmn repo?

I started the LMN laser project (thanks Bart and Buildlog!), and am
the principle author of the laser-related portions of the firmware
here: https://github.com/lansing-makers-network/buildlog-lasercutter-marlin
 The Marlin folks did most of the work, I just added the laser bits.
:)

> I am using a full graphic lcd. I just let my friend borrow Mt non graphic or I would tetest it out for ya.

Interesting.  Are you "printing" via USB, or from an SD card?  If
you're using USB, can you try some prints from SD and see if that
fixes it?

> You are talying about the ramps fw right or the smoothieboard?

Ramps.

> I have my unit almost all setup and really don't want to change micro's but I will if I absolutely have to.

No worries, whatever works!  If you're willing to work through some
tests, we might find a fix (or at least a cause).  And if we find a
bug, I'll put some work into fixing it.

--tim

[Jeremy G]

I have processed a dry run via sd card and the machine seemed to work just fine. I haven't had a chance yet to actually fire the laser and cut as it was completely dead when I got the laser. Aside from firing the laser all is good.

I would be happy to help you test the fw to find bugs/make it better. Just let me know what type of tests you want and when I get it running "soon I hope" I will give them a go.

Also Ajf has modified the inkscape plugin I can't remember what was wrong with it but it was not generating gcode properly that marlin liked.

[Jeremy G]

Oh and thank you for all of your hard work :)

[Tim Schmidt]

I've updated the documentation on the LMN wiki to point at ajf's updated plugin.  I'm going to try that out next time I fire up the laser!  I'll get the git readme updated tonight.

Testing: if your machine is behaving in a way that doesn't seem to match the Marlin documentation, and doesn't seem to match the documentation here: http://wiki.lansingmakersnetwork.org/equipment/buildlog_laser_cutter post about it.  We've been using LMN's machine for more than a year now, and I've been supporting the firmware on the mUVe 1, AMRI's OpenSLS, and a few other machines.  So we've run into a few common issues.  Off the top of my head:

- Non-contact induced voltages in metallic objects near the laser tube can top 600v.  Ground everything to everything.  Twice.
- Serial communications with laser cutters are very susceptible to interference caused by the laser's high-voltage power.  SD printing is FAR more reliable.
- Aligning and focusing a laser is hard.  We use aluminum plates w/ heat-sensitive receipt paper resting on the mirror assemblies, and an alignment gcode file that issues quick low-power laser pulses while traversing a single axis.  This makes it pretty easy to visualize the linear path of the invisible laser in 3D space - vital for adjusting it's path.
- Clean the aperture of the laser tube every once in a while.

In general, continuous, pulsed, and raster mode should work.  There's an open bug in pulsed mode that causes corruption in axis location on second print, but the first print always seems to work, and a reset fixes it.  Other than that, if something doesn't work, there's a good chance it isn't wired or configured quite right  :)  That said, I'm sure there are bugs to find still - especially in areas like the LCD code.

It's very exciting to see folks hacking their lasers!

--tim

[Jeremy G]

Sounds great! I think I need to realign the laser maybe.. it was only ever used for 30 mins before the micro blew up and it sat for over a year until I recived it.

I just got the liquid cooling system all setup. Now I just need to finish wiring a few things and general cleanup and it should be ready to cut. Most likely after finals week.

Ya seems like they did a piss poor job of grounding the unit. So far everything is grounded but i will double check and most likely add a few more chassis grounds. Oh and I need to print dogp's laser guide.

Quick question if I hook up the interlock to a hatch switch so the laser does not fire when the lid is closed, if the lid is opened; after closing it will the laser resume cutting?

[Tim Schmidt]

On Fri, Nov 21, 2014 at 11:45 PM, Jeremy G
<jeremy.goss@weistekengineering.com> wrote:
> Quick question if I hook up the interlock to a hatch switch so the laser does not fire when the lid is closed, if the lid is opened; after closing it will the laser resume cutting?

At LMN, we just use the hardware interlock (which is labeled "WP" on
our laser power supply).  It's a normally-closed circuit, and breaking
it turns the laser off.  Reconnecting it turns the laser back on.

Marlin supports a software Emergency Stop pin, which is defined in
pins.h.  We don't use it, so I'm not sure if you have to pull it low
or high to trigger it, but if you do, Marlin should shut everything
down, kill the laser, and require an M999, at least, before
restarting.

--tim

[ajf]

Hi Tim,

First, I'd like to join Jeremy in thanking you for all your hard work!  As a Mac guy, it's what got my K40 useable when I first got it... (with much thanks to Dan's original buildlog.)

Second, thanks for the link to my fork of the plugin.  However, please note that the current default branch is for Smoothieware and will not work with LMN Marlin.  The last Marlin version is master, but not default.

Also, though I'm currently running my K40 with Smoothie, I'll be happy to support the Marlin build as best as I can both with the plugin and firmware. Smoothieware is quite nice, though still very young, but the boards are quite a bit more expensive than the Marlin compatible stuff that's out there.

Regards,

aj

[Tim Schmidt]

Hi aj,

Thanks for the kind words.  I updated the plugin link on LMN's wiki.

Good to see that Smoothie's using G0/G1.  I should probably get in touch with those guys to talk about standardizing the rest of the functionality.  We shouldn't use G7 for raster forever.  Do you know who I should get in touch with to discuss that sort of thing?  Maybe they've got some better ideas for gcode parameters too, who knows?  :)  This is the first I've really looked at Smoothie's firmware - though I've poked around in all the AVR-related firmwares.  I really like their documentation, and the plugin model is sound.  I like it a lot.

I've been working on something that looks similar, but it's written in very weird C89, whilst reading the datasheet(s), so as to run reasonably well on AVRs with as little as 2Kb ram - like the 328p or much more useful 324p.  here: https://github.com/timschmidt/bailingwire  For just that reason - cost.  I'm also attempting to support multiple target boards, like the AVR firmwares.  But I'm only able to hack on it part time at the moment, so I've got a long way to go to catch up to Smoothie.

--tim

[ajf]

Hi Tim,

Re the plugin:  I had set the min_arc_radius default really high to force G1 because G2/3 moves were causing issues for me on Marlin.  Have now reverted back to the original.  Also, using G28 for homing since my machine doesn't have Z, but that might be problematic for you guys.  Happy to make any changes you think appropriate.

I think Arthur Wolf, Mark Cooper and Jim Morris are the people to talk to, they are Arthur, Logxen and wolfmanjm on the #smoothieware irc channel which seems the best way to reach them.  Could also try Dev list

Bailingwire looks cool, nice work.

[Andy Carter]

Hi All

I've recently put a RAMPS 1.4 into a K40 laser cutter. I'm using the LMN Marlin variant. It mainly works o.k but doesn't seem to recognise the G96 command to set the overall spindle (laser intensity) speed. I also had a problem in that G3 didn't fire the laser. I got around that by copying the laser control code from the G1 section of Marlin_Main.cpp to the G3 section. Everything, apart from G96, now seems to work fine with gcode output from the LMN Inkscape plugin. Thanks for all the hard work creating the code in the first place.

Regards

Andy

[ajf]

Andy,

The reason G2/G3 didn't fire the laser is because the inkscape plugin wasn't setting the intensity with the M3 command.  LMN is now linking to my fork of the plugin.  In addition to setting the intensity on M3, it also allows you to set separate traversal and cut feedrates.

regards,

aj