PDA

View Full Version : QSerialDevice never comes back if device unavailable



waynew
22nd January 2010, 23:25
QSerialDevice is working just fine - reads and writes with no problems (thanks for all of your hard work Denis!), unless the h/w or s/w device on the other end of the serial port is unavailable (like the power is off to the device). Then when you try to write a command to it, it goes away and freezes the application. Not sure how to resolve this.

I would like to give the user a QMessageBox with a warning when this happens.

Thanks for any ideas.

kuzulis
23rd January 2010, 10:59
If the words "device unavailable" you mean the situation when the remote device is powered off or there was a break of communication (cable break RS-232), there are two options:
1. If the data exchange with the device you are using two wires: Rx and Tx - it is impossible to determine the availability of hardware or unavailability of the unit! For this purpose, use the software definition of the device: the device first sends a query and await a response from the device during a timeout. If no answer for the timeout - the device is not available. :)
2. If the data exchange with the device you are using more than two wires (such as modems) - then we can determine the availability / unavailability of device (see the description of the standard and goal lines of port RTS, CTS.RI, etc.).
For this case, sufficient to include hardware control "Hardware flow control" - and then the data exchange will occur on the standard. (if I'm not mistaken)



hen when you try to write a command to it, it goes away and freezes the application.

show the source code. likely you do something wrong doing. :)

waynew
23rd January 2010, 15:52
Thanks for your response.
No doubt it is something I am doing wrong.
Yes, the device is software, so no flow control.
Here is the code and the debug output:



PreferencesDialog::PreferencesDialog(QWidget *parent) :
QDialog(parent),
m_ui(new Ui::PreferencesDialog)
{
m_ui->setupUi(this);

//01202010 - Set up CAT preference values
AbstractSerial *MyDevice = new AbstractSerial();
// Getting Available Ports
QStringList list = MyDevice->serialDevicesAvailable();
list.sort();
int len = list.size();

for (int i = 0; i < len; i ++) {
m_ui->cbPort->addItem(list[i]);
qDebug() << "Port is " << list[i]; // see debug output below
}
MyDevice->close();
delete MyDevice;

// debug output
Port is "COM1"
Port is "COM2"
Port is "COM3"
Windows: NativeSerialEnginePrivate::nativeClose
-> hd == INVALID_HANDLE_VALUE. Error!
//


// Get tx vfo
cmd = "FT;";
len = 8;
ba = cmd.toAscii();
QByteArray ra = readWrite(port, len, ba);
///


QByteArray SerialComm::readWrite(QString port, int len, QByteArray ba) {
AbstractSerial *MyDevice = new AbstractSerial();
MyDevice->setDeviceName(port);
if (MyDevice->open(QIODevice::ReadWrite | QIODevice::Unbuffered)) {
qDebug() << "serial device status is " << MyDevice->deviceName();

qDebug() << "Writing the command";
MyDevice->write(ba); // see debug output below
qDebug() << "Command written";

//printDataToHex(ba);
ba.clear();
}

// debug output
Windows: NativeSerialEnginePrivate::nativeOpen
-> Trying to open device: "COM3"

Windows: NativeSerialEnginePrivate::nativeOpen
-> Opened device: "COM3" succesfully. Ok!

serial device status is "COM3"
Writing the command
// no response now


Doesn't make any difference if I try to timeout the write(ba) command - it just never returns.

kuzulis
24th January 2010, 12:57
Hmm .. All my works. I did rewrote the program from the /examples for reading and writing command "FT;" (see the archive as an attachment).
I tried to write the command "FT;" simply in the serial port PC, which was not connected to anything. I have a "freeze" was not! Maybe you have a "curve" port driver or faulty port?

waynew
24th January 2010, 13:23
Thanks for your help Kuzulis. My application is trying to reach a software serial port through a virutal port programmed pair that are established with the program com0com.
Perhaps that is where the problem lies. I will try a different program for making the virtual pair and see if that solves the problem.

OK, I have switched from com0com to VSP Manager and the problem is cured.