Arduino Due: USB ID it doesn't work but the serial mode does.

[robustini]

I can't get the printer to work in USB ID but only in serial mode at 250000 baud.
With "make menuconfig" I correctly enter the IDs in the configurator but then the printer does not communicate with Repetier Server.
With "lsusb" i see this:

Bus 001 Device 004: ID 2341:003d Arduino SA

So 0x2341 is the vendor id and 0x003d the product id.
In the printer.cfg:

[mcu]

serial = /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Due_Prog._Port_55736323938351C0A120-if00

With USB ID the result is this one:

9:48:02.932: // Printer is not ready
9:48:02.932: // The klippy host software is attempting to connect. Please
9:48:02.932: // retry in a few moments.
9:48:02.933: !! Printer is not ready

While in serial mode it perfectly communicates:

9:48:04.439: // Klipper state: Ready
9:48:04.482: ok FIRMWARE_VERSION:v0.8.0-193-g380309a0 FIRMWARE_NAME:Klipper

in the .config:

USB ids

CONFIG_USB_VENDOR_ID=0x2341
CONFIG_USB_DEVICE_ID=0x003d
CONFIG_USB_SERIAL_NUMBER_CHIPID=y
CONFIG_USB_SERIAL_NUMBER="12345"
CONFIG_HAVE_GPIO=y
CONFIG_HAVE_GPIO_ADC=y
CONFIG_HAVE_GPIO_SPI=y
CONFIG_HAVE_GPIO_I2C=y
CONFIG_HAVE_GPIO_HARD_PWM=y
CONFIG_HAVE_GPIO_BITBANGING=y
CONFIG_HAVE_CHIPID=y
CONFIG_INLINE_STEPPER_HACK=y

Where am I doing wrong?

[klipper-gitissuebot]

Hi @robustini,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[robustini]

Here the log when it doesn't communicate in "usb id" mode.

klippy.log

[robustini]

And here the log when it works correctly in serial mode.

klippy.log

[KevinOConnor]

After flashing Klipper with USB support, you must run the ls /dev/serial/by-id/* command again to determine the new device name - as described in the Installation document. (The device name will change after Klipper is flashed to the device.)

-Kevin

[robustini]

Thanks @KevinOConnor for reply!
Reflashed now but the device name is the same.
After: /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Due_Prog._Port_55736323938351C0A120-if00
Before: /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Due_Prog._Port_55736323938351C0A120-if00

[KevinOConnor]

If you compile and flash Klipper with USB support, then you must use the other usb plug (the one furthest from the power port).

-Kevin

[robustini]

You mean the "Native Port" instead "Programming Port" of Arduino Due?
I've not read this thing in the documentation, where is it? :-)

[robustini]

Ok, with the Native Port work fine, cool thanks!

[robustini]

I've strange behavior flashing using USB ID with Arduino Due.
After flashing it everything works perfectly, and the "Native Port" is correctly identified, with "lsusb":

Bus 001 Device 014: ID 2341:003e Arduino SA

Doing an RPI reboot no longer works because it changes:

Bus 001 Device 006: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader

To show it again with the correct ID I have to reflash it, or reconnect the USB port to the RPI turned on, and it's terribly boring.
Is it the fault of Raspberry or the firmware that installs Klipper?
I repeat, is the "Native Port", not the "Programming port," because only the serial mode works with the second one.

[robustini]

Solved with Arduino Due hardware mod fix.

[Googliola]

Sorry to resurrect this issue, but after struggling with that menuconfig USB for a while, I am wondering what can be gained from using the native port in terms of performance.
Also, if I understand correctly, using a genuine DUE does not make the flashing procedure any different (apart from the settings of course) or more complicated.