grblHAL not sending initial message

[TPMoyer]

grblHAL is initially silent, vs expected behavior of executing
void report_init_message (void) after grounding the pi-pico run pin, or hitting the pi-pico reset button.

Expect main.c to call grbl_enter() in grbllib.c, and to then call report_init_message();
from the first pass through the grbl_enter(){ while(looping){. Inside report_init_message(); it should call
hal.stream.write_all(ASCII_EOL "GrblHAL " GRBL_VERSION " ['$' or '$HELP' for help]" ASCII_EOL); for my COMPATIBILITY_LEVEL == 0 instance

Have compiled under both RPi 64 bit, and windows 10. Love that drag/drop the grblHAL.uf2 onto the exposed RPi USB pseudo-drive after a 1)grounding-run button, 2) hold reset, 3)release run button, 4) release reset. sequence. MobaXterm allows a similar drag/drop ftp of files from my faster windows gaming development box, into the directory location of choice on the RPi.

My RPi+pico+grblHAL DOES respond with grbl system information requests. This pairity checks both my hardware and software setup. Check for loose wires is first fear upon any occurrence of negative function. When prompted with my java USB port.write("$#\n"), my serialEvent(serial s) listener picks up the response.
Similarly, grblHAL responds to $$ with a full listing of the $ settings.

As background: I've previously written a Grbl GUI Grbl4P and have been able to implement things like the gcode file streaming using the suggested buffer just-in-time feed, with runtime axis non-orthogonality compensation to the Y co-ordinates. Axis orthogonality was measured using RPi Processing3 boofCV image interpretation (better than 1Hz) of CNC mounted digital microscope images of display pixels, implementing my US patent 10,871,384.
Believe my serialSniffer is picking up all output on both the UART and the USB. Have verified good serialSniffing on USB, UART, and both USB+UART, by compile/runs of the pico_examples hello_world using the compile-time toggles in the CMakeLists.txt

Not having an initial hello might seem a trivial thing about which to submit an issue. My reasons for doing so are twofold.
My intent is to have multiple pi-pico instances running off a single RPi. The gCode senders will need to know which pico is which. Would like to tweek the pre-compile report_init_message() to say hello: I'm grblHAL0 or hello: I'm grblHAL1 , etc. Second reason is in the hopes of garnering some information about how and when the hal.stream.write can be employed. I'm a debug-by-logging guy, and intend to peek/poke around inside the grblHAL maslow function for my homebrew CNC. Hoping the enablement of the grblHAL initial message will be a Rosetta stone as to how I can push runtime info out of the pico.

[andrewmarles]

On my RP2040 board I happen to be working with here I see the welcome message if I have a serial console open when the board boots. There also used to be a compile option in GRBLHAL that would pause during loading until a USB connection was established, but I have not looked at that for over a year (I want my machines to be up and running without necessarily needing a sender connected).

Sending the reset (CTRL-X) character 0x18 will reset the controller and output the startup message. Sending $I will output more detailed build info as well which might also be useful. In addition, you might consider that instead of editing the hard-coded welcome string, you could add a small plugin with a configurable identifier that you could query via a $ setting so that the board role did not have to be hard-coded.

[andrewmarles]

With regards to debugging, you can print anything to the IOStream and all you have to worry about is your sender getting confused (some do, some don't). There are also debug options in the code to send output to one of the UART ports.

[TPMoyer]

Tried sending 0x18, got no response. Sent 0x18 followed by "/n" (aka 0x0A aka char(10): no response Sent each of the 256 single-byte characters followed by "/n": no response from 0x18, Most curious was: frequently but not always a 4 row response from 0x19.

one blank line GrblHAL 1.1f ['$' or '$HELP' for help] ALARM:10 [MSG:Emergency stop]

0x19 always responded to first instance after a run pin grounding, After that, it seems kinda 50/50 if it would or would not be in a mood to respond.

Full list of single chars followed by "/n" which got responses on each of multiple runs (re-ran with and without grounding run pin) 3  [MSG:Emergency stop] 5  <Alarm|MPos:0.000,0.000,0.000|Bf:35,1021|FS:0,0|Pn:PXYZHSE|Ov:100,100,100> 63 ? <Alarm|MPos:0.000,0.000,0.000|Bf:35,953|FS:0,0|Pn:PXYZHSE> 128 € <Alarm|MPos:0.000,0.000,0.000|Bf:35,826|FS:0,0|Pn:PXYZHSE> 135 ‡ <Alarm:10|MPos:0.000,0.000,0.000|Bf:35,1019|FS:0,0|Pn:PXYZHSE|WCO:0.000,0.000,0.000|WCS:G54|A:|Sc:|H:0|T:0|TLR:0|FW:grblHAL>

Infrequent responses also from 36 $ [HLP:$$ $# $G $I $N $x=val $Nx=line $J=line $SLP $C $X $H $B ~ ! ? ctrl-x] 131 ƒ [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.]

I took 63 ? as parity checking that i was not committing a classic "off-by-one" error, as ? is the grbl Status Report Query

We have a book from my university "the journal of irreproducable results". This seems like a good candidate.

Net for me: The 0x18 <==> 0x19 behavior is curious but not gating.
Your suggestion about the $I was quite helpful, as "$I/n" always prompts a pico grblHAL identifying response.

Thank you for your prompt and helpful response.
Sorry to leave it with a bit of not-fully-resolved'edness

[terjeio]

The gCode senders will need to know which pico is which. Would like to tweek the pre-compile report_init_message() to say hello: I'm grblHAL0 or hello: I'm grblHAL1 , etc.

You can add information to the $I output by registering a string with $I=some string, you can also add info via plugin code, either in the NEWOPT line or by adding entirely new lines.

$I=hello: I'm grblHAL0] followed by $I outputs

[VER:1.1f.20220325:hello: I'm grblHAL0]
[OPT:VNMZHSL,35,1024,3,0]
[NEWOPT:ENUMS,RT+,HOME,ES,TC,SS,SED,PID]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:220517]
[DRIVER OPTIONS:USB.2]
[BOARD:T41BB5X Pro]
[AUX IO:2,3,0,0]

Second reason is in the hopes of garnering some information about how and when the hal.stream.write can be employed.

hal.stream.write is set very early in the startup sequence and if there is an established UART connection on boot you will be able to see any output. A USB connection is a bit more tricky as messages sent may or may not be buffered until a connection is established. I would like to output the welcome message whenever a connection is established (as I do for networking connections) but I have not been able to do that yet - digging further into this in on my todo list, but not a high priority.