Yeah, I'm trying to test now, but looking at Moonlite::sendCommand, it calls tcflush(PortFD, TCIOFLUSH) immediately before calling tty_write_string. tcflush is going to discard all unsent and unread data in the serial port at that moment, and since we are immediately calling tty_write back to back, I don't think the underlying serial port has actually sent the data yet. I think we need to add tcdrain in indicom.c. I'll give it a test as soon as I get it to compile on my Mac.

I just commented out the tcflush(PortFD, ...) to test it and it solved the problem. I don't know if that is the solution, but it is the problem.

Thanks,
Dave

So Mac flushes :SN because :FG is called soon after it? What if you replace TCIOFLUSH with TCIFLUSH ?

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.