I need to be able to close COM ports through the command prompt (Windows 7 OS). The reason for this is that I work with a lot of experimental equipment, controlled with a language called LabVIEW, and communication to these devices is sometimes lost. Right now the only fix is to either rename the COM in device manager, or reboot. Ideally I'd like to close the port in command prompt, which I can implement programatically in my control software.
Does anyone know either; how to close a COM port in command prompt, or a quick and easy way of closing a COM port, so then I can reestablish a connection with my device?
Cheers!
I don't think you can simply close a resource that is in use by another program, this will undoubtedly lead to errors. Programmed correctly LabVIEW should not leave ports open, even if port are left open simply closing labview should be enough.
In LabVIEW programatically open and close the COM port, don't rely on the auto-closing of the VISA system. Also add timeouts to the serial connections, than you should get a connection error time out and be able to clean up the resource.
Basically you need to solve your problem at the origin, if help needed post your LabVIEW code.
Presuming you read from the serial port in a while loop, simply stop the while loop when an error is found, see the code snippet. This stops the loop and the resource will be closed outside the loop regardless of the error.
Related
I have firmware installed on an Arduino DUE from a different mac, it is designed to interface with a Matlab-based application. It has been tested and known to work. I am attempting to modify the firmware from the mac in my office, but I ran into a snag after installing the Arduino IDE.
First, I cannot get the Arduino Serial Monitor to interact with the DUE. I have tried multiple times, it worked once but I have not managed to make it work since. No errors are reported.
Second, I cannot get the screen terminal command to interact with the DUE either. No errors are reported.
Third, if I simply use text pipes in the terminal (e.g., echo 'status' > /dev/cu.usbmodem1421 or head -20 /dev/cu.usbmodem1421 &) I get appropriate responses from the DUE.
Fourth, the Matlab application can interact with the DUE just as designed.
Note that this is the native USB port in the DUE, no serial adapters (with their driver weirdnesses) are involved. I have not tried to download new code to the DUE as the firmware works as it is as long as we use macs (it is just that I need to modify it so that it can work with the much-slower ports in a Windows PC).
I need to be able to debug the code I am modifying, and for that I need to be able to interact via a terminal, any terminal. Any ideas of where to look?
UPDATE: I noticed that the code was not waiting for USB to be ready. So I added
while(!WiredSerial){
digitalWrite(PIN_LED, HIGH);
delay(125);
digitalWrite(PIN_LED, LOW);
delay(125);
}
After this change the DUE waits for the terminal to be opened and the terminals display the initialization text without a hitch. After that the behavior is the same as reported before.
Never mind.
I was certain that I had already checked this before posting. As a matter of fact, I am sure that it is the first thing I checked, something else must have changed in the interim.
The code was expecting a newline character before it sent anything back while the terminals were just sending a carriage return.
I'm interfacing to a hardware serial device using QT, I've based my application roughly around the Terminal example, but as the communication needs to be very synchronous the serial handler is living in another thread. The connection is via a 2xRS232 to USB adaptor with an FTDI chipset.
The serial comms are fine, I can connect, send commands, etc. However, when I quit and reload the application the serial port seems to be blocked.
Let COM1 be the connected device, COM2 is unconnected.
If I run the program, do a bit of talking to the hardware and quit, I can no longer connect to COM1 the next time I run the program (the data leds don't flash on the adaptor) unless I attempt to connect to COM2 first. Once I've tried this I can then connect back to COM1 as usual. This behaviour is not seen in the reference utility for the hardware and so must be down to some way I'm handling the port.
My close code is:
void mydevice::closeSerialPort()
{
this->stop();
serial->close();
emit serialClosed();
emit log("Serial port closed.");
}
serial is a QTSerialPort. First a stop command is sent to turn off the hardware (not relevant to the problem, it's just a convenience) and then I send a close command to the serial.
I have a subclassed QWidget for my main window, which calls this command on exit:
/* In the constructor */
connect(this, SIGNAL(WindowClosed()), mydevice, SLOT(closeSerialPort()));
void mainwindow::closeEvent(QCloseEvent *event)
{
emit WindowClosed();
event->accept();
}
Is there any reason for this behaviour? I assume I'm blocking the port open somehow, but surely it would complain that it's already open.
Another odd issue is that say the device is on COM1 and I open it in my application, COM1 is unresponsive in the other utility and the device appears on COM2. However, when I switch back to my program and fiddle a bit, the device appears on COM1 again (though always in COM2 in the other application).
So there seems to be a fairly simple solution, though I don't understand exactly what was causing the problem.
I have two threads, each controlling a different serial device. The serial configuration is accessed through a dialog which I stole from a QT example (the terminal). Each thread has an instance of this settings dialog. It seems that something goes wrong when selecting the port - for instance all the selections in the dialog actually point to the same COM port if checked in a debugger.
Anyway, I chalked this up to non-thread-safe code and changed the program to just ask for the serial port name as the data rates, stop bits, parity, etc are fixed by the hardware and aren't going to change. This has fixed the problem.
There are two possible answers, I think:
Your process doesn't terminate in spite of you closing the main window. How have you verified that the process is, in fact, terminated?
Your use of qt's serialport module exposes a bug in FTDI's driver. That's not unthinkable, but I'd call it a remote possibility at the moment.
Personally I don't see any use for the serial port emulation of the FTDI driver, it's adding an extra layer for no good reason. The D2XX interface is the way to do it, if you don't want to use something like libftdi. On Windows, I've found D2XX and libftdi to be the only viable alternatives, with libftdi working much better than D2XX on virtual machines.
Don't know if this could be useful.
I have a similar issue (but not the same) with a prolific pl2303.
In my case when i close the port (or even at startup, before opening it!), data is received anyway somehow and presented immediately when i open the port.
This happens only with an usb-rs232 adapter, if I use the ttyS0 (physical serial port) the problem does not appear.
The solution for me was forcing QSerialPort::clear() to clear buffers just after QSerialPort::open(). This avoids signal readyRead to be emitted and thus unwanted data to be received.
I have an application in windows, that opens a com port. It attempts to call a comport, then fails and prompts me with an error.
The issue is this is very legacy software that we no longer have the source code for. I'm wondering if anyone knows of a way that can trace, or follow a program calling a com port to find out what com port its attempting to allocate.
Appearantly you can use Process Explorer (as called out in this post) to search for processes using serial ports. It sounds like you should be able to use the same searching concept called out the other post to find what you need.
I actually gave up on this solution and re-wrote the entire program in a week, it had to be done due to binary compatibility issues with the PCI cards.
In Windows XP (SP2 if necessary), is there any way to detect, from a userspace application, that a TCP/UDP socket (from any process) has opened? I know of the GetExtendedTcpTable() and GetExtendedUdpTable() functions, but they only detect currently opened sockets. Some sockets close immediately after they're opened that the only way I'd be able to detect their existence is by being notified when they open.
If no such a mechanism exists in userspace, I'm willing to go into kernel space to get this functionality. Are there any documented/undocumented features that could do this?
You will likely need to write a WinSock LSP or SPI driver in order to detect that without having to hook every running process directly.
I am trying to make U9 telit modem send SMS messages. I think I handle protocol correctly, at least, I manage to send them, but only under these circumstances: the native application was executed beforehand, and killed by task manager (without giving it a chance to initialize things).
It looks like the supplied application is good at doing certain initialization/deinitialization which is critical. I also see the difference between the two states in output of AT+CIND command. When I am trying to do things on my own, it returns zeroes (including signal quality), but when I run the same command after killing the native application, the output looks reasonable.
I am out nearly of ideas. I have tried many things, including attempts to spy at modem's COM ports (didn't work). Haven't tried setting windows hooks to see what the application is trying to get thru.
Perhaps you have encountered a similar situation?
Agg's "Advanced Serial Port Monitor" actually helped a lot. Sometimes it caused blue screen, but it helped uncover secret commands which seem to help. AT+PCFULL is not described anywhere on the net, for example. The real trigger of non-operatio was AT+CFUN, the power disable/standby feature.
Also, it appeared that we have more issues. At first, the modem appears on the bus only as disk drive. It doesn't want to appear as any other devices before the drivers are installed. So, the U9 Telit software sends an IOCTL to disk driver to tell the modem to reappear as more devices (modem, 3 serial ports, another disk drive).