Author Topic: Serial Port software splitting method  (Read 7457 times)

roshan.ok

  • Member
  • ***
  • Posts: 3
Serial Port software splitting method
« on: March 09, 2013, 01:03:12 pm »
Hi All,
I am working on Hardware automation . Where the hardware has various components and each component communicates via serial port(rs232).
my approach here for automating the devise is that, i will have hardware and component communicate to each other via my laptop, so that i can control the messages that flows in between the hardware(master) and component(slave)
for example, if you consider ATM , ATM is a master and say Reciept dispenser is a component (slave). Internally they are coomunicating through serial port. Now, i will connect the one end of the Master port(that connecting to Slave) to my Laptop using an USB-Serial port device(say to com1).
Same way i connect the Com2 of my laptop seria port to the Slave.
Now the design is that, when you perform a transaction at ATM, the ATM sends the message to my laptop at Com1 . And my software in laptop reads the message from com1 and writes to com2(ie the slave). And vice versa. This wayany communication that master does is written to slave, and response from slave is written to master)

Now, challenge here is that, with this approach, i am able to read and write data to the master and components. But i am not successfully able to bring up the hardware. it works sometimes, it doesnt works some times.

As of now, i would like to know if my approach is a possible way to establish the right communication between the master and slave?
if no, what could be the challenges, and can it be handled programmitically. Please help me solve the puzzle.Thanks in advance

Thanks


Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 2803
    • Lakeview Research
Re: Serial Port software splitting method
« Reply #1 on: March 09, 2013, 01:24:29 pm »
Yes, you can use two serial ports on a PC to communicate with two devices.

I don't know what you mean by "i am not successfully able to bring up the hardware."


roshan.ok

  • Member
  • ***
  • Posts: 3
Re: Serial Port software splitting method
« Reply #2 on: March 09, 2013, 11:41:04 pm »
Oh thats great to know. thank you very much.
Well i am not able to bring the hardware up means..
when the ATM is turned on, it does the initialization with the Reciept dispenser. When it does, it sends and recieves numerous data to and from the reciept dispenser.
In my case, my software in the laptop will actually reads the data from com1(master) and writes to the com2(slave) and vice versa.

i could see that there is reading and writing happening between the devices, but when i perform a transaction at ATM, it says Reciept dispenser is Down.

Please let me know which of the following could be possible reason(my assumptions)
1. The software that i have written is not properly synchronized with the 2 devices?
2. There is a difference in the way Hardware communicating with wired cable and hardware communication between Laptop software.

or anything that could be other than my assumptions.

Thanks


HDowns

  • Member
  • ***
  • Posts: 14
Re: Serial Port software splitting method
« Reply #3 on: March 10, 2013, 03:18:07 am »
Is it possible you need to synchronize hardware flow control lines (RTS/CTS)?

roshan.ok

  • Member
  • ***
  • Posts: 3
Re: Serial Port software splitting method
« Reply #4 on: March 10, 2013, 06:34:45 am »
but as per the device settings the flow control is set to None.
Hence i have not used the RTS synchronization? any comments please!

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 2803
    • Lakeview Research
Re: Serial Port software splitting method
« Reply #5 on: March 10, 2013, 12:19:15 pm »
OK, so as I understand it, the two devices normally connect to each other directly, and you have added the laptop so you can capture, but not change, the data. And you've written an application that sends all received data to the other device.

If it works sometimes, the problem might be in timing. For example, if device 1 sends data and expects an immediate response from device 2, the delay in having to resend the data to device 2 might cause device 1 to resend data or take other action. If you can decode what the devices are sending, that might be helpful.

Maybe a serial port monitor would do what you need (scroll down):

http://lvr.com/serport.htm#software