Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add laser support #113

Closed
wants to merge 117 commits into from
Closed

Add laser support #113

wants to merge 117 commits into from

Conversation

nextime
Copy link
Contributor

@nextime nextime commented Apr 2, 2016

This pull request add laser support for machines like the K40 chinese laser cutter modified to use a RAMPS 1.4 controller board.

It fully support both vectorial and rasterized images for both cut and engrave, and it's fully compatible with https://github.com/openhardwarecoza/LaserWeb, pronterface and other gcode-host software for laser cutters.

It also fully compatible and support https://github.com/TurnkeyTyranny/laser-gcode-exporter-inkscape-plugin, an inkscape plugin to produce gcode for laser machines.

The patch is a port of the modifications done by TurnkeyTyranny on an old marlin firmware here: https://github.com/TurnkeyTyranny/buildlog-lasercutter-marlin, updated and adapted for MarlinKimbra.

@mkeyno
Copy link

mkeyno commented Apr 3, 2016

hi @MagoKimbra , have you check the @HakanBastedt thread , ? we intend to adapt the laser or plasma THC ready module in Marlin, I really appreciated to have your comments on those notes

@nextime
Copy link
Contributor Author

nextime commented Apr 3, 2016

@mkeyno just take care that i'm working on it, it's working enough well right now, but there is an issue for the water cooling PWM that will make me move probably the LASER_FIRING_PIN from D5 to another pin on RAMPS, so, be carefull if you want to try it

@nextime
Copy link
Contributor Author

nextime commented Apr 3, 2016

As i'm adding also support for water cooler on the laser patch , i'm thinking about the Mcode to set the PID for it.

Actually we have 2 Mcodes for setting PIDs: M301 for extruders, and M304 for bed.

For the laser cooler i have many options:

  • Use M301, and just use it as if where the first extruder (E0)
  • Use M301, but use the last available extruder (E3 on MarlinKimbra) as is the less probable extruder used in configurations of machines that can both 3dprint and laser cut/engrave
  • Use M301, add an additional extruder setting (also in eeprom store), (E4 on MarlinKimbra), so, it doesn't override any possible extruder in case of machines that can both 3dprint and laser cut/engrave
  • Use M304, on laser machines we don't have heatbed, so, just use it.
  • Use M304, modify it as it can accept multiple PID settings, like extruders does in M301 with "E" selector. Don't know which selector to add too, using "E" seems stupid, has to be choosed something that make sense both for "bed" and "water cooler" or "laser".
  • Use another Mcode not yet listed. I can't find any Mcode "standardized" for this use, and i don't like to add Mcodes without large consent.

I asked the very same question also in this issue on Marlin firmware, so, we can find a large consent on this for future compatibility with possible Marlin laser support patches: MarlinFirmware/Marlin#3208 (comment)

@mkeyno maybe you can be interested too.

Has anyone suggestions about that?

@MetalMusings
Copy link

Hello, good that TurnkeyTyranny's code finds a home.

I have ported it myself, and I have some comments regarding the original code

  1. The mapping between 255 to 100 in planner.cpp is not optimal, going from 255 greyscale range is now reduced to 100 grayscales. Only purpose is to fit laser_fire which goes from 0-100. Better to keep 0-255 range and make a laser_fire_byte() that takes 0-255. Only for the rastering.
  2. There is a small issue with accumulated errors in block->step_event_count due to integer arithmetic with block->steps_l. One way to reduce it is to increase block->steps_l by factor 1000 to keep its precision. Of course the 1000 needs to be considered in the few places block->steps_l is used.
  3. The timer code in laser.cpp is fine. But there is a rare issue with the 255 range of greyscales when engraving at low intensity, say at S10 = 10% the range is only 25 grayscales. Requires a bit of work to improve, maybe not worthwhile on Mega.
  4. People will wonder why the laser fires when navigating X and Y in repetier-host. G0/G1 issue. I don't know how to solve it but it will be a nuisance. M649 S0.
  5. I have added code to switch off the laser when the step is finished. Not sure if it is needed.

Regarding the cooler temperature. On my diode laser there is a fan going all the time the power is on, can't control it. On the Co2 the water pump is going all the time and the cooling fan is operated with a switch. For the Co2 I would like to see a) monitoring of waterflow to make sure there is water flowing all the time, b) temperature monitoring of the tube itself if this is at all possible due to the high voltage noise or on the exiting water tube and c) as a convenience to keep the noise level down from the cooling fan I could consider closed loop operation of the cooling fan.

