<p><em><strong>It would seem that the printer control board doesn't use a CH340 (see bottom of this answer) and therefore this answer should be ignored.</strong></em></p>
<hr />
<h3>CH340 and OS X incompatibility</h3>
<p>The reason your Mac might not see the printers <em>could</em> be down to the USB interface <em><strong>on the printer controller board</strong></em>.</p>
<p>If it is implemented by a CH340 (which is probably is, in order to reduce manufacturing costs) then, historically, MacBooks have a problem with the drivers for this device and its derivatives. That is to say, the OS has a problem - more specifically the device drivers used by the OS X kernel - as opposed to the hardware. There are a number of posts dealing with this problem, it is common on Arduino clones too, see <a href="https://arduino.stackexchange.com/search?q=mac+ch340">here</a>.</p>
<p>The third party drivers for the CH340(G) written for OS X are often poorly written and/or have shoddy documentation - although this opinion may be hotly debated, and I have no wish to expand upon.</p>
<p>If the USB interface, on the printer controller board, is implemented with an FTDI or a ATmega 16U2 then it will work fine. Unfortunately the solution is probably not to use the Mac and stick with the Lenovos (i.e. PC clone).</p>
<p>See the extensive answers to <a href="https://3dprinting.stackexchange.com/q/6221/4762">Can&#39;t connect Cura to my Anet A8 on OSX 10.11.6</a></p>
<hr />
<p>As an aside, I gave up trying to buy/use cheap Arduino clones with a CH340(G), on a Mac long along, as it just wasn't worth the effort in trying to get the Mac to see it. I now ensure that either:</p>
<ul>
<li>I purchase a slightly more expensive Arduino which uses a 16U2 (the more pricey FTDI chip is more rarely used on boards these days, but can still be found). Obviously, you don't have that sort of luxury when selecting a 3D printer.</li>
<li>I will use a PC instead, if the board has a CH340(G), or similar.</li>
</ul>
<h3>One possible solution</h3>
<p>However, having said all of that, this issue <strong>may</strong> have been resolved in newer versions of OS X (post Mountain Lion, or thereabouts). This <em>might</em> provide a solution, <a href="https://arduino.stackexchange.com/q/57126/6936">Connect to ch340 on MacOS Mojave</a></p>
<blockquote>
<p>remove all old drivers:</p>
<pre><code>sudo rm -rf /Library/Extensions/usbserial.kext
sudo rm -rf /System/Library/Extensions/usb.kext
</code></pre>
<p>Now reboot the computer.</p>
<p>And then (very important, because it took me 10 cables to find the
right one) use a <strong>fully connected</strong> cable ;-)</p>
<p>Now I have these ports:</p>
<pre><code>/dev/cu.wchusbserial1410
/dev/cu.usbserial-1410
</code></pre>
</blockquote>
<p><strong>Important note</strong>: Clearly, deleting kernel drivers (also known as <em>kernel extensions</em>, <code>.kext</code>) shouldn't be taken lightly. If you feel uncomfortable doing it, or don't know how to revert the process, by using a saved backup of the drivers, then <em><strong>please don't attempt this</strong></em>.</p>
<p>For completeness:</p>
<ul>
<li><p>To back up the <code>kext</code> (<em><strong>before</strong></em> deleting it as shown above):</p>
<pre><code>sudo cp /Library/Extensions/usbserial.kext /Library/Extensions/usbserial.kext.bak
sudo cp /System/Library/Extensions/usb.kext /System/Library/Extensions/usb.kext.bak
</code></pre>
</li>
<li><p>To restore the <code>kext</code> (<em><strong>after</strong></em> having deleted the kernel extension and then finding that it made no difference whatsoever):</p>
<pre><code>sudo mv /Library/Extensions/usbserial.kext.bak /Library/Extensions/usbserial.kext
sudo mv /System/Library/Extensions/usb.kext.bak /System/Library/Extensions/usb.kext
</code></pre>
</li>
</ul>
<hr />
<p>Alternatively, instead of <em>deleting</em> the kernel drivers, you could just <em>rename</em> them to hide them, by adding <code>.bak</code> to the filename, like so</p>
<pre><code>sudo mv /Library/Extensions/usbserial.kext /Library/Extensions/usbserial.kext.bak
sudo mv /System/Library/Extensions/usb.kext /System/Library/Extensions/usb.kext.bak
</code></pre>
<p>Then reboot. Check the printer connects or not. If not, then just <em>restore</em> them using the same commands shown above - so you just end up removing the additional <code>.bak</code> from the filename.</p>
<hr />
<p>With respect to the quoted answer, I'm not entirely sure what is meant by a <strong>fully connected</strong> cable... There <em>is</em> a well-known issue that some USB <em><strong>charging</strong></em> cables - that look like normal USB cables - have only the power lines connected, and omit the data lines (again for cheapness), and it can be difficult to tell the two apart (usually by thickness, the thicker cables have more lines connected). Obviously, if the data lines are missing then the cable will not transfer data.</p>
<p><em>However</em>, this usually applies only to cables with mini, or micro USB connectors, and usually doesn't apply to standard peripheral cables such as a USB-A to USB-B cable:</p>
<p><a href="https://i.sstatic.net/11mVl.png" rel="nofollow noreferrer" title="USB connectors"><img src="https://i.sstatic.net/11mVl.png" alt="USB connectors" title="USB connectors" /></a></p>
<p>So, this issue should only arise for micro/mini USB connectors... it will depend upon your connector type.</p>
<hr />
<p>We can't recommend particular makes or models of USB hubs as that is a shopping question, which is <a href="https://3dprinting.stackexchange.com/help/on-topic">off-topic</a>.</p>
<hr />
<h3>Analysis on the printer board</h3>
<p>Makerbot appear to use the Mightyboard for the Replicator. INterestingly from the following two photos it would appear that a CH340(G) is <em><strong>not</strong></em> used, and the IC is in fact a 16U2.</p>
<p>Here is a photo of the board (image from <a href="https://www.fargo3dprinting.com/products/makerbot-replicator-2-2x-rev-h-mightyboard-oem/" rel="nofollow noreferrer">MakerBot Replicator 2/2X Rev H Mightyboard – Official, OEM Board w/ 4 BotSteps</a>):</p>
<p><a href="https://i.sstatic.net/AcMoE.jpg" rel="nofollow noreferrer" title="Photo of Mightboard"><img src="https://i.sstatic.net/AcMoE.jpg" alt="Photo of Mightboard" title="Photo of Mightboard" /></a></p>
<p>The IC closest to the USB-B port would appear to be a 16U2:</p>
<ul>
<li>Its form is square like a 16U2 and not elongated like a CH340G</li>
<li>It would appear to have an Atmel logo printed upon it.</li>
</ul>
<p>This image (from <a href="https://www.teknistore.com/en/3d-printer-module-board/19403-mightyboard-motherboard-3d-printer-dashboard.html?mobile_theme_ok" rel="nofollow noreferrer">MightyBoard Motherboard 3D Printer Dashboard</a>), also suggests the a 16U2 is used:</p>
<p><a href="https://i.sstatic.net/DoO9c.jpg" rel="nofollow noreferrer" title="Annotated photo of MightBoard"><img src="https://i.sstatic.net/DoO9c.jpg" alt="Annotated photo of MightBoard" title="Annotated photo of MightBoard" /></a></p>
<p>All of which means that, if your printer(s) have this board, then your Mac <em>should</em> indeed connect to the printer.</p>

