Prusa i3 - can't connect from iMac or MacBook Pro

I recently purchased and assembled a Prusa i3 EG-1. It came with a ZRIB board loaded with (I believe) the Marlin firmware. However, I am not able to connect to the printer using my iMac (running to El Capitan 10.11) nor my MacBook Pro (running Mavericks 10.9).

Note that:
- I am able to print from an SD card
- I was able to connect by using my friend's laptop running Windows 10, using Repetier Host to control the motors and move the extruder in all directions

On my machines, I tried installing the Arduino software after being told that it automatically installs the necessary drivers for the printer. But on my iMac, nothing shows up in the list of ports (Arduino software or Repetier Host) when the printer is plugged in. On my MacBook pro, I can see a serial connection popping up… but when trying to connect with Repetier Host, it says “connection opened”, and 5 messages remain waiting and it never finishes making the connection.

So I know it's not the USB cable, since it worked on my friends laptop. And I know things should be assembled fine because I was able to print from the SD card. I tried manually installing the FTDI drivers on my laptop but it didn't work. I think there's a message at the bottom of Repetier that says "unknown printer firmware”.

The shop I bought it from wants to replace the board, but I'm hoping there's a simpler solution. Can someone help? I would really like to print from my iMac!

According to google this board uses a FTDI FT232R device for USB, that's a fairly standard device

what driver did you try and install This one?

You should be able to identify the serial driver chipset using the "About this Mac" dialog which you can find in the Apple Menu or using Spotlight:



