Page MenuHomeAleph Objects Inc

Cannot connect to Printer - Windows/Debian
Closed, ResolvedPublic

Description

Testing on Windows platform version 2.6.21 - similar issue to T1034 however difference being that:
Mac OS X - no USB device is detected and Connect/Disconnect/Console buttons are grayed out and not usable.
Windows - USB device is detected (Connect/Disconnect/Console buttons are active) but once you click "Connect", it scans and does not find a printer. Message: "Failed to find a printer via USB"

Event Timeline

Yahuba created this task.Aug 23 2017, 10:44 AM
Yahuba renamed this task from Cannot connect to Printer - Windows to Cannot connect to Printer - Windows/Debian.Sep 11 2017, 8:51 AM

I was able to replicate this same error in the Debian OS environment while testing 2.6.26

Debugging this gave me the error from serial: "Device is not ready", solution is wait a bit and then reconnect. I think this is not cura error. @alexei @karrad Should we add special message for user in this situation like "Device is not ready. Wait a bit and then reconnect"?

Is there a suggested amount of time we should wait before we try to connect again?

I attempted to wait in incriments of 1 minute, 2 minutes, etc.. all the way up to 5 minutes but continued to get an error: "failed to connect via USB". I noticed that there is a missing driver (RAMbo). Could this be why its not connecting?

@Yahuba I have "Device is not ready" only on linux. For windows, yes, this is driver issue. Linux have this driver by default, but on windows it needs to be included to the setup. @alexei, Could you check why driver is not installed with cura?

@victor_larchenko: I think I heard @Yahuba mentioning that serial drivers are not working for Win7 only, but it works for Win10. In any case one would need corresponding cura log output to figure out what is wrong.

@Yahuba See if you can find a cura2_lulzbot.log file and paste the contents here.
It is typically in a location like

\Users\<username>\AppData\Local\cura2_lulzbot\cura2_lulzbot.log

or

\Users\<username>\AppData\Roaming\cura2_lulzbot\2.6\cura2_lulzbot.log
Yahuba added a comment.EditedSep 29 2017, 12:11 PM

Here is the log from the WIn 7 machine.

Steven added a subscriber: Steven.EditedSep 29 2017, 2:01 PM

@Yahuba we do not have Windows workstations to troubleshoot this so will need some additional info.

  • Confirm if the issue happens on Win 7 with a different printer.
  • Try to manually flash the firmware using the Machine setting flash
  • Try to manually flash the .hex file using Arduino IDE. If this fails, it is very likely the issue is with the driver installed on that workstation and not Cura.
Steven reassigned this task from victor_larchenko to Yahuba.Sep 29 2017, 2:01 PM
Steven added a subscriber: victor_larchenko.
Yahuba added a comment.Oct 2 2017, 2:57 PM

Follow up:
Attempted to connect to both the mini and Taz 6 printer and in both cases get a Failed to Connect to Printer via USB message.
When I try to update the firmware via Machine Settings, it gives me a Failed Due To Communication error.
Tried to manually flash using Arduino IDE and got a "problem uploading to board" message.

@Yahuba just realized the title of this ticket also lists Debian. Are you also not able to connect on Debian?

Yahuba added a comment.Oct 4 2017, 1:54 PM

@Steven correct, I am not able to connect in Debian stretch

Steven added a comment.Oct 5 2017, 6:18 AM

@Yahuba I think something is either wrong with those specific printers or other hardware in your testing. Every computer in our offices is running either Debian Stretch or Debian Jessie and can connect and reflash firmware.

Yahuba added a comment.Oct 5 2017, 8:57 AM

Ive tried flashing the firmware but I keep getting a message that the update failed due to a communication error. It happens in Debian and in Win 7 and Ubuntu Zesty. Xenial wont even launch becuase the installer is missing a dependency (T1138)

@Yahuba , make sure that you directly connecting printer and computer via USB cable. No USB switches should be used.

In T1125#19440, @alexei wrote:

@Yahuba , make sure that you directly connecting printer and computer via USB cable. No USB switches should be used.

Yes, all our testing systems are direct USB cable connection from printer to computer.

@Yahuba Also see the articles that Alexei referred to. One possibility for the problems on Debian is that you aren't added to the necessary Linux groups.

