So as you've discovered there was a big update to the FTDI drivers a little while ago thanks to some excellent work by sbk58, you will need at least version 2.0.651 of the RTL in order to get good support for RTS/CTS with these devices.
Just a few other follow ups from your posts.
dieselnutjob wrote:With ultibo the flow control seems to be specified in the deviceopen. Is it possible to change flow control on the fly with an already open port?
Depending on your requirements simply closing and reopening the serial device (SerialDeviceClose, SerialDeviceOpen) with the new parameters might give you the result you need, doing that does clear the RX and TX buffers but if you are just doing an initial handshake to check for a device being present then that might be okay.
Of course there are potentially other options as well, you could enable flow control from the start and use the non blocking mode of the serial API to check for data being received within a specified timeout window.
Probably best to get some initial communications going first and then refine this part further based on that.
dieselnutjob wrote:I get $0000006 if my device is powered up and $00000004 if it is not.
The FTDISerial driver doesn't currently implement reading the status "on demand", what is returned is the status values that were provided with the last received data.
It possibly could be added to the driver if there was a need for it.
dieselnutjob wrote:in the log window I have idVendor=0403 and idProduct=6001
this doesn't seem to match these lines in ftdiserial.pas
Don't worry too much about the descriptions shown in ftdiserial.pas these come from the Linux driver and are pretty much just the first usage of each VID:PID pair. The text shown in the log is actually read from the USB device and should be correct (at least as far as the manufacturer got it right anyway). There are literally thousands of these FTDI devices floating around, as long as the actual VID:PID is listed in the source then consider it a supported device.