Communication Issues?

[jdeline]

I compiled this repository today with no errors and loaded the uf2 file onto my rpi pico board, but none of the gcode senders I tried could communicate with the board. I tried UGS, IOSender, Candle, and even the Arduino Serial Monitor. No luck. Is anyone else having problems? My toolchain setup is as described in this wonderful tutorial by Shawn Hymel: https://shawnhymel.com/2096/how-to-set-up-raspberry-pi-pico-c-c-toolchain-on-windows-with-vs-code/

[terjeio]

Are you connecting via USB or UART? If via USB I guess the port enumerates...

I have bCNC running gcode on my Pi 400 via USB and can connect via a terminal over USB as well.
With the Bluetooth plugin (uses the UART port) I can connect from my Win10 machine with ioSender.

Which board map are you using? I can upload a binary for you to test with.

[jdeline]

I clones the repository and compiled it. Did not change any of the defaults. So whatever the default board map is. If connecting directly to the Pico, what would the board map be?

[jdeline]

I can connect with bCNC, but the board starts up in an alarm state, which is "Alarm [PXYZHSE]"
I presume this is due to the default setting for the limit switches being enabled and set to inverse logic (i.e., open is a fault). The board is sitting on my desk and is not actually connected to a machine.

[andrewmarles]

It is normal behaviour that it starts in alarm state since it expects NC switches.

[terjeio]

Check this wiki page.

[Drewadc]

I'm running into this issue too. If I connect the SKR Pico to my computer, it fails to handshake with my senders and locks up the COM port until I reset the board. If I first open the COM port in bCNC and then close it, I'm able to connect to it via other Gcode senders. Is there a special exchange at the beginning of the serial connection that only bCNC is able to handle? I have inverted all of the triggers, so it is starting up in an idle state in bCNC, not alarm, but still no luck with other senders.

[terjeio]

Is there a special exchange at the beginning of the serial connection that only bCNC is able to handle?

That could be a reason as some senders wait for the so called welcome message. This is sent from Arduino boards on connection as they are hardwired from a USB <> UART chip to reset the prosessor on connect. The RP2040 is using native USB implemented on the prosessor and do not have have this option - and I have yet to find a way to detect when a connection is made.

It could also be due to grblHAL having many extensions that some senders may not like, for those compiling with a non-default compatibility option may help.

but still no luck with other senders.

Have you tried ioSender? This works for me. And do you have examples of some "other" senders that fail to connect?

[Drewadc]

Is there a special exchange at the beginning of the serial connection that only bCNC is able to handle?

That could be a reason as some senders wait for the so called welcome message. This is sent from Arduino boards on connection as they are hardwired from a USB <> UART chip to reset the prosessor on connect. The RP2040 is using native USB implemented on the prosessor and do not have have this option - and I have yet to find a way to detect when a connection is made.

This seems to be a definite possibility. When I connect with a plain serial monitor (Arduino), it gives no welcome message, but ? returns as expected. When I connect to another sender first and then disconnect, the senders that don't want to connect initially are able to get the welcome message upon connection.

It could also be due to grblHAL having many extensions that some senders may not like, for those compiling with a non-default compatibility option may help.

I tried compatibility mode 1 already with no change.

but still no luck with other senders.

Have you tried ioSender? This works for me. And do you have examples of some "other" senders that fail to connect?

Lightburn and Candle both fail to connect initially and lock up the port until a reset. Arduino serial monitor connects with no welcome message, bCNC connects as expected. If I connect via Arduino Serial Monitor or bCNC first and then disconnect, Lightburn and Candle both connect just fine. I'll take a look at ioSender.

[Drewadc]

ioSender did work, but didn't release the COM port on exit, so it didn't help with connecting to other senders. It seems as though the RP2040 can detect a serial close event, just not an open event required to send the welcome message to some of these senders. As a workaround, I wrote a batch file that first runs a python script that tries to open then close all COM ports and then launches my sender of choice. Definitely cobbled together, but it works.

[terjeio]

I believe I have found the reason for the issue, the senders that are not working apparently do not assert the DTR signal on connect (as they should?). This lead to a few failures, even a hard crash, I hope all are fixed now. I'll do a bit more testing before I commit the fix.

[Drewadc]

I believe I have found the reason for the issue, the senders that are not working apparently do not assert the DTR signal on connect (as they should?). This lead to a few failures, even a hard crash, I hope all are fixed now. I'll do a bit more testing before I commit the fix.

I can confirm that this seems to be the issue. I posted about it on the Lightburn forum and was informed late last night that there was an option to toggle the DTR signal. Once I turned it on, no more connection issues with Lightburn.