That will probably also work. I'm willing to bet there's just a minor difference in the serial implementation in the linux kernel vs the xnu kernel.

Calling tcflush just before writing data is just about standard in all drivers. However in the majority of cases sending a command is followed by reading a response.
But some moonlite commands don't return a response and in this case the driver doesn't do the read so the next tty command is the flush at the start of the next command.

At present the moonlite sendCommand has:

if (res == nullptr)
return true;

Perhaps this should be:
if (res == nullptr)
{
tcdrain(PortFD);
return true;
}

It's surprising this hasn't been more of a problem, the send takes milliseconds while the processor is working in microseconds.

Yeah, a lot of serial code I've used in the past just always put a tcdrain after a write. With the amount of data any of our drivers send, the delay caused by adding tcdrain should be very short, single digit milliseconds in most cases. Adding it to the tty_write function in indicom.c may prevent these kinds of issues from cropping up in all other serial drivers as well.

also works.

How about the tcdrain when res == nullptr as Chris suggested above? If that works, I'll change it across all drivers.

That works as well. With the original tcflush:
Modifying the code to drain:
fixes the problem.

To be clear, this change was made to the indi_moonlite_focus module only. (moonlite.cpp)

The Moonlite DRO driver will also need this.

There may be other drivers of all sorts which don't always return a serial response to a command.

I would be a bit nervous about adding this in indicom.c for a couple of reasons:
QtCreator reports over 200 issues with indicom.c, half of which are errors.
There's no knowing how drivers use the tty commands in indicom.

It isn't usually a problem because if a driver expects a response the tty_read will start by waiting for the command to finish being sent, then for the hardware to process the command and send the reply.

Fair enough. Definitely safer to only add it to the Moonlite drivers, or others that do multiple writes in quick succession.

Sure, fix pushed for Moonlite.

I've had a quick look and taking the strict view that any driver that sends a command but does not wait for a reply is vulnerable then it is quite a lot. All the LX200 based drivers to start with. Some of the drivers don't use a sendCommand() subroutine, the serial writes and maybe reads are embedded in each command. The Moonlite DRO driver is like that.

I spent quite a lot too much of my professional career fighting ths sort of thing on electron microscopes - just the same except that the hardware was more expensive. I had almost no say in what was implemented and one manufacturer seemed to use a different intern to do the external control for each microscope model.

Maybe then tcdrain should be added to tty_write ? Any side-effects for that?