BG221518125 Nope. For an acceptable carbon fiber cut you'll need a multi-wavelength laser system. The Internet says a combined beam from a 1.06 micron fiber laser and a 10.6 micron CO2 could do it.

BG221518125 support@atomstack3d.com

BG221518125 8 bit, but note that the bit width of a CPU does not change how math or physics works. An 8-bit CPU will spend 90% of its life waiting for the motors to move the laser where it needs to be and a 32-bit CPU will spend 98% of its life waiting for the motors to move the laser where it needs to be. The most useful practical difference is that a 32bit CPU will have more available RAM for its serial buffer which in turn helps maintain a constant data stream when you connect it to a very, very old desktop PC running the laser software. On the other hand, the ability to set the laser power S0-S1000 (in 0.1% increments, usually advertised for 32bit boards) or S0-S255 (in 0.4% increments, with 8bit boards) would be the least useful practical difference. That said: yes, absolutely, a 32bit board has greater future potential but the firmware that turns that potential into something practical has not arrived yet.

BG221518125 It speaks standard “g-code” so it’s compatible with all OSs. I’m using it with LightBurn on a Mac.

BG221518125 The CNC mill dust on that picture is a dead giveaway it's just photoshopped. The one with the three smiling white collar folks is also highly dubious as they appear to have plugged their power cable into a ballpoint pen and forgot to connect the thing to a computer. The focus of their laser will also be horrible with the engraving head that high. On a more serious note: a speed of 700-800mm per min and 3-4% laser power gets me OK 20-25mil SOIC-level PCB results with dry photoresist film out of the box. For finer detail you will have to get your fingers dirty as the beam shape of an average solid state laser module is never a perfect dot. Mine projects a 0.1x0.3mm rectangle which physically limits designs to ~12mil traces in one of the dimensions and you will only achieve that definition if you can either write your own image preprocessor to separate X and Y moves (different kerf) or can tell your laser software it's drawing with a bar and not a point. Hardware patches like swapping optics, beamforming lenses, or pinhole covers to mask out that unwanted 0.1x0.2mm of extra light might also work (but are messy and fiddly).

BG221518125 I don't have an MKS-TFT to test but the relevant 8-pin AUX-1 (5V, RS232) connector is there and should work. But even if the connector wasn't there: the MKS-TFT outputs standard g-code so it's expected to work with pretty much any board as long you connect the TX, RX, 5V, and GND pins to where they belong.

BG221518125 ATMEGA328P (8bit)

BG221518125 The frame does not have any pre-drilled holes for limit switches so it's left to the end user to figure out which particular switch they prefer (if any) and how they want to attach it (you'll have to drill metal). Also see github.com/gnea/grbl/wiki/Wiring-Limit-Switches - the board already has the pull up resistors and the capacitors.

BG221518125 $I: [VER:1.1f.20170801:] [OPT:VI,15,128] The board is an MKS DLC clone.

BG221518125 If a new serial port does not automatically appear in your OS after you plug it in: install the CH340G USB-to-serial driver.

BG221518125 Yes, the control board is an MKS DLC clone. The sockets for the limit switches are already on the board but you'll have to run your own cables and then tell GRBL about your switches. Both MKS DLC and GRBL have their own GitHub pages with further details, schematics, and wiring diagrams. If you'd also like to enable the homing function: you'll also have to recompile and flash GRBL with the Z axis disabled (more on the GRBL FAQ page).