The serial monitor shows nothing

Which pins carry a UART, and what the monitor is actually listening to.

The monitor is not on the pins

This catches almost everybody. The serial monitor is wired to the board's UART peripheral directly, not to pins on the breadboard.

On the real hardware those signals share pins with GPIO: pins 0 and 1 on the Uno, 20 and 21 on the ESP32-C3. In Mokxi those pins stay plain GPIO and the bytes go to the monitor instead. So wiring anything to those pins will not put text on the screen, and not wiring them is not why nothing appears.

The peripheral per board is USART0 on the Uno, UART0 on the ESP32-C3, UART0 on the Pico and USART1 on the STM32F411.

The sketch has to print

Serial.begin() and then something that prints. A board that is running an example chosen in the Firmware panel prints whatever that example prints, which for Blink is nothing at all. Pick the Serial example, or write a print into your own loop.

It only decodes while it is running

The decoders exist exactly as long as the run does. Stop the simulation and the monitor keeps what is already in the log, but nothing further arrives.

Is the right board selected?

With more than one board in the diagram, every line is prefixed with the board it came from, and the input row has a picker choosing which board you are typing to. If you are sending to the wrong one, nothing answers.

Is it a partial line?

A half-written line is shown as it arrives rather than held back until the newline, so a sketch that prints without ever ending a line still shows something. If you see nothing at all, nothing has been written.

Carriage returns are dropped and \n ends a line, so a sketch printing \r alone will look like it is printing nothing.

Has the log been cleared, or filled?

The log keeps the last two thousand lines across every board and drops the oldest after that. A very chatty sketch pushes earlier output out.

Sending to the board

Type into the input row and press Enter. The bytes go into that board's receive queue exactly as they would arrive on the wire, and a queue that overflows drops bytes and sets the overrun flag, as the chip does.

Nothing else works either?

Start with nothing lights up, which covers power and ground, or run and the serial monitor for what the panel does.