Serial to Ethernet Device Servers on Linux

Hello there!

I am new to low level programing. I have a Moxa 5232 Device server. I have a rs485 device that I like to be able to access from a Linux computer. It is a 2 wire 1/2 duplex rs485 enabled device.

After installing the Moxa drivers I have a "/dev/ttyr00 & /devttyr01" devices/ports on my Linux server.

In order for me to access this device, I wrote a C program. It basically opens the port and then writes some ASCII text to the port. If I send H-E-L-L-O the device should respond with a H-I and vice verse.

The trick is, since it is a 1/2 duplex I need to be able to send the initial text and then flip the line so that I could receive the data. If I don't receive the data with in 100ms then I have to resend the initial text again.

Is there any sample codes available for C on the net. I have been searching for the last 3 days and I am having no luck with it. Unfortunately Moxa does not have any sample codes on their web site and their tech support is not the greatest. I think they are more into the windows side than Linux.

Please let me know of any sample codes or ideas that I could make use of. Thanks in advance for all of your helps :)

CM23

Reply to
pesinc
Loading thread data ...

I don't know your kernel version, but maybe the comments here help:

formatting link

If they don't, how about flipping DTR and RTS via moxa_tiocmget()? $ man termios could help, too.

Regards,

Phil

Reply to
Ph. Marek

[...]

The hardware ought to be doing that for you. All of the other network-attached RS-485 devices I've used handle the line direction automatically. If the Moxa doesn't, toss it in the bin and get something decent.

formatting link

Another good reason to toss it and buy something decent.

If the device server doesn't turn the line around automatically, you've got little hope of doing it yourself. The Moxa device _might_ be using RTS to control the line direction. If so, you can control RTS using TIOCM* ioctl calls shown in the reference above. But, that's not reliable even on locally attached devcices due to latency issues. It's going to be even less reliable over Ethernet.

--
Grant Edwards                   grante             Yow!  Is it NOUVELLE
                                  at               CUISINE when 3 olives are
                               visi.com            struggling with a scallop
                                                   in a plate of SAUCE MORNAY?
Reply to
Grant Edwards

other

net.http://www.easysw.com/~mike/serial/serial.html

doesn't turn the line around

Reply to
pesinc

And the problem is ?

Any decent USB-to-serial or Ethernet-to-serial RS-485 device will do that in hardware at the converter. Due to the varying network delays, there would be a very large uncertainty about turning the transmitter off if controlled by the host computer (in fact you would have to readback the transmitted bytes to see when your transmission actually stopped, before commanding the line to Rx mode).

That Moxa converter contains what they call "Automatic Data Direction Control" (ADDC) which is controlling the Tx when there is actually something to send. You do not have to bother about the line turnaround in RS-485 mode, just throw the converter with a stream of bytes in the TCP mode and then start reading bytes from the other system.

Paul

Reply to
Paul Keinanen

Thanks Paul for your reply. I have been working on this issue and I don't know if the ADDC works right on the Moxa. When you are dealing with a slow serial network @9600 baud it seems to be working fine, As your speed increases the performance of the ADDC goes down as well. Well, that is what I have been seeing with my loop back test, it could be very well related to my ethernet network.

I am looking for a good sample application in C to test this, any suggestions? I have been using the Linux "cu" utility for my loop back test.

Reply to
pesinc

That is quite expected, since the TCP/IP stack delays are in series at both ends, which drops the half duplex performance.

With some Moxa converters, you may be able to do a single transaction (send+receive) in about 5-10 ms at the highest speed and short messages, while some other converters may have 50-100 ms transaction times.

A good PCI card master may be able to perform the transaction in 1-2 ms, since no TCP/IP or Ethernet overhead is involved.

Paul

Reply to
Paul Keinanen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.