CC BY-SA 4.0
2021-11-15T02:30:06.373Z
OK, I am not one who understand much of the terminology you just used. But when you say a fully-connected cable do you mean one that does not need an adapter?
Jesse
CC BY-SA 4.0
2021-11-15T02:35:07.770Z
To put it bluntly, could you translate your post to non-techie?
Jesse
CC BY-SA 4.0
2021-11-15T02:37:32.233Z
I'm not entirely sure myself, as that is quoted from the linked answer. However, there is a well-known issue that some USB ***charging*** cables - that look like normal USB cables - have only the power lines connected, and omit the data lines (again for cheapness), and it can be difficult to tell the two apart (usually by thickness, the thicker cables have more lines connected). Obviously, if the data lines are missing then the cable will not transfer data.
Greenonline
CC BY-SA 4.0
2021-11-15T02:43:44.380Z
Again thanks, and to be clear the "CH340" on the Mac side or the printer side? (Again, a big chunk of the answer you posted is pretty opaque to me). If I understand it correctly you are saying I can delete the USB drivers on the mac, reboot, and it should read the USB printer connection. I am a little nervous about deleting stuff like that from my system.
Jesse
CC BY-SA 4.0
2021-11-15T02:56:46.683Z
Updated answer... hopefully it is a bit clearer :-)
Greenonline
CC BY-SA 4.0
2021-11-15T05:34:13.890Z
YES thanks, it clears up a lot of things (and you went all in with the illustrations!)
Jesse
CC BY-SA 4.0
2021-11-15T02:25:11.807Z
2021-11-15T05:54:35.843Z
2021-11-15T05:54:35.843Z
Greenonline
<p>You can use Simplify3D to slice your .STL files into .X3G needed for the Makerbot. You can either connect to the printer via USB or export the .X3G file to an SD card for use in the printer. Hope this helps!</p>

CC BY-SA 4.0
2023-01-27T14:49:51.150Z
2023-01-27T14:49:51.150Z
Jeroen
<blockquote>
<p>what do you mean by SD card approach? The Makerbots take flash drives, but my attempts to print off of one were unsuccessful (it seems to be rather hard to make the right kind of file, it won't work with STLs and I gave up figuring out how to make them .makerbot files)</p>
</blockquote>
<p>This sounds like you need a better basic understanding of the printing process.</p>
<p>An STL file describes a shape you want to print, but it does not have all the information needed to actually print the object. In order to actually print the file, you need to know things like what material you will use (which will determine temperatures), what the capabilities of the machine are (how fast you can go), how much vertical detail is important to retain (layer thickness vs print time trade-off), and how strong the piece needs to be (trade-off between infill + wall thickness vs print time + material costs). You also need to specify things like how to orient the shape for best print results and what to do when there are steep overhangs or bridges.</p>
<p>To get this information, you must <strong>slice</strong> the STL (or OBJ or 3DS) file.</p>
<p>There are a number of different software packages available to do slicing, many of them freely available: Cura and slic3r come to mind. Makerbot also has their own slicer. I know you can download and install Cura on a Mac.</p>
<p>The output of the slicer is usually a <strong>.gcode</strong> file, and I would expect your Makerbots to be able to handle gcode files that were produced with the appropriate options. In fact, I strongly suspect the &quot;.makerbot&quot; file mentioned in your comment is actually a gcode file in disguise.</p>
<p>Why does this matter?</p>
<p>Print jobs can take hours and even days, and they tend to completely take over the computer while printing. No one wants to leave their laptop sitting next to a printer overnight, not able to do anything else. Newer printers will also have features like automatic resume from power loss, filament out detection, are more, that a are less likely to function properly when printing from a computer.</p>
<p>There's just too much that can go wrong while printing via computer, such that <em>you're pretty much always better off going with the SD card or USB option.</em><sup>*</sup></p>
<p>In other words, printing directly from your main computer is <strong>waaaaay</strong> down the list. It's not the first, second, or even third of fourth option as the best way to do this.</p>
<hr />
<p><sub>* A <em>dedicated</em> print station can work well, when setup properly, and people often use OctoPrint installed on a Raspberri Pi in this way. However, this also implies a high-end laptop is complete overkill for the task.</sub></p>

CC BY-SA 4.0
2021-11-22T18:09:22.790Z
2021-11-22T18:25:57.770Z
2021-11-22T18:25:57.770Z
Joel Coehoorn
<p>I am at a school with several Makerbot Replicator+ – a total of 9 of them.</p>
<p>So, they seem to print fine and I can hook up to two of them to one laptop (they are some Lenovo models from a few years back) using Makerbot Print. Well and good.</p>
<p>But I wanted to hook them up to my MacBook Pro (2020, OS X Catalina) with the USB cables, and the MacBook doesn't seem to &quot;read&quot; the printers, it's like they aren't even there. Makerbot Print (latest version) doesn't seem to &quot;see&quot; that they are hooked up. I checked the system prefs to see if the Makerbots showed up as connected USB devices and they don't seem to be there either.</p>
<p>Now, I am connecting via the USB cables and then through an adapter that connects the USB-A to USB-C. If I should just use a USB-B to USB-C cable (I ordered one to test it) then fine, I'll do that. I just wanted to check that there wasn't some other problem or if anyone else had this issue.</p>
<p>Next up: USB hubs. Makerbot says they don't recommend it, but sometimes I have to print out lots of stuff at once for student projects and I can't tie up multiple laptops for hours-long prints. I have done the technique of leaving stuff all night but that's hit or miss – if something goes wrong I am not there to stop the print (at least once something got unstuck from the build plate and I ended up with an extruder with the end encased in hard plastic like a stalactite. Unless I basically blowtorch it off... )</p>
<p>So, the question(s) is/are:</p>
<p>Any recommendations for USB hubs? (I would do wireless but that I am less sure of, and it seems easier, faster, and more reliable to link up through USB. The wireless connection always drops).</p>
<p>Any recommendations for the MacBook issue? Is it just a matter of finding the right cable? (it's certainly possible my $10 USB-A to USB-C adapter plugs aren't well designed, and I should just go for direct cabling)</p>
<p>Any recommendations for a good USB hub to link a Mac (or anything else) to Makerbots?</p>
<p>Thanks for your time and help. I do hope I am not duplicating a post but I don't see anything in my searches that addresses the specific issues I have; though it's possible I didn't use the right search terms.</p>

CC BY-SA 4.0
2021-11-15T02:26:03.590Z
you can run into bandwidth issues going the hub route- there is some point at which attempting too many simultaneous prints off a single port will not be worth it.  instead consider the sd card approach?
Abel
CC BY-SA 4.0
2021-11-15T02:32:03.090Z
Also what do you mean by SD card approach? The Makerbots take flash drives, but my attempts to print off of one were unsuccessful (it seems to be rather hard to make the right kind of file, it won't work with STLs and I gave up figuring out how to make them .makerbot files)
Jesse
CC BY-SA 4.0
2021-11-15T03:22:15.923Z
My answer pivots entirely around my supposition that the Makerbot Replicator has a CH340 IC for the USB. It *may not*, in which case my answer is useless. It would help to know which IC is actually used to implement the USB interface on the printer control board. If you can take a photo and add it to the question that would be great... however, it should be possible to determine the IC used by search the web - but only **if** you know the model and version number of the controller board, which should be written on the PCB somewhere.
Greenonline
CC BY-SA 4.0
2021-11-15T05:56:38.123Z
Further analysis (via the web) appears to show that the CH340 is **not** used for the USB - see at the bottom of my updated answer. Therefore my answer probably should be discarded and deleted as it confuses matters totally. You really need to check what IC is used by your board, for an accurate answer.
Greenonline
CC BY-SA 4.0
2021-11-15T23:20:51.287Z
they might take x3g which just needs you to run a makerbot slicing software on your stl.  usually can be made from same software that runs printer off usb
Abel
CC BY-SA 4.0
2021-11-22T17:54:15.917Z
You want to make a `gcode` file, not a `makerbot` file. The STL file describes the shape of what you want. The gcode file includes things instructions for like temperature, layer thickness, infill density, and speed in various situations.... all the information needed for the printer to produce not only the correct shape, but at the correct quality and with settings appropriate for a specific printer.
Joel Coehoorn
CC BY-SA 4.0
2021-11-22T17:56:10.283Z
As print jobs can take hours, and completely take over the computer while printing, you're pretty much always better off going with the SD card or USB option. Also, a dedicated print station (often a raspberri pi) can work well. But printing directly from the computer is **waaaaay** down the list. There's just too much that can go wrong over the course of a long print job for a computer to be a good choice.
Joel Coehoorn
<makerbot><usb><replicator+>
Want to connect Makerbot Replicator+ to Mac and several to USB hub
Jesse
# Want to connect Makerbot Replicator+ to Mac and several to USB hub

(Asked by: username_0 on 2021-11-15)

I am at a school with several Makerbot Replicator+ – a total of 9 of them.

So, they seem to print fine and I can hook up to two of them to one laptop (they are some Lenovo models from a few years back) using Makerbot Print. Well and good.

But I wanted to hook them up to my MacBook Pro (2020, OS X Catalina) with the USB cables, and the MacBook doesn't seem to "read" the printers, it's like they aren't even there. Makerbot Print (latest version) doesn't seem to "see" that they are hooked up. I checked the system prefs to see if the Makerbots showed up as connected USB devices and they don't seem to be there either.

Now, I am connecting via the USB cables and then through an adapter that connects the USB-A to USB-C. If I should just use a USB-B to USB-C cable (I ordered one to test it) then fine, I'll do that. I just wanted to check that there wasn't some other problem or if anyone else had this issue.

Next up: USB hubs. Makerbot says they don't recommend it, but sometimes I have to print out lots of stuff at once for student projects and I can't tie up multiple laptops for hours-long prints. I have done the technique of leaving stuff all night but that's hit or miss – if something goes wrong I am not there to stop the print (at least once something got unstuck from the build plate and I ended up with an extruder with the end encased in hard plastic like a stalactite. Unless I basically blowtorch it off... )

So, the question(s) is/are:

Any recommendations for USB hubs? (I would do wireless but that I am less sure of, and it seems easier, faster, and more reliable to link up through USB. The wireless connection always drops).

Any recommendations for the MacBook issue? Is it just a matter of finding the right cable? (it's certainly possible my $10 USB-A to USB-C adapter plugs aren't well designed, and I should just go for direct cabling)

Any recommendations for a good USB hub to link a Mac (or anything else) to Makerbots?

Thanks for your time and help. I do hope I am not duplicating a post but I don't see anything in my searches that addresses the specific issues I have; though it's possible I didn't use the right search terms.

**Tags:** makerbot, usb, replicator+
> **Comments:**
> **username_1**: you can run into bandwidth issues going the hub route- there is some point at which attempting too many simultaneous prints off a single port will not be worth it.  instead consider the sd card approach?  
> **username_0**: Also what do you mean by SD card approach? The Makerbots take flash drives, but my attempts to print off of one were unsuccessful (it seems to be rather hard to make the right kind of file, it won't work with STLs and I gave up figuring out how to make them .makerbot files)  
> **username_2**: My answer pivots entirely around my supposition that the Makerbot Replicator has a CH340 IC for the USB. It *may not*, in which case my answer is useless. It would help to know which IC is actually used to implement the USB interface on the printer control board. If you can take a photo and add it to the question that would be great... however, it should be possible to determine the IC used by search the web - but only **if** you know the model and version number of the controller board, which should be written on the PCB somewhere.  
> **username_2**: Further analysis (via the web) appears to show that the CH340 is **not** used for the USB - see at the bottom of my updated answer. Therefore my answer probably should be discarded and deleted as it confuses matters totally. You really need to check what IC is used by your board, for an accurate answer.  
> **username_1**: they might take x3g which just needs you to run a makerbot slicing software on your stl.  usually can be made from same software that runs printer off usb  
> **username_3**: You want to make a `gcode` file, not a `makerbot` file. The STL file describes the shape of what you want. The gcode file includes things instructions for like temperature, layer thickness, infill density, and speed in various situations.... all the information needed for the printer to produce not only the correct shape, but at the correct quality and with settings appropriate for a specific printer.  
> **username_3**: As print jobs can take hours, and completely take over the computer while printing, you're pretty much always better off going with the SD card or USB option. Also, a dedicated print station (often a raspberri pi) can work well. But printing directly from the computer is **waaaaay** down the list. There's just too much that can go wrong over the course of a long print job for a computer to be a good choice.  

---

## 3 answers

### Answer by username_2 on 2021-11-15. Score: 2 | Accepted answer

It would seem that the printer control board doesn't use a CH340 (see bottom of this answer) and therefore this answer should be ignored.

CH340 and OS X incompatibility
The reason your Mac might not see the printers could be down to the USB interface on the printer controller board.
If it is implemented by a CH340 (which is probably is, in order to reduce manufacturing costs) then, historically, MacBooks have a problem with the drivers for this device and its derivatives. That is to say, the OS has a problem - more specifically the device drivers used by the OS X kernel - as opposed to the hardware. There are a number of posts dealing with this problem, it is common on Arduino clones too, see here.
The third party drivers for the CH340(G) written for OS X are often poorly written and/or have shoddy documentation - although this opinion may be hotly debated, and I have no wish to expand upon.
If the USB interface, on the printer controller board, is implemented with an FTDI or a ATmega 16U2 then it will work fine. Unfortunately the solution is probably not to use the Mac and stick with the Lenovos (i.e. PC clone).
See the extensive answers to Can't connect Cura to my Anet A8 on OSX 10.11.6

As an aside, I gave up trying to buy/use cheap Arduino clones with a CH340(G), on a Mac long along, as it just wasn't worth the effort in trying to get the Mac to see it. I now ensure that either:

I purchase a slightly more expensive Arduino which uses a 16U2 (the more pricey FTDI chip is more rarely used on boards these days, but can still be found). Obviously, you don't have that sort of luxury when selecting a 3D printer.
I will use a PC instead, if the board has a CH340(G), or similar.

One possible solution
However, having said all of that, this issue may have been resolved in newer versions of OS X (post Mountain Lion, or thereabouts). This might provide a solution, Connect to ch340 on MacOS Mojave

remove all old drivers:
sudo rm -rf /Library/Extensions/usbserial.kext
sudo rm -rf /System/Library/Extensions/usb.kext

Now reboot the computer.
And then (very important, because it took me 10 cables to find the
right one) use a fully connected cable ;-)
Now I have these ports:
/dev/cu.wchusbserial1410
/dev/cu.usbserial-1410


Important note: Clearly, deleting kernel drivers (also known as kernel extensions, .kext) shouldn't be taken lightly. If you feel uncomfortable doing it, or don't know how to revert the process, by using a saved backup of the drivers, then please don't attempt this.
For completeness:

To back up the kext (before deleting it as shown above):
sudo cp /Library/Extensions/usbserial.kext /Library/Extensions/usbserial.kext.bak
sudo cp /System/Library/Extensions/usb.kext /System/Library/Extensions/usb.kext.bak


To restore the kext (after having deleted the kernel extension and then finding that it made no difference whatsoever):
sudo mv /Library/Extensions/usbserial.kext.bak /Library/Extensions/usbserial.kext
sudo mv /System/Library/Extensions/usb.kext.bak /System/Library/Extensions/usb.kext




Alternatively, instead of deleting the kernel drivers, you could just rename them to hide them, by adding .bak to the filename, like so
sudo mv /Library/Extensions/usbserial.kext /Library/Extensions/usbserial.kext.bak
sudo mv /System/Library/Extensions/usb.kext /System/Library/Extensions/usb.kext.bak

Then reboot. Check the printer connects or not. If not, then just restore them using the same commands shown above - so you just end up removing the additional .bak from the filename.

With respect to the quoted answer, I'm not entirely sure what is meant by a fully connected cable... There is a well-known issue that some USB charging cables - that look like normal USB cables - have only the power lines connected, and omit the data lines (again for cheapness), and it can be difficult to tell the two apart (usually by thickness, the thicker cables have more lines connected). Obviously, if the data lines are missing then the cable will not transfer data.
However, this usually applies only to cables with mini, or micro USB connectors, and usually doesn't apply to standard peripheral cables such as a USB-A to USB-B cable:

So, this issue should only arise for micro/mini USB connectors... it will depend upon your connector type.

We can't recommend particular makes or models of USB hubs as that is a shopping question, which is off-topic.

Analysis on the printer board
Makerbot appear to use the Mightyboard for the Replicator. INterestingly from the following two photos it would appear that a CH340(G) is not used, and the IC is in fact a 16U2.
Here is a photo of the board (image from MakerBot Replicator 2/2X Rev H Mightyboard – Official, OEM Board w/ 4 BotSteps):

The IC closest to the USB-B port would appear to be a 16U2:

Its form is square like a 16U2 and not elongated like a CH340G
It would appear to have an Atmel logo printed upon it.

This image (from MightyBoard Motherboard 3D Printer Dashboard), also suggests the a 16U2 is used:

All of which means that, if your printer(s) have this board, then your Mac should indeed connect to the printer.

> **Comments:**
> **username_0**: OK, I am not one who understand much of the terminology you just used. But when you say a fully-connected cable do you mean one that does not need an adapter?  
> **username_0**: To put it bluntly, could you translate your post to non-techie?  
> **username_2**: I'm not entirely sure myself, as that is quoted from the linked answer. However, there is a well-known issue that some USB ***charging*** cables - that look like normal USB cables - have only the power lines connected, and omit the data lines (again for cheapness), and it can be difficult to tell the two apart (usually by thickness, the thicker cables have more lines connected). Obviously, if the data lines are missing then the cable will not transfer data.  
> **username_0**: Again thanks, and to be clear the "CH340" on the Mac side or the printer side? (Again, a big chunk of the answer you posted is pretty opaque to me). If I understand it correctly you are saying I can delete the USB drivers on the mac, reboot, and it should read the USB printer connection. I am a little nervous about deleting stuff like that from my system.  
> **username_2**: Updated answer... hopefully it is a bit clearer :-)  
> **username_0**: YES thanks, it clears up a lot of things (and you went all in with the illustrations!)  

---

### Answer by username_4 on 2023-01-27. Score: 0

You can use Simplify3D to slice your .STL files into .X3G needed for the Makerbot. You can either connect to the printer via USB or export the .X3G file to an SD card for use in the printer. Hope this helps!


---

### Answer by username_3 on 2021-11-22. Score: 0

> what do you mean by SD card approach? The Makerbots take flash drives, but my attempts to print off of one were unsuccessful (it seems to be rather hard to make the right kind of file, it won't work with STLs and I gave up figuring out how to make them .makerbot files)

This sounds like you need a better basic understanding of the printing process.

An STL file describes a shape you want to print, but it does not have all the information needed to actually print the object. In order to actually print the file, you need to know things like what material you will use (which will determine temperatures), what the capabilities of the machine are (how fast you can go), how much vertical detail is important to retain (layer thickness vs print time trade-off), and how strong the piece needs to be (trade-off between infill + wall thickness vs print time + material costs). You also need to specify things like how to orient the shape for best print results and what to do when there are steep overhangs or bridges.

To get this information, you must **slice** the STL (or OBJ or 3DS) file.

There are a number of different software packages available to do slicing, many of them freely available: Cura and slic3r come to mind. Makerbot also has their own slicer. I know you can download and install Cura on a Mac.

The output of the slicer is usually a **.gcode** file, and I would expect your Makerbots to be able to handle gcode files that were produced with the appropriate options. In fact, I strongly suspect the ".makerbot" file mentioned in your comment is actually a gcode file in disguise.

Why does this matter?

Print jobs can take hours and even days, and they tend to completely take over the computer while printing. No one wants to leave their laptop sitting next to a printer overnight, not able to do anything else. Newer printers will also have features like automatic resume from power loss, filament out detection, are more, that a are less likely to function properly when printing from a computer.

There's just too much that can go wrong while printing via computer, such that *you're pretty much always better off going with the SD card or USB option.*\*

In other words, printing directly from your main computer is **waaaaay** down the list. It's not the first, second, or even third of fourth option as the best way to do this.

---

\* A *dedicated* print station can work well, when setup properly, and people often use OctoPrint installed on a Raspberri Pi in this way. However, this also implies a high-end laptop is complete overkill for the task.


---