Update: I was able to figure out my issue with Debian Stretch (Jeff, you were correct that the issue was that the user account was not added to tty and dialout groups) and am able to push a successful print on 2.6.37.

I am updating this ticket with the console output from Ubuntu Zesty. Tested 2.6.38 today and still failing to connect to printer via USB and when I attempt to flash firmware update (auto or manual upload), i am getting a failed do to Communication error.

It doesn't seem to be finding a printer on any serial port.
Is this a known good printer and computer, i.e. that works from another OS like Debian or Windows?
Are you a member of the Linux group "dialout"?

With the printer turned on, try plugging in the USB cable. Then open a console and type the command "dmesg". At the end you should see a serial device detected, something like this:

[61360.016037] usb 8-1: new full-speed USB device number 3 using uhci_hcd
[61360.213085] usb 8-1: New USB device found, idVendor=27b1, idProduct=0001
[61360.213091] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[61360.213095] usb 8-1: Product: RAMBo
[61360.213098] usb 8-1: Manufacturer: UltiMachine (ultimachine.com)
[61360.213101] usb 8-1: SerialNumber: 8543334333435120A1E0
[61360.215227] cdc_acm 8-1:1.0: ttyACM0: USB ACM device

What do you see?

Once you know the device (in this case ttyACM0), could you try setting the baud rate and seeing what is coming back from the serial port?
These commands should do this under Linux:

stty 115200 < /dev/ttyACM0
cat /dev/ttyACM0

You should see something like this coming back from the printer:

echo:Marlin 1.1.5

echo: Last Updated: Sep 25 201715:39:02 | Author: (Aleph Objects Inc., LulzBot Git Repository)
echo:Compiled: Sep 25 2017
echo: Free Memory: 5359 PlannerBufferBytes: 1232
echo:EEPROM version mismatch (EEPROM=V23 Marlin=V40)
echo:Hardcoded Default Settings Loaded
echo: G21 ; Units in mm

echo:Filament settings: Disabled
echo: M200 D3.00
echo: M200 D0
echo:Steps per unit:
echo: M92 X100.50 Y100.50 Z1600.00 E833.00
echo:Maximum feedrates (units/s):
echo: M203 X300.00 Y300.00 Z8.00 E40.00
echo:Maximum Acceleration (units/s2):
echo: M201 X9000 Y9000 Z100 E1000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P2000.00 R3000.00 T2000.00
echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
echo: M205 S0.00 T0.00 B20000 X12.00 Y12.00 Z0.40 E10.00
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:Auto Bed Leveling:
echo: M420 S0
echo:PID settings:
echo: M301 P28.79 I1.91 D108.51
echo: M304 P294.00 I65.00 D382.00
echo:Z-Probe Offset (mm):
echo: M851 Z-1.38
echo:Stepper motor currents:
echo: M907 X1300 Z1630 E1250

This is for a LulzBot Mini. It might be different for a TAZ.

karrad added a comment.EditedOct 26 2017, 3:56 PM

@Steven @Yahuba @tranter Running 2.6.43 on windows 7. I am able to connect to a Mini, flash default firmware, and move axi(s?)

karrad added a subscriber: marcio.EditedOct 26 2017, 4:21 PM

@Steven @Yahuba @tranter @marcio I was able to connect a TAZ 5 in windows 7, but it exhibited some strange behavior.

First attempt to connect to the printer did not succeed. For whatever reason, windows 7 wanted to re-install the RAMBo drivers when first plugging into the TAZ 5. This test happened immediately after the Mini test above, but i thought Mini RAMBo and RAMBo both ran the same drivers... Once the drivers installed, I had no issue connecting and flashing.

After connected the printer would not allow me to home in the Z direction through Cura. I was required to home x and y first, and than it would allow me to home Z. After that, moving axis work as normal in all directions. The Z endstop trigger is on the Z axis motor mount, and we should be able to home in Z whenever without damaging the machine. I am not sure if this is marlin 1.1.5.19 or Cura 2 preventing home in Z initially.

Yahuba closed this task as Resolved.Nov 1 2017, 3:54 PM

Closing this ticket. The issue was on my end with our Windows 7 machines. For some reason they were not installing the RAMBo drivers as part of the installation. I had to download the drivers from here: http://reprap.org/wiki/File:RAMBo_USBdriver.zip and point to them from the device manager.