@droftarts reduced the data rate as well per your advice. Thank you so much!
FYI I picked up the default from: https://docs.duet3d.com/en/User_manual/Connecting_hardware/IO_Neopixel_DotStar
@droftarts reduced the data rate as well per your advice. Thank you so much!
FYI I picked up the default from: https://docs.duet3d.com/en/User_manual/Connecting_hardware/IO_Neopixel_DotStar
@droftarts my brain skipped past the U option probably 20 times over the past couple days. That 100% solved the issue! Sorry to confuse the OP with an unrelated issue, I was just trying to keep it clean and grouped with similar issue.
I've got full control over 144 LEDs
I am also seeing strange behavior on 3.5 RE: Neopixel LEDs.
Only about half the strip is lighting, and it doesn't seem like there is any way to get the second half lighting. We are running 144 LEDs and way more than just 10 are lighting. I would say about half without counting up all 144.
Previously on 3.3 and 3.4 - using a standard 5v NeoPixel LED strip wired to the DOTSTAR header DO & Ground pins, we just sent the commands and everything worked. No hardware or wiring changes.
Here was the working code from 3.3/3.4 - and the updated code for 3.5.
3.3/3.4
Command: M150 R255 U255 B255 S144
3.5.0-rc.1
Config.g: M950 E0 C"led" T1 Q3000000
Command: M150 R255 U255 B255 P255 S144 F0
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
I'm happy to report that I've got a fix for both problems ready. With my latest version no more messages are written to USB before the device is actually opened and the reboot problem is fixed, too.
Amazing news! Sorry for the delay between responses as always, I'm very appreciative!
@chrishamm do you have an expected release date? Or is there any way I could get my hands on it a bit early?
@chrishamm I do not believe we have this same issue on the Duet 3 6HC boards, only the Mini 5+. Would it be useful to you for me to double-check that assumption?
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
(see here for further details
Any idea if it would be possible to hack in the USB-IDs of a device with the DISABLE_ECHO flag already in it? Or should I start looking at recompiling with the hack in the driver side?
@dc42 said in Issue with USB->Serial on Duet 3 Mini 5+:
As all Duet boards using a genuine USB device interface (not a USB-to-serial converter as many older 3D printer control boards did), flow control is intrinsic to the channel and the virtual RTS/CTR/DSR/DTR signals serve no purpose.
Very good information, thank you!
@dc42 said in Issue with USB->Serial on Duet 3 Mini 5+:
Please also confirm that you have tried this with more than one Duet 3 Mini board, to rule out a hardware issue with a particular board.
I have confirmed this on three separate boards. I have not yet tested with my 6HC boards but will try and squeeze that in soon. (I don't expect there to be a problem on the 6HC, as we use them in this same configuration.)
@dc42 said in Issue with USB->Serial on Duet 3 Mini 5+:
against mains ground noise causing problems
Confirmed there are no ground loops or leakages.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
Please make sure your Duet is on the latest RepRapFirmware version 3.4.4.
I reproduced the issue on both 3.3 and 3.4.4.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
Setting the USB baud rate in config.g isn't needed. It is overridden by tio anyway when you launch it (and probably by potential Python scripts, too). If you want to use a different baud rate. use the -b option instead (defaults to 115200 in tio).
Took that out of my configuration, I think it was one of those desperation measures where I was throwing everything at the wall to see what stuck.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
To get proper line outputs in tio, use the INLCRNL mode: tio -e -m INLCRNL /dev/ttyACM0.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
you have no way to disable this behaviour unless you recompile the Linux kernel (see here for further details).
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
Please confirm if the problem persists with RRF v3.4.4.
Confirmed in 3.4.4
@Falcounet at least in my case, this did not work. Not sure if this is a different issue than OP on this thread, so if so I apologize for cross-posting.
@Falcounet I wonder if this is related to the issue I am current troubleshooting.
https://forum.duet3d.com/topic/30554/issue-with-usb-serial-on-duet-3-mini-5
Could you try connecting it to the Pi4, opening the serial port, and then pressing the 'reset' button on the Mini 5+? That would indicate you are experiencing the same thing I am, which seems to be unique to the Mini 5+ USB->Serial connection on Linux.
I am having an issue with the USB Serial port being locked up on the Duet 3 Mini 5+ after rebooting or freshly booting the computer, with the USB plug plugged in.
Setup:
Error:
When freshly booting the system with the USB cable plugged in, the serial-port is hung.
If I press the reset button after booting - the terminal becomes responsive.
If I leave the USB cable unplugged and boot the system, then plug in the USB cable - the system is responsive.
To continue troubleshooting, I attached a RS232->TTL adapter to /dev/ttyS0 and changed my config.g to use the additional serial port. (For good measure I forced the USB Serial Baud / Mode)
After setting that up and plugging in the adapter and restarting the machine, you can see that the board itself is working. The web-interface responds, and the second serial port responds as well. However, the USB Serial port is still hung up when the cable is plugged in during boot-up.
Walked over to Duet and hit the reset button. Got an error message about writing to tty device. Finally disconnected and closed terminal.
Opened up the port again to see if it was responding after hitting the reset button:
For reference, I have tried the normal things like different cables, boards, etc. etc. etc.
I would also say that this exact same setup works flawlessly on the same hardware (PC) on the Duet 6HC. The USB Serial port does not hang on boot, and is used extensively. I am attempting to replicate that setup to a smaller machine using the Mini 5+
I also found the following strangeness with the USB init in dmseg:
Thank you all in advance, and sorry this is so hard to follow! Please let me know if I can explain it in an easier way, or if any supplemental information is needed.