I've got a windows 7 machine with numerous physical serial ports going into it and I would like the information coming into the machine to be read by multiple pieces of software at the same time. My first idea was a physical serial port splitter, however, this isn't viable as it may not have enough power to be split even once let alone multiple times.
So the next idea is to open a physical serial port on the computer and read everything coming through and then send that data to one or more virtual serial ports and then those virtual serial ports can be opened by individual pieces of software. After some research, I found a few pretty basic solutions which got my hopes up but they require "pty" which upon further research and a few "ModuleNotFound" errors I discovered this is for Mac Os only.
Is there any pty equivalent for windows or really anything that will make this possible? And if not is there something that is viable on Java or C++?
Related
I have a data buffer of data on my Serial port. This communication is developed in order to transfer the "maximum" value of possible data. Hence, the value of samples "send" if there is no connection with a computer is around ~11500 data/sec. If I attach the controller (who send the data) on a Windows 10 machine and I try to read (with java) the data, the information frequency drops down to ~ 950/1000 data/sec. Otherwise, if I attach the controller to the same machine, with the same software, but under Ubuntu, it reaches ~6000/7000 data/sec. So, there is a way to improve the Serial port under Windows?
If you are using a cheap USB-serial port, it is possible it only works at USB1 speeds, and/or the driver is basically a rebadged device driver demo from the Windows SDK (which is very poor). More expensive USB ports generally have their own drivers which are much better at higher data rates.
It is also possible that there is some sort of hardware flow control that isn't quite as efficient on Windows as it is on Linux.
Without knowing exactly which USB port you have, it's difficult to make suggestions.
In the world of printers, particularly the POS ones, there are two common approaches, OPOS and Windows print queues. And there's also the work-around like the virtual serial port. But there seems to be another approach out there too ... the driver is installed but the software seems to be writing directly to the port rather than using the windows spooler.
If you look at the spooler ports when an Epson USB printer is installed for example, there is a ESDPRT001 ... could it be that the POS app is writing to the port directly and bypassing the whole spooler?
According to Epson's product description of OmniLink no driver is required. It is quite possible that the spooler has been outsourced to the powerful onboard computer, which is operating at ~400Mhz. Just a guess.
You don't need a driver for Epson's OmniLink. If your spoolsv.exe isn't working, look into this though.
Can the Windows COM port be used by two programs running on the same PC for inter process communication? Our ultimate goal is to write a program which communicates over COM port to control a hardware. Since the hardware is not available we want to emulate the hardware in a program which reads from a virtual COM port and responds.
A trivial emulator would be a program which waits for bytes to be read from the COM port and responds by writing on to the COM port. To start with the values of these messages can be hardcoded.
So what I do is I have two programs written in C/C++ using the ReadFile, WriteFile functions given by windows to read and write over the file. This approach will not work because of access conflict. Hence I was wondering if our approach for the emulator itself is wrong.
I am new to Windows based programming though I have programming experience in other areas. Any help would be greatly appreciated.
Update:
Solution:
Installed Virtual Serial Port Driver 7.1 by Eltima Software (trial version)
Added a pair of virtual ports (e.g. COM1 and COM2)
The controller program communicates through COM1
The emulator program communicates through COM2
Eltima software takes care of transferring the data between the two ports
You can open a file with sharing parameters that allow both of the processes to read/write to it. But that's not a good solution, because reading/writing serial port has a number of differences with reading and writing to a file.
Instead I recommend to get a virtual COM port driver (like com0com.sourceforge.net, or select another from here en.wikipedia.org/wiki/COM_port_redirector). Install it, create two COM ports and connect them virtually. That way you will be sure that your program will work on real COM port too.
If that solution is not acceptable look into using pipes rather than a file
I have a Arduino app that needs to talk to my PC across the USB (Serial) connection. I have this bit of code that I lifted from the Arduino Playground at
http://arduino.cc/playground/Interfacing/CPPWindows#VisualStudio2008
this->serialPort1->PortName = "COM5"; // Replace with your COM port!
this->serialPort1->Open();
this->serialPort1->Write( "7" ); // In the future, you'll expand on this
// to write your custom data to the board
this->serialPort1->Close();
My question is how does one determine what COM port the Arduino USB cable is attached to?
There are several ways you can approach this.
The most obvious is that you simply make your application configurable and tell it which serial port to use. The port name should never change, unless you have other processes on your machine allocating virtual COM ports such as Bluetooth drivers.
A second option is that you can do what the Arduino app does and scan the serial ports on the system looking for the hardware. Since you are using the CLR, System.IO.Ports.SerialPort.GetPortNames() will give you a list of all the serial ports on the system. (You can also get this from the registry.) Then you can enumerate through them and check the status of the pins to see which serial ports have devices attached. You should probably include in your sketch a way to query the Arduino so that you can send it a command and have it give a fixed response. This would allow you to discern your application from other serial devices such as modems.
There is a third option which would involve figuring out where the FTDI driver stores its configuration information in the system/registry and going from there. This is a bit more involved, so I can't give any information on if this approach is even viable.
I'm developing a project that has a number of hardware sensors connecting to the deployment machine through RS232 serial ports.
But ... I'm developing on a machine without an physical RS232 serial ports, but I would like to make fake serial ports that I can connect to and output data from with the aim of faking input from hardware sensors.
Does anyone know of a way to create a fake serial port and control it on Windows XP?
If you are developing for Windows, the com0com project might be, what you are looking for.
It provides pairs of virtual COM ports that are linked via a nullmodem connetion. You can then use your favorite terminal application or whatever you like to send data to one COM port and recieve from the other one.
EDIT:
As Thomas pointed out the project lacks of a signed driver, which is especially problematic on certain Windows version (e.g. Windows 7 x64).
There are a couple of unofficial com0com versions around that do contain a signed driver. One recent verion (3.0.0.0) can be downloaded e.g. from here.
I know this is an old post, but in case someone else happens upon this question, one good option is Virtual Serial Port Emulator (VSPE) from Eterlogic
It provides an API for creating kernel mode virtual comport devices, i.e. connectors, mappers, splitters etc.
However, some of the advertised capabilities were really not capabilities at all.
EDIT
A much better choice, Eltima. This product is fully baked. Good developer tech support. The product did all it claimed to do. Product options include both desktop applications, as well as software development kits with APIs.
Neither of these products are open source, or free. However, as other posts here have pointed out, there are other options. Here is a list of various serial utilities:
com0com (current)
com0com - With Signed Driver (old version)
Yet another place for com0com with Signed Driver (Pete's Blog)
Tactical Software
Termite
COM Port Serial Emulator
Kermit (obsolete, but still downloadable)
HWVSP3
HHD Software (free edition)
I use com0com - With Signed Driver, on windows 7 x64 to emulate COM3 AND COM4 as a pair.
Then i use COM Dataport Emulator to recieve from COM4.
Then i open COM3 with the app im developping (c#) and send data to COM3.
The data sent thru COM3 is received by COM4 and shown by 'COM Dataport Emulator' who can also send back a response (not automated).
So with this 2 great programs i managed to emulate Serial RS-232 comunication.
Hope it helps.
Both programs are free!!!!!
There's always the hardware route. Purchase two USB to serial converters, and connect them via a NULL modem.
Pro tips:
1) Windows may assign new COM ports to the adapters after every device sleep or reboot.
2) The market leaders in chips for USB to serial are Prolific and FTDI. Both companies are battling knockoffs, and may be blocked in future official Windows drivers. The Linux drivers however work fine with the clones.
Another alternative, even though the OP did not ask for it:
There exist usb-to-serial adapters.
Depending on the type of adapter, you may also need a nullmodem cable, too.
They are extremely easy to use under linux, work under windows, too, if you have got working drivers installed.
That way you can work directly with the sensors, and you do not have to try and emulate data.
That way you are maybe even save from building an anemic system.
(Due to your emulated data inputs not covering all cases, leading you to a brittle system.)
Its often better to work with the real stuff.
i used eltima make virtual serial port for my modbus application debug work. it is really very good application at development stage to check serial port program without connecting hardware.