1
$\begingroup$

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.

$\endgroup$
7
  • $\begingroup$ 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? $\endgroup$
    – Abel
    Nov 15 '21 at 2:26
  • $\begingroup$ 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) $\endgroup$
    – Jesse
    Nov 15 '21 at 2:32
  • $\begingroup$ 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. $\endgroup$
    – Greenonline
    Nov 15 '21 at 3:22
  • $\begingroup$ 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. $\endgroup$
    – Greenonline
    Nov 15 '21 at 5:56
  • $\begingroup$ 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 $\endgroup$
    – Abel
    Nov 15 '21 at 23:20
2
$\begingroup$

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:

USB connectors

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

Photo of Mightboard

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:

Annotated photo of MightBoard

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

$\endgroup$
6
  • $\begingroup$ 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? $\endgroup$
    – Jesse
    Nov 15 '21 at 2:30
  • $\begingroup$ To put it bluntly, could you translate your post to non-techie? $\endgroup$
    – Jesse
    Nov 15 '21 at 2:35
  • 1
    $\begingroup$ 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. $\endgroup$
    – Greenonline
    Nov 15 '21 at 2:37
  • $\begingroup$ 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. $\endgroup$
    – Jesse
    Nov 15 '21 at 2:43
  • $\begingroup$ Updated answer... hopefully it is a bit clearer :-) $\endgroup$
    – Greenonline
    Nov 15 '21 at 2:56
0
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.