Thread Subject: Serial fprintf/fwrite hanging troubleshooting

I'm making a GUI at the moment to access several different types of serially-connected instruments, each having a different configuration, and it works quite nicely. I'd like to get it to auto-detect the thing attached to each port, but when you try and send a command to an object which requires hardware flow control, it just hangs.

The code is:

serialObj = pumpobj(1) % user-written function to generate a serial object with the correct properties (here on COM1)
fopen(serialObj)
fprintf(serialObj, 'someString', 'async')
response = fscanf(serialObj)

if isempty(response)
    tryNextInstrumentType
else
    assignSomeValue
    tryNextComPort
end

If flow control is not required, then it works nicely, but if flowcontrol is hardware (I don't have anything which requires software flowcontrol) it hangs on the fprintf (same with fwrite) when you connect to something which isn't there, e.g. a COM port with nothing attached, or a different instrument type.

Anybody got any suggestions to get round this? Perhaps fooling matlab into thinking flow control is working when it isn't?

"Geoffrey Akien" <geoff.akien@gmail.com> wrote in message
news:gvgi79$l25$1@fred.mathworks.com...
> I'm making a GUI at the moment to access several different types of
> serially-connected instruments, each having a different configuration, and
> it works quite nicely. I'd like to get it to auto-detect the thing
> attached to each port, but when you try and send a command to an object
> which requires hardware flow control, it just hangs.
>
> The code is:
>
> serialObj = pumpobj(1) % user-written function to generate a serial object
> with the correct properties (here on COM1)
> fopen(serialObj)
> fprintf(serialObj, 'someString', 'async')
> response = fscanf(serialObj)
>
> if isempty(response)
> tryNextInstrumentType
> else
> assignSomeValue
> tryNextComPort
> end
>
> If flow control is not required, then it works nicely, but if flowcontrol
> is hardware (I don't have anything which requires software flowcontrol) it
> hangs on the fprintf (same with fwrite) when you connect to something
> which isn't there, e.g. a COM port with nothing attached, or a different
> instrument type.
>
> Anybody got any suggestions to get round this? Perhaps fooling matlab
> into thinking flow control is working when it isn't?

Hi Geoffrey,

Since hardware flow control uses RTS/CTS, you can look to see if the device
asserts CTS in a setup function.

 s.PinStatus.ClearToSend

"Geoffrey Akien" <geoff.akien@gmail.com> wrote in message <gvgi79$l25$1@fred.mathworks.com>...
> I'm making a GUI at the moment to access several different types of serially-connected instruments, each having a different configuration, and it works quite nicely. I'd like to get it to auto-detect the thing attached to each port, but when you try and send a command to an object which requires hardware flow control, it just hangs.
>
> The code is:
>
> serialObj = pumpobj(1) % user-written function to generate a serial object with the correct properties (here on COM1)
> fopen(serialObj)
> fprintf(serialObj, 'someString', 'async')
> response = fscanf(serialObj)
>
> if isempty(response)
> tryNextInstrumentType
> else
> assignSomeValue
> tryNextComPort

For the instruments that require hardware flow control, you can set the FlowControl property of the object to hardware.

You can search for FlowControl in the documentation for more help.

Hope this helps

-Ankit
> end
>
> If flow control is not required, then it works nicely, but if flowcontrol is hardware (I don't have anything which requires software flowcontrol) it hangs on the fprintf (same with fwrite) when you connect to something which isn't there, e.g. a COM port with nothing attached, or a different instrument type.
>
> Anybody got any suggestions to get round this? Perhaps fooling matlab into thinking flow control is working when it isn't?

Hadn't checked this in a while because I wasn't e-mailed when there were updates. Anyway, I got it to work in the end by turning flow control off, then manually flagging the DTR pin on for 50 ms then off again. This meant the device would happily start receiving commands and responding to them, which is enough for me to find out if its working or not. Thanks anyway.