Re: reliable rs-232
On Saturday 10 April 2010 13:41:33 Grzegorz Daniluk wrote: Hi everybody, I have a question regarding rs-232 under FreeBSD. I need to write an application for FreeBSD to operate an industrial controller via rs-232. The trick is that it should have very good long term stability (reliably operation over years). It should be able to detect and correct (e.g by reconfiguration of rs-232 port parameters) when rs-232 hangs or changes its transmission parameters as a result of electrical interference/disturbances etc. First thought is to simply close and reopen rs-232 port every given time interval, so even if something 'strange' happens the failure would be fixed after finite time period. But maybe there is smarter way of doing that. Maybe some special fault-tolerant rs-232 kernel drivers ? Any help appreciated, maybe someone has other helpful advieces regarding reliable rs-232 programming ini general ? Hi Grzegorz, I dont think you are going to find anything that is classified as fault tolerant RS-232. My experience with 232 in industrial environments has been met with various levels of success. In small controlled conditions it works OK, but you are limited to speed and distance. Further, the single ended nature of 232 and the high input impedance of the receivers make it not the best choice for electrical interference rejection. If you have control of the electrical specifications, you might be better off using RS-422 as it is designed differentially and with a low impedance, so it works well in electrically nasty environments. All the better if you can opto-isolate the line drivers/receivers on the transmission line side of the interface. In one application, I designed a RS-232 to fibre-optic interface using S/Pdif transceivers and a 555 as a PWM generator/detector. This worked wonderfully for electrical isolation between the PC and the CNC motion controller I was interfacing to. I have seen similar things sold as a ready made brick that you could just plug in and use. Making the machine and PC Fail to a safe condition is not something you should design into the rs-232 interface directly, in my opinion. You should have a upper layer protocol bouncing between the two points and if this protocol times-out, then you should assume the interface of the remote device has failed and take action in your software (on both sides). In the case of the fibre connection, I added in addition to the protocol checks, a carrier detect circuit where if the link failed between the two machines, it dropped out a relay that was wired to the E-Stop circuit. I hope some of this is helpfull... Peg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: reliable rs-232
Thank you very much for all your advices. The device I'm going to 'talk to' is cesium clock with rs-232 interface. So it is not possible to simply change the interface to differential one. Connection cable can be short and the transmission speed can be slow. The most important thing for me is to ensure the long term communication. Not to lose any data is very important when periodically monitoring cesium parameters. We are speaking here about months and years of continous operation. That is why I'm afraid of something 'strange' happens to my rs-232 interface and communication. Maybe I'm too afraid of strange magic, but still, is it possible that my rs-232 could change its transmission parameters as a result of e.g. nearby elecrical interference ? Or, in general, what bad thing could happen to me in such scenario. Thanks a lot, Greg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: reliable rs-232
2010/4/11 Grzegorz Daniluk li...@o2.pl: Thank you very much for all your advices. The device I'm going to 'talk to' is cesium clock with rs-232 interface. So it is not possible to simply change the interface to differential one. Connection cable can be short and the transmission speed can be slow. The most important thing for me is to ensure the long term communication. Not to lose any data is very important when periodically monitoring cesium parameters. We are speaking here about months and years of continous operation. That is why I'm afraid of something 'strange' happens to my rs-232 interface and communication. Maybe I'm too afraid of strange magic, but still, is it possible that my rs-232 could change its transmission parameters as a result of e.g. nearby elecrical interference ? Or, in general, what bad thing could happen to me in such scenario. I've had to connect medical vital-sign monitors to ruggedized mobile computers over RS-232 and write the software for data collection. In my case, communication was packet-based and each packet had a 2-byte CRC16 field appended to the end, which made it rather easy to detect corrupt data. The goal was to have reliable communication for a period of a few weeks; the time between equipment inspections. The only real problem I ran into was that certain power events, such as attaching an external power supply to the computer or turning off the display, would cause the serial port buffer to overflow and corrupt one or two packets. This seems to be a peculiarity with the computers that we're using, since there was no actual data overflow, just corruption. I've tested everything using regular desktop machines and never had this problem before. For our purposes, the loss of a single packet is no big deal. The point is that the reliability of the connection depends on the equipment you are using. Use a shielded cable that's as short as possible. A ferrite bead on the cable might help eliminate high-frequency noise. Keep the cable away from power cables or supplies. The lowest usable baud rate should be less prone to corruption. Beyond that, there really isn't much you can do to prevent errors at a physical level. Obviously, be sure to configure your UART correctly (i.e. baud rate, bits per byte, parity bits, stop bits, and so on). I've never seen a UART reconfigure itself due to electrical interference, but it is possible for you to start getting framing errors if the clock synchronization is off. Here I don't really have any advice for you, except to test everything as much as you can in its final configuration. Avoiding buffer overruns is the responsibility of the software that you're using, but it can be affected by the OS. Consider the setup of your system. If you expect a high load on the CPU, be sure to give higher priority to the program that's reading data from the serial port. If the program is kept in the run queue for too long, you may start losing bytes (depending on how fast they are arriving and the size of the receive buffer). If you're doing some processing of the data as it arrives, consider running that code in a separate thread from the one that's reading the serial port. How to design reliable software depends on the protocol you're using. Test everything... If it runs fine for a week, it'll probably be ok for a month. However, I think that expecting the link to work for several years without a single corrupt bit is asking too much (if that is your goal). In general, when dealing with RS-232 the best you can do is detect an error using parity bits or checksum/crc values at the protocol level. Correcting errors after they happen could be difficult. When it comes to changing the interface type, you might consider using a serial-to-usb adapter. I've used those successfully with an early prototype of our system, but we later removed them to have a more secure physical connection. This may or may not be good advice for you. I'm just throwing it out there in case you start seeing corrupt data with a regular RS-232 connection. Adding a high-quality USB adapter (I used Tripp Lite Keyspan) means an additional buffer for sending and receiving data. It also means more hardware that can fail, which is why I say that it may not be a good option for you. Also, I was doing this on Windows and have no idea whether FreeBSD supports such setup. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
reliable rs-232
Hi everybody, I have a question regarding rs-232 under FreeBSD. I need to write an application for FreeBSD to operate an industrial controller via rs-232. The trick is that it should have very good long term stability (reliably operation over years). It should be able to detect and correct (e.g by reconfiguration of rs-232 port parameters) when rs-232 hangs or changes its transmission parameters as a result of electrical interference/disturbances etc. First thought is to simply close and reopen rs-232 port every given time interval, so even if something 'strange' happens the failure would be fixed after finite time period. But maybe there is smarter way of doing that. Maybe some special fault-tolerant rs-232 kernel drivers ? Any help appreciated, maybe someone has other helpful advieces regarding reliable rs-232 programming ini general ? Thanks for all help and advices. Best regards, Greg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: reliable rs-232
In freebsd-questions Digest, Vol 305, Issue 13, Message: 2 On Sat, 10 Apr 2010 15:41:33 +0200 Grzegorz Daniluk li...@o2.pl wrote: Hi everybody, I have a question regarding rs-232 under FreeBSD. I need to write an application for FreeBSD to operate an industrial controller via rs-232. The trick is that it should have very good long term stability (reliably operation over years). It should be able to detect and correct (e.g by reconfiguration of rs-232 port parameters) when rs-232 hangs or changes its transmission parameters as a result of electrical interference/disturbances etc. First thought is to simply close and reopen rs-232 port every given time interval, so even if something 'strange' happens the failure would be fixed after finite time period. But maybe there is smarter way of doing that. Maybe some special fault-tolerant rs-232 kernel drivers ? Any help appreciated, maybe someone has other helpful advieces regarding reliable rs-232 programming ini general ? RS-232 is inherently as reliable as the devices you're talking with, the protocols you're using for communication and the (lack of) interference from noise on cable/s in the environment you're operating in. Even in very adverse (noisy) conditions, I've never found any need to close and reopen ports to reinitialise hardware on freeBSD, back to version 2.2. If a byte of data is corrupted, it's just corrupted; I don't know of any conditions (given electrical signals within specification) that could cause a tty or uart port to require re-initialisation. So it comes down to detection of any transmission errors, either byte-by-byte using say parity bits, or by protocol (eg CRC) if using packet-oriented data transmission, and physical prevention of errors by such as shielded cables, avoiding earth loops between computer and device/s and so on. Perhaps you could provide a few more details about how the industrial controller is talked to, at what baudrate, cable length, software or hardware handshaking (eg CTS/RTS /or DTR/DSR) and whether byte-by-byte or using packet protocols, and such? Is the communication two-way? cheers, Ian (please CC me; I'm subscribed to the -digest which can take a while) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
