locked
I think I need to build a port replicator - how do I do that? RRS feed

  • Question

  • Greetings.
     
    I am building an application to read data coming from a serial com port.  However another application requires the same port and grabs it before my application can connect to it.

    If I create (something) to read the com port and replicate the incoming data to multiple (virtual) ports, I think both applications will be able to use the incoming data.

    The next question is... How do I do that?

    Can someone show me some code or point me to a example application that does something like that?

    I have used the Net.Sockits libraries to read and display incoming data, but how do I create and write out the data to the other newly created ports?

    Your help is appreciated!
    Bob
    Saturday, January 17, 2009 5:24 AM

Answers

  •  I don't think you'll be able to do this with any sophistication without writing your own virtual serial driver (a task that .Net is not suited for).

    Your proxy application would be much like the windows bluetooth manager; it would gather serial data (from a physical serial port, as the bluetooth manager gathers from a wireless socket), work the data to decode or re-encode as appropriate, and then relay to the virtual serial ports created by your driver (again, as the bluetooth manager directs data to it's virtual com ports).

    While the Proxy application could be written in .Net to run as a service and could then communicate with the driver, the driver itself would probably have to written in a flavor of C (but not C#).

    Now, since driver development  is a ball of wax all of its own, there is a much less sophisticated "work-around", if you will; not that it's a great work around or easily implemented, but here it is anyway:

    With 4 serial ports (you will likely need a good multiport USB-Serial adapter; I would recommend a solution from SeaLevel Systems) , and a short female-female "Y" serial cable (you may have to construct one - RadioShack has everything you need, though not at the best prices), and a .Net proxy application (secondary application to the one you actually need to create) you could accomplish this as follows:

    Assume COM ports are COM1 thru COM4

    1.  Connect device whose data is to be captured to COM1
    2.  Connect "Y" cable from COM2 (single end) to COM3 (dual end) and COM4 (dual end)
    3.  Configure the other existing application to look for the device on COM4
    4.  Write a .Net proxy application (with 2 SerialPort components) to read all data on COM1 and write that data to COM2

    In this way, so long as the proxy application is running, any data received on COM1 will be sent out COM2 and then via the "Y" cable, that data will come into both COM3 and COM4.  So now your application can be written to connect to the device data on COM3 and the other existing application can be configured to connect on COM4. 

    The proxy application should effectively be able to relay data between ports.  While this should work ok for reading the device data, it may take more work to write back to the device.  If it is necessary to write back to the device, particularly for the other existing application, then the proxy should be written to forward data from COM2 to COM1.  But only the other existing application can use this.  Your application cannot write back in the same way because there would be no way to prevent both applications from writing at the same time and corrupting each other's data (because of the "Y" cable).  If your application also needs to write back to the device, then you should use another method (such as Remoting or IP Sockets) to communicate between the proxy and your application.  That way the proxy can queue incoming data from both the serial port (other existing application) and from your application and control sending/receiving data between the two.

    So the level of complexity depends on exactly what you need to accomplish, but the above should be a general start in that direction.  Note that you're probably looking at a few hundred dollars worth of hardware to make this "work-around" effective.  While you can get cheap USB-Serial adapters, they will be software based and may not work with all devices.  For anything of production-quality you need to use hardware based adapters, and those are more expensive.

    I know none of this is a great answer (sorry for that) but I hope it helps get you going toward a solution.
    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"
    • Marked as answer by Bob Pokorny Monday, January 19, 2009 3:34 AM
    Saturday, January 17, 2009 5:38 PM
    Moderator

All replies

  •  I don't think you'll be able to do this with any sophistication without writing your own virtual serial driver (a task that .Net is not suited for).

    Your proxy application would be much like the windows bluetooth manager; it would gather serial data (from a physical serial port, as the bluetooth manager gathers from a wireless socket), work the data to decode or re-encode as appropriate, and then relay to the virtual serial ports created by your driver (again, as the bluetooth manager directs data to it's virtual com ports).

    While the Proxy application could be written in .Net to run as a service and could then communicate with the driver, the driver itself would probably have to written in a flavor of C (but not C#).

    Now, since driver development  is a ball of wax all of its own, there is a much less sophisticated "work-around", if you will; not that it's a great work around or easily implemented, but here it is anyway:

    With 4 serial ports (you will likely need a good multiport USB-Serial adapter; I would recommend a solution from SeaLevel Systems) , and a short female-female "Y" serial cable (you may have to construct one - RadioShack has everything you need, though not at the best prices), and a .Net proxy application (secondary application to the one you actually need to create) you could accomplish this as follows:

    Assume COM ports are COM1 thru COM4

    1.  Connect device whose data is to be captured to COM1
    2.  Connect "Y" cable from COM2 (single end) to COM3 (dual end) and COM4 (dual end)
    3.  Configure the other existing application to look for the device on COM4
    4.  Write a .Net proxy application (with 2 SerialPort components) to read all data on COM1 and write that data to COM2

    In this way, so long as the proxy application is running, any data received on COM1 will be sent out COM2 and then via the "Y" cable, that data will come into both COM3 and COM4.  So now your application can be written to connect to the device data on COM3 and the other existing application can be configured to connect on COM4. 

    The proxy application should effectively be able to relay data between ports.  While this should work ok for reading the device data, it may take more work to write back to the device.  If it is necessary to write back to the device, particularly for the other existing application, then the proxy should be written to forward data from COM2 to COM1.  But only the other existing application can use this.  Your application cannot write back in the same way because there would be no way to prevent both applications from writing at the same time and corrupting each other's data (because of the "Y" cable).  If your application also needs to write back to the device, then you should use another method (such as Remoting or IP Sockets) to communicate between the proxy and your application.  That way the proxy can queue incoming data from both the serial port (other existing application) and from your application and control sending/receiving data between the two.

    So the level of complexity depends on exactly what you need to accomplish, but the above should be a general start in that direction.  Note that you're probably looking at a few hundred dollars worth of hardware to make this "work-around" effective.  While you can get cheap USB-Serial adapters, they will be software based and may not work with all devices.  For anything of production-quality you need to use hardware based adapters, and those are more expensive.

    I know none of this is a great answer (sorry for that) but I hope it helps get you going toward a solution.
    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"
    • Marked as answer by Bob Pokorny Monday, January 19, 2009 3:34 AM
    Saturday, January 17, 2009 5:38 PM
    Moderator
  • Reed -

    Thank you for the response.  I was actually thinking of doing something like that  (building some sort of appliance) to split/share the CO port.  Unfortunately, I'm not sure that is the direction we want to take.

    After countless houes of searching the Internet, I have found software port replicators, some say they can be integrated into our application.  I may have to look at that solution and see if that will resolve our problem.

    Thank you for help.

    Bob

    Monday, January 19, 2009 3:33 AM