Arduino should be visible in this list (but I don't have one connected right now):



If it uses some clone chipset (like CH-340) you might have to use another driver, but it looks like Dust is right.
But if the device doesn't appear in this list the board might be damaged.

Edited 1 time(s). Last edit at 12/07/2016 08:42AM by microfortnight.

---

Best regards / Viele Grüße
Till

Thanks everyone.

First I tried the Arduino software.
Then I tried the driver sent by the supplier, looks like CH34x (340/341)
Then I tried the VCP drivers from FTDIchip (same as Dust suggested)

It’s showing up in my system report as “FT232R USB UART”

So is it possible for the board to be defective, even considering it worked from a Windows machine?

Edited 1 time(s). Last edit at 12/08/2016 12:04AM by Cake.

Have you downloaded and run print run?

Quote
Cake
It’s showing up in my system report as “FT232R USB UART”

So is it possible for the board to be defective, even considering it worked from a Windows machine?

Sorry, you already mentioned this in the first post and I didn't see it
No, it's probably not defective in this case.

Since 10.9 Mavericks Apple delivers FTDI drivers together with MacOS (AppleFTDI).
If I remember correctly, they didn't work properly in 10.9 / 10.0 and needed to be deactivated.

Command to list installed FTDI drivers:

find /Library/Extensions/ /System/Library/Extensions/ -iname "*FTDI*.kext"

Example output:

/Library/Extensions//FTDIUSBSerialDriver.kext
/System/Library/Extensions//AppleUSBFTDI.kext

Command to display currently loaded drivers:

kextstat | grep FTDI

Loading and unloading AppleFTDI driver:

sudo kextload -b com.apple.driver.AppleUSBFTDI
sudo kextunload -b com.apple.driver.AppleUSBFTDI

Loading and unloading FTDI driver:

sudo kextload -b com.FTDI.driver.FTDIUSBSerialDriver
sudo kextunload -b com.FTDI.driver.FTDIUSBSerialDriver

Please ensure only one of these drivers is loaded and then try again.
If things don't work, try the other driver.

There are some posts which recommend the AppleFTDI driver on 10.12 Sierra: [forum.arduino.cc]
TBH, I don't know which driver I'm using at the moment.
I have boards with all kinds of chipsets (original FTDI, CH-340, ATMEGA16U2, ...) and with each MacOS update at least one of these will stop working
The AppleFTDI driver was meant to stop these problems when updating the OS but it didn't work properly on older MacOS.

In the Arduino IDE you should be able to select the serial port now: Example images

When trying to connect with Pronterface or Repetier Host you need to select the correct device and the correct baud rate.

Edited 1 time(s). Last edit at 12/08/2016 08:34AM by microfortnight.

---

Best regards / Viele Grüße
Till

On my MacBook (10.9)… I followed the instructions from microfortnight. My drivers were exactly like yours posted, and in a sequence (that I can't remember or reproduce) of loading and unloading between those two drivers, twice it connected successfully using Repetier Host with the non-Apple FTDI driver… But at the moment, it again refuses to connect, with either driver. However, I am able to connect with print run (Pronterface?), even when both drivers are loaded. So I would think that it's just a setting in Repetier, but that doesn't make sense because it did work those two times and I didn't change any settings.

On my iMac (10.11), output of the list of installed FTDI drivers:
/Library/Extensions//FTDIKext.kext
/System/Library/Extensions//AppleUSBFTDI.kext

Output of the command to display currently loaded drivers is empty. The port doesn't show up in Arduino software, but in the system information > USB it shows FT232R USB UART

Hey Cake,

both drivers try to handle the same kind of device, identified by USB Vendor ID (FTDI: 0x0403) and product ID (FT232RL: 0x6001).
Only one of these drivers can "lock" and use the device at the same time.
To stay out of trouble, you should only load one.
It would also be the best to install only one but since one of these drivers comes with MacOS.....

You should also know that kextunload is not permanent, if you reboot both driver will be loaded again

For your 10.9 machine:

The Manual says:

Quote
FTDI Driver Installation manual
Since 10.9 (Mavericks), OS X has included built-in partial support for some FTDI devices in VCP mode. Starting with 10.11 (El Capitan), Apple’s own driver seems to be sufficiently comprehensive that many customers will not need to install FTDI’s own VCP unless they wish to use its advanced features such as baud-rate aliasing and configurable latency times.

Source: [www.ftdichip.com]

There are also steps for "Disabling the Apple-provided VCP on OS X 10.9 and later".

So you should try to permanently disable the AppleFTDI driver on this Mac because it does not work in this version.

For your 10.11 machine:

Did you by chance "install D2xxHelper to prevent OS X 10.11 (El Capitan) claiming the device as a serial port (locking out D2XX programs)."?
In this case, none of the drivers mentioned above would be able to see the device.
If installed, the kext file could be found in: /Library/Extensions//D2xxHelper.kext
If you don't need it, or don't know about it, just delete it from your Mac.

On 10.11, you cannot permanently disable the AppleFTDI driver, you can only do the kextunload procedure until you restart your Mac.
Because of this, and because of the quote from the manual above, you should not install the FTDI driver and try the AppleFTDI driver first.
If you can't get AppleFTDI to work, you can still install the FTDI driver.

If the board is plugged in, does this command display anything (except for the bluetooth devices)?

ls -1 /dev/cu.*

Unfortunately, I have no 10.9 / 10.11 machine left for testing, all of my Macs are already migrated to 10.12, so I can't test it.

Edited 2 time(s). Last edit at 12/09/2016 08:20AM by microfortnight.

---

Best regards / Viele Grüße
Till

I can confirm my USB Programmer (Original FTDI FT231X, Device ID 0x6015) is working under 10.12 Sierra with AppleUSBFTDI.kext.
I just used it to push a Blink Sketch to some Arduino Pro Mini.

USB serial device is created in /dev/cu.usbserial-DB00J4YN

It didn't work the first time, I had to reboot. Could be because I previously had the Original FTDI driver installed.

The driver seems to be loaded when the device is attached and unloaded after some inactivity.
So there is no reason to load the driver manually, but you could check...

kextstat | grep -i ftdi
  159    0 0xffffff7f838f9000 0x7000     0x7000     com.apple.driver.AppleUSBFTDI (5.0.0) 797D6BEE-10AD-30B0-97AE-157463D700AF <138 39 5 4 3 1>

...if the driver has been loaded.

---

Best regards / Viele Grüße
Till

10.9 MacBook… I went ahead and disabled apple’s FTDI driver. Then by installing the FTDI Driver manually I can connect using Print Run/Pronterface, but NOT with Repetier. That leads me to think that I have an incorrect setting in Repetier (*BUT* I do remember those 2 times it actually did connect successfully). I guess I could learn how to use Print Run, but it's really bothering me that Repetier isn't working.

Some other things to add:

- when asking the supplier for help, they sent a link to another driver labeled CH34x (for CH340 or CH341 chips). An Arduino clone? From them:

Quote

The printer kit you have is the new EG-1 v2. It uses the ZRIB control board. You should not need to install anything other than the Arduino IDE software (latest version). It includes the necessary drivers. You can manually install the FTDI drivers found here: [goo.gl]

I’m wondering if this CH34x driver is causing issues somewhere, since I don't know how to uninstall it (or remember when and if I even installed it in the first place!)

- in /Library/Extensions I see a file “USBSerial.kext” but I don't know what that is since the uninstall instructions for CH34X asked to remove a file called “USB.kext” in the System/Library/Extensions folder.

- Even after disabling Apples driver, and uninstalling the FTDI one too, “FT232R UART” still shows in my system report

- did the Arduino software install any drivers that I'm not aware of?



10.11 iMac… I don't see "D2xxHelper.kext" in my extensions folder, and ls -1 /dev/cu.* doesn't display anything other than bluetooth.
Searching for install drivers, I see "FTDIKext.kext" and have no clue what it is:
/Library/Extensions//FTDIKext.kext
/System/Library/Extensions//AppleUSBFTDI.kext

I will try to install the FTDI Driver tomorrow, but I'm thinking I should upgrade to Sierra before starting on it (because that machine will be upgraded eventually).

I must be making this is difficult for you. When this is over I’m buying you a beer. Two beers!!

Edited 1 time(s). Last edit at 12/10/2016 03:50PM by Cake.

Switched over to my iMac... and made some progress. I updated the operating system to Sierra (10.12). It seems the default Apple FTDI driver works, but only when I have the printer plugged in when the computer boots up. Then, if I unplug and replug the printer, it stops seeing the port. Considering I rarely restart my computer, this could be annoying... I can't leave the printer plugged in all the time!

Maybe this explains why when you tested your device it only worked after you rebooted?

Steps:
1. Power on the printer and plug it to the computer
2. boot (or reboot) the computer

After this, unplugging the printer causes issues. kextstat shows that (after a couple minutes) the driver is unloaded. But it does not get loaded after plugging the printer back in. Is there any way to force it to refresh so it really checks what's going on? What happened to plug 'n play?

Edited 3 time(s). Last edit at 12/10/2016 03:49PM by Cake.

You probably don't have a CH340, but you better check, they look like this in System information:



If plugged in, it looks like this in kextstat:

kextstat | grep -i wch
  154    0 0xffffff7f838a6000 0x5000     0x5000     com.wch.usbserial (1) 2A7CE003-3526-32C8-BC4E-62C90DF85FB5 <115 40 4 3>

Current CH340 driver installs in /Library/Extensions/usbserial.kext, you can verify the location by checking the output from

pkgutil --files com.wch.usbserial
usbserial.kext
usbserial.kext/Contents
usbserial.kext/Contents/Info.plist
usbserial.kext/Contents/MacOS
usbserial.kext/Contents/MacOS/usbserial
usbserial.kext/Contents/Resources
usbserial.kext/Contents/Resources/en.lproj
usbserial.kext/Contents/Resources/en.lproj/InfoPlist.strings
usbserial.kext/Contents/_CodeSignature
usbserial.kext/Contents/_CodeSignature/CodeResources

The driver matches the device by using USB Vendor ID and Device ID.
It should not be necessary to remove the CH340 driver.
I also have both installed as you can see.

These CH340 devices are dirt cheap and might work for some people, maybe even for most people.
I still don't like them, on every new MacOS version, it takes a long time until they release a new driver.
Their download section is a mess and everything is in Chinese, but there is a blog which posts the link every time.
Also the device file often changes when unplugging, like /dev/cu.wchusbserial1410, /dev/cu.wchusbserial1420, etc., so you get weird errors when uploading stuff.
Don't buy these if you can avoid it.

Regarding the FTDI driver / programmer, I needed to reboot only once to get this one to work. Now I can plug and unplug and it works instantly.
The driver also unloads after some time but there is no problem when reconnecting the device.

I understand that rebooting every time is no acceptable workaround
Unfortunately I have no ideas left. Maybe it's something stupid and it works when changing the cable or AC outlet

---

Best regards / Viele Grüße
Till

ok. Thank you very much for your help, it's much appreciated. It really helped me to understand more about drivers on the Mac.

I will try to get the supplier involved. I don't understand why they sent me the driver for CH340/CH341, when the device is registering as FTDI…

So I'm still trying to solve the issue of why the printer loads fine when booting my machine, but does not load again after unplugging and re-plugging it. The supplier offered some advice that looks promising:

Quote

As for when it works when booting the Mac, well that makes senses, since when booting the Mac in is power user mode(root) in the background and loads up the drivers FTDI correctly with theses permissions. But if you unplug the printer, then upon re-connection your user does not have proper permission to load the FTDI drivers correctly.

So I found this in the FTDI Driver installation guide:

Quote

An ownership or permissions problem is preventing the system from making the device accessible. Check that the driver is owned by root and wheel. The most common symptom is the group for FTDIUSBSerialDriver is not wheel. To change the group, login as root and perform the following script in a Terminal window

cd /system/library/extensions
chgrp -R wheel FTDIUSBSerialDriver.kext

Here are the permissions for my driver:

drwxr-xr-x@ 3 root  wheel  102 19 Oct 23:57 AppleUSBFTDI.kext

So I enabled and logged in as the root user and ran:

chgrp -R wheel AppleUSBFTDI.kext

Here is what it spit out:

chgrp: AppleUSBFTDI.kext/Contents/_CodeSignature/CodeResources: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/_CodeSignature: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/Info.plist: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/MacOS/AppleUSBFTDI: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/MacOS: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/Resources/English.lproj/InfoPlist.strings: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/Resources/English.lproj: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/Resources: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents/version.plist: Operation not permitted
chgrp: AppleUSBFTDI.kext/Contents: Operation not permitted
chgrp: AppleUSBFTDI.kext: Operation not permitted

Why operation not permitted?
and am I on the right track?

Hello Cake,

you cannot change the permissions of AppleUSBFTDI.kext, it is considered a system file and covered by System Integrity Protection, so also with sudo or as root it's not possible.
It is also not required because the permissions are already correct (root/wheel) as you can verify in your output of ls.

Also I'm no expert when it comes to operating systems, but this support answer sounds like BS to me
Loading drivers is a kernel mode task, not user mode task.
The user does the plugging and unplugging, driver and OS should do the rest.

When mentioning permissions, you might want to check the permissions of the generated files in /dev/tty*

You can try to check your systems log files using Console.app.
Maybe you are able to find, identify and compare the output when connecting to the printer on first and second attempt.
If you find something related, it might be possible to filter by subsystem (right-click onto a line which is related to the problem).

If there is no obvious problem, I'm probably not able to analyse the output.

---

Best regards / Viele Grüße
Till