On top of that there is a need to operate the air assist (pneumatic air valve), and have switches to detect open lid/case (important for Co2), perhaps some laser pulsing dedicated for mirror alignment, table height adjustments with perhaps four individual motors, static autofocus, dynamic autofocus. A much better operator panel is needed and sound feedback (piezo beeper?) is needed.
Many concepts can be re-used from the 3D printing world, and many are new. I tend to think that a range of G/M-codes is used specifically for lasering is the right way, at least for the Co2 lasers that need a bit more support systems around. G7 is already unique.

For the Due it is the same work, just the pwm part is different, you can check my code at the end of HAL.cpp it comes from analogWrite() code. Don't use the pwm generator, it will conflict with analogWrite on pin 6-9 and it isn't possible to separate their use even of there seems to be one clock available.

@nextime
Copy link
Contributor Author

nextime commented Apr 3, 2016

Hello @HakanBastedt, thanks for your suggestions:

1- i agree, make sense to apply your suggestion, i will do that
2- i will take care of this too
3- as i'm using mega, it's worthwhile to fix it for me :)
4- this is a non-issue in my opinion: using repetier-host is sub-optimal for lasers, and anyway it depends on what produces the gcode. I will focus on the open source free software gcode producer softwares and apparently they are more than anything else based on turnkey tiranny that uses g0/g1 as we are using here.
5- it should'n be needed, but i remember i saw someone doing the same somewhere, i will investigate if make sense to add it too.

For the temperature: my setup ( on a K40 co2 modified machine ) i have, other than the pump as you have:

  • flow sensor
  • peltier cell based refrigerator
  • temperature sensor
  • air assisted
  • the open lid/case swirch
    I'm adding those things, using the temperature sensor to build a PID with the peltier. Optionally you can just use the "pheripherals" support to manage fan in the diode laser, pump in the co2, and the air assist compressor.

I will soon add also Z axis support and i'm investigating also auto-focusing tools.

@mkeyno
Copy link

mkeyno commented Apr 3, 2016

hi @nextime franco, also as well as @HakanBastedt I suggest to move to ARM core board such as Due , I built the 100watt CNC laser machine with capability of cutting thin sheet metal but when I compare it with chines cnc machine , it is not reliable or fast as those , I bind the laser fire pin to the peripheral auxiliary unite such air pressure & cooling water , but right now focusing to add ready-to-use Tools Height Control (THC) module in Marlin
I discuss it with couple of cool guys , on what would be best solution to initialize and pre set the cutting tools and dynamically Control Height during the printing ,
I really appreciated if you could check the suggestion on this thread and have your comments as well

@nextime
Copy link
Contributor Author

nextime commented Apr 3, 2016

@mkeyno regarding the "arm is faster", except for border line use i really think is a non issue at all, with my old good 8 bit mega and ramps i'm able to raster images very fast on my chinese machine, and it's fully reliable.

I found that 100% of the "sloweness" issues with those machines using mega2560 by many people was not the MCU speed, but the serial buffer size instead: just by enlarge the buffer to 256 byte instead of the default 64 bytes has solved any speed issue to me, and i'm able to raster images at more than 2000mm/s without losing a bit on my mega based ramps controller.

Anyway, in any case, of course, arm support is a "must have", no matter if i will use personally or not :)

For the focusing, i tend to be an "experimental guy", i will try different solutions, and then, having numbers on which to discuss, we, as anyone want to contribute/is interested, will choose the best one :)

@mkeyno
Copy link

mkeyno commented Apr 3, 2016

your probably right dear @nextime but I'm referring to pulse rate compare to industrial controller whereas all of them use ARM or DSP core and actually in my new 180 watt laser I've plan use the AC stepper motor and driver which is need much higher pulse rate for optimum performance , I have bad experience with tinny driver such as DRv8822 hence move to reliable industrial drive for any CNC

@nextime
Copy link
Contributor Author

nextime commented Apr 3, 2016

@mkeyno your arguments make sense. As usual, different configurations needs different things, so, the best way is to implement both :)

@MetalMusings
Copy link

The only difference in code between Mega and Due is the PWM, and that is already taken care of. It is not really a choice between one or the other, it is a matter of having two codes in sync for laser, just like any other functionality.
Franco, you must mean 2000 mm/min, right? With the G7 command I can do 3000 mm/min on the Mega, the Due can do over 30000 mm/min. Perhaps you already have seen my video https://www.youtube.com/watch?v=AaAx0MbhCxo In some cases the speed from the Due is really appreciated.
One other way to increase speed is to remove the LCD. During LCD update, the stepper runs out of prepared blocks and the stepper stops, waiting for work to do.

@nextime
Copy link
Contributor Author

nextime commented Jun 2, 2016

Laser support has been merged

@nextime nextime closed this Jun 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants