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

[{'answer_id': 18377, 'author': 'Greenonline', 'author_id': 4762, 'author_profile': 'https://3dprinting.stackexchange.com/users/4762', 'pm_score': 3, 'selected': True, 'text': '<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>\n<hr />\n<h3>CH340 and OS X incompatibility</h3>\n<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>\n<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>\n<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>\n<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>\n<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>\n<hr />\n<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>\n<ul>\n<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>\n<li>I will use a PC instead, if the board has a CH340(G), or similar.</li>\n</ul>\n<h3>One possible solution</h3>\n<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>\n<blockquote>\n<p>remove all old drivers:</p>\n<pre><code>sudo rm -rf /Library/Extensions/usbserial.kext\nsudo rm -rf /System/Library/Extensions/usb.kext\n</code></pre>\n<p>Now reboot the computer.</p>\n<p>And then (very important, because it took me 10 cables to find the\nright one) use a <strong>fully connected</strong> cable ;-)</p>\n<p>Now I have these ports:</p>\n<pre><code>/dev/cu.wchusbserial1410\n/dev/cu.usbserial-1410\n</code></pre>\n</blockquote>\n<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>\n<p>For completeness:</p>\n<ul>\n<li><p>To back up the <code>kext</code> (<em><strong>before</strong></em> deleting it as shown above):</p>\n<pre><code>sudo cp /Library/Extensions/usbserial.kext /Library/Extensions/usbserial.kext.bak\nsudo cp /System/Library/Extensions/usb.kext /System/Library/Extensions/usb.kext.bak\n</code></pre>\n</li>\n<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>\n<pre><code>sudo mv /Library/Extensions/usbserial.kext.bak /Library/Extensions/usbserial.kext\nsudo mv /System/Library/Extensions/usb.kext.bak /System/Library/Extensions/usb.kext\n</code></pre>\n</li>\n</ul>\n<hr />\n<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>\n<pre><code>sudo mv /Library/Extensions/usbserial.kext /Library/Extensions/usbserial.kext.bak\nsudo mv /System/Library/Extensions/usb.kext /System/Library/Extensions/usb.kext.bak\n</code></pre>\n<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>\n<hr />\n<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>\n<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>\n<p><a href="https://i.stack.imgur.com/11mVl.png" rel="nofollow noreferrer" title="USB connectors"><img src="https://i.stack.imgur.com/11mVl.png" alt="USB connectors" title="USB connectors" /></a></p>\n<p>So, this issue should only arise for micro/mini USB connectors... it will depend upon your connector type.</p>\n<hr />\n<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>\n<hr />\n<h3>Analysis on the printer board</h3>\n<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>\n<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>\n<p><a href="https://i.stack.imgur.com/AcMoE.jpg" rel="nofollow noreferrer" title="Photo of Mightboard"><img src="https://i.stack.imgur.com/AcMoE.jpg" alt="Photo of Mightboard" title="Photo of Mightboard" /></a></p>\n<p>The IC closest to the USB-B port would appear to be a 16U2:</p>\n<ul>\n<li>Its form is square like a 16U2 and not elongated like a CH340G</li>\n<li>It would appear to have an Atmel logo printed upon it.</li>\n</ul>\n<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>\n<p><a href="https://i.stack.imgur.com/DoO9c.jpg" rel="nofollow noreferrer" title="Annotated photo of MightBoard"><img src="https://i.stack.imgur.com/DoO9c.jpg" alt="Annotated photo of MightBoard" title="Annotated photo of MightBoard" /></a></p>\n<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>\n'}, {'answer_id': 18426, 'author': 'Joel Coehoorn', 'author_id': 12562, 'author_profile': 'https://3dprinting.stackexchange.com/users/12562', 'pm_score': 0, 'selected': False, 'text': "<blockquote>\n<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>\n</blockquote>\n<p>This sounds like you need a better basic understanding of the printing process.</p>\n<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>\n<p>To get this information, you must <strong>slice</strong> the STL (or OBJ or 3DS) file.</p>\n<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>\n<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>\n<p>Why does this matter?</p>\n<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>\n<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>\n<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>\n<hr />\n<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>\n"}]
['https://3dprinting.stackexchange.com/questions/18376', 'https://3dprinting.stackexchange.com', 'https://3dprinting.stackexchange.com/users/31967/']