Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have one computer that is running a c++ program to control a robot and another computer that is running a computer vision system (also written in c++). I would like for these two programs to be able to talk to one another. The communication would not have to be complex, I would just need the robot computer to be able to tell the vision computer when a trial begins and ends (when to start and stop a data collection sequence). Do any of you have advice on how to approach this problem? Rs232 communication between the computers? Some kind of networking solution? smoke signals? Any suggestions would be welcome.
thank you in advance
(edit) In case you think the statement above is vague:
I need to pass a binary (go/don't go) signal from one computer to another. Unfortunately I can't be more specific about what this will look like because (obviously) I don't know what is available. Both computers are on a network, and both computers are running windows. The goal is to syncronize data collected by the computer vision system with actions performed by the robot. The communication does need to be fast enough that it will not slow down either the robot or the computer-vision program. a "good" solution would be 1) easy to implement 2) fast. I do not know much about networking and I am looking for a place to start looking.
thank you again for your assistance
You might use a simple UDP protocol - the advantage being that if you understand the concepts of simple packet protocols on RS232 you'll find it easy to transfer that knowledge to sending the packets via UDP.
If you want a reliable (as in, other parts of the system will worry about errors and retries) stream of bytes between the two PCs, then TCP/IP is not much more complicated to use than UDP.
Both UDP and TCP are accessed through 'sockets'. I'm afraid you'll find that from C++ there is rather a lot of tedious boilerplate to getting that working, but there are lots and lots of examples around.
If they are network-connected you could just use sockets.
The best option will be to use network communication. The easiest way to approach this should be to look at the networking examples in Qt.
You basically will create a client and a server application. You decide what the client does when it sees a certain message from the server. That's all. Qt should take care of the rest of the stuff.
Other answers suggests TCP/IP, UDP, RS232, ... All those things are just options when you use QtNetwork module. I assume that since you ask your question, you don't know about the difference between those. So the safest bet will be to use the highest level (free) library, hence the suggestion to look into Qt.
Another option is to use Boost.Asio. I tend to prefer Qt solution since their API is nicer.
That sounds like a fairly good use for the network socket. If both your machines are on Windows you can even use named pipes.
For Windows, you will need to open the COM n port as a file to communicate over a serial port[1]. I don't have access to my code now, I can look it up when I get home.
RS232 is easy and I like it. However, it it is slow. You need to consider that in your design.
[1] For C++.
Most modern computers have Ethernet capability, so get yourself a cheap hub or switch and look at networking APIs. There's usually some fairly easy socket stuff. One advantage of this is that, if you want to increase communication ability later, such as having your vision software provide instructions and guidance to your robot, you've got the basics set up.
Alternately, set up your vision program so you can start and stop it by hitting random keys. When you're going to use it, put the keyboard in front of the robot computer's CD drive, and eject at the start and end of the robot run.
This may be overkill in your situation, but if I were in your shoes I would probably implement it using the HTTP protocol. The vision computer would run a HTTP server and the robot computer would communicate the state changes using POST requests. The Poco C++ Net library provides you with the facilities required to do this.
I would use a TCP/IP socket for communications. TCP guarantees that the data will make it. So, all you need to do is parse the data.
RS232 is an easy option to program for, however modern PCs don't tend to have RS232 ports. You may need to get USB-RS232 adapters or install a PCI card.
The other problem with RS232 is that you have an additional wire to worry about which can be a nusiance. Also RS232 cables can be limited in length (5-15m) unless you invest in some clunky RS232 repeaters or bluetooth connectors, etc.
On top of all that you're also adding one more item to your project that can go wrong and cost you time in deploying and debugging.
IMO, an elegant engineering solution would be to utilise the hardware that you have and use TCP/IP sockets to communicate.
The web is awash with examples on passing messages between servers and clients:
If you're using Linux:
http://www.linuxhowtos.org/C_C++/socket.htm
Using Windows:
http://www.adp-gmbh.ch/win/misc/sockets.html
I also might look at something like 0MQ to make the connection more robust. It will transmit and reassemble messages regardless of the transport, and handle buffering in the case of temporary loss of connectivity.
But the bottom line is that I would use TCP/IP, but depending on the nature of the robot you may want a slightly more robust connection system than TCP sockets. UDP is nice because it's connectionless-- if the robot temporarily travels out of range/sight/etc you wont have to rebuild the socket and context.
Related
I am currently working on the design of a measurement system. It has a three instruments mounted on a pan/tilt head, but only one serial line from the instruments to the Beaglebone Black (BBB) that controls everything. Instrument A and B are similar (use the same commands and module). I'm using Python to control everything. During testing, I had additional cables so that I could wire each instrument to a separate port on the BBB, but that is not possible in the final setup.
Since I needed some processing capabilities on top of the pan/tilt head anyway, I'm using a PIC24 device to connect all instrument serial connections to.
My idea is to multiplex the 3 serial connections, for instance by adding a prefix A_/B_/C_ to the commands/replies.
This I can do.
Communications and processing for instrument A and B is done by the same Python module, which has a function measure() that takes the serial port (ie. /dev/ttyO4) as one of the parameters. I'll obviously need to adapt this.
I need to find a way to allow different modules to access three "virtual" ports, with the choice of either stream A/B/C.
So in short: I (think I) need some kind of class/... that opens the serial port and multiplexes/demultiplexes three streams. Instrument A and B are not to be used simultaneously, but A/C and B/C can be used at the same time. Timing is not critical, a couple of hundreds of milliseconds delay is not an issue.
One option would be to use a second PIC to do the reverse of the microcontroller near the instruments, but I suppose this should be possible in Python as well...
I think the elegant solution is to add some code for your PIC to work as a Modbus slave.
There seem to be good efforts already done, so maybe you can use something like this as a starting point.
You can have the three UARTs connected to the sensors continuously writing to several Modbus registers and query those from your BBB with something like pymodbus or pylibmodbus.
It will also be possible to use other buses/protocols like CAN, but if you run Modbus directly on the TTL UART (instead of over RS485, which you won't need unless you have long distance or a noisy environment) you don't need any additional hardware. You will have to modify the firmware on your PIC and write some more lines of Python on your BBB.
But if you want to learn something new (assuming you don't know already), Modbus is quite an easy and useful protocol to add to your toolbox. It's still very popular and open (the spec is publicly available and you have tons of info and code).
EDIT: I'm keeping my first answer as a reference for others, but the question did not refer to sharing the same physical cable for multiple ports so what I wrote here is not really useful somebody misunderstands it the same way I did.
This question has come up a number of times, see for instance Receiving data from multiple devices using parallel wired RS232
Serial lines are not intended to be multiplexed, if you decide to follow this route I think you'll get many headaches.
Is there a reason not to use a multipoint protocol like RS485, SPI...? I'm sure you'll be able to find one that works for your needs. For RS485, for instance, the
investment in new hardware would be minimal and the software side would be a piece of cake.
I am implementing a messaging system using C++ and Qt. After much thought, I have determined that multicasting or a multicast-style technique will work best to solve my problem. However, I have learned about UDP's unreliability and believe it to be unacceptable.
My requirements are as follows:
Messages are to be sent in a binary serialized form.
From any given node on the network, I must be able to send messages to the other nodes.
Message delivery must be insured.
I have heard of OpenPGM and NORM as alternatives for UDP. If anyone has experience with either of these, could you please share?
I am also open to the possibility of implementing "reliable" multicast by myself, in the application layer, but I would prefer not to if there is a library that already implements this.
I am using C++ and Qt, therefore .NET or Java-based solutions are not acceptable unless they are open-source and I may port them to C++.
Thank you very much.
EDIT 20120816T1853 MDT: An additional question: would either PGM or NORM have to be implemented at the hardware/IP level? Or can they be overlayed on top of existing protocols?
We have implemented our own reliable multicast protocol over UDP called RSP, since we needed something cross-platform and at the time couldn't find a good solution between Linux and Windows. The Windows PGM implementation disconnects slow clients which leave the send window, whereas our implementation throttles the sender similar to TCP. Afaik OpenPGM can be configured to do the same.
The open source NORM at http://cs.itd.nrl.navy.mil/work/norm can be built as a library and has C++ API with Python and Java language bindings. If you ping the developer (me) via the mailing list, I can help get you started.
There is a large RFC division of reliable multicast protocols, and many implementations out there. It's a long time since I looked at this but there are TRAM, LRMP, ...
My main goal is to create an advanced program for manipulating the packets that route within my network via the router. Let my program have total control over the router. Set the download/upload speeds to my inputs, apply the effect to certain devices within in my network. Block upload or download traffic. Set second delay for either the upload or download speed. Specify % of loss packets, and the list goes on.
The problem is that I don't know where to start. I know most languages at the very most basic level. I'd like to create this program in either C, C++ or C# but I don't know yet. What else do I need to know before creating this program? Winsock or something? Winpcap APIs?
This goal is my motivation to learn programming to the extreme, and I'm really looking forward to it.
Thanks in advance!
Hmmm I guess you would want to look at pcap(?):
pcap
Check out:
http://beej.us/guide/bgnet/html/multi/index.html
'Beej's Guide to Network Programming
Using Internet Sockets'
All you could possibly need to know about programming sockets for capture and manipulation.
If I were you I'd write it in C, I'm writing a similar project at the moment in C++ and it's hell but too late to stop and start again.
Hope that helps.
Bear in mind that you either need a router that you can re-program or you need to use your PC as a router to do this.
Either way you want to look into how IPTABLES are implemented.
I've never seen Desktop Windows used as a router only Windows Server, though it may still be possible. libpcap is for packet capture, but not interception as I understand it. Programs like Wireshark use it to monitor copies of packets, but not to modify them. If you want to attempt this, my impression has been that there is a lot more documentation and tools for doing something like this with NetFilter/IPTables on Linux. You can even install something like OpenWRT on a compatible router and get a small, cheap Linux router, though having Desktop Linux will probably help for development. The NetFilter QUEUE library can be used with some IPTables firewall rules to redirects specific (or all) packets to a regular user program. That program can then read the packet and modify it or even request it to be dropped.
http://www.netfilter.org/projects/libnetfilter_queue/
If you want to manipulate network traffic on a Windows machine (as you mentioned), you will need some extra software. This operating system wont give you the full control over itself, which is fine for some reasons.
I think what you want to do, should be done with either winpcap or win10pcap if you are using Win10. These packages contains a windows driver and the libpcap user space library.
In a few weeks I'm thinking of helping a project finish a pretty major aspect of a C++ world with 3D characters: networking. I will help with the server's transfer of information from/to clients. I already know C++ well enough. I just need to know what specifically I should know to do this and resources from which I could find this information. Thanks :)
as RageD said, it's a big difference in networking between different types of games. A FPS server typically sends complete game state to all clients regularly (e.g. 60Hz) over UDP. Other game types can use TCP (tuned a bit like TCP_NODELAY and forcing immediate ACK packets) or reliable UDP (raknet lib or others). Network protocol can become really wide so you'll need to think how to make it easily extendable. I'd recommend you to start from here: http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm currently working on a serial interfacing project based upon connecting to the rs232 port. However, seeing as a decent number of laptops and/or PC's seem like they might have their rs232 ports disappear within the next 5 years, I was considering using the RJ45 modular port for my project (EIA/TIA 568). However, I'm not quite sure how to denominate it when accessing the port through the Win32API (I'm programming in C++). It's currently programmed to "COM1". Does anyone know how I can find out what this port is called or how to configure it so it can be used in this manner?
I'm really confused... RJ45 ports on laptops/PCs are for Ethernet connections, aren't they? I don't understand how you could utilize one as a COM port.
If you need a serial port, and don't need ultra-low latency*, pick up a USB <-> RS232 converter, they run about $20-$30 and work just fine: from the PC software's point of view it looks like a regular old COM port.
*RS232 itself has low latency, but if you use USB as part of the serial connection, you're limited by the timing of its frames and how the USB serial converter uses them... I seem to remember USB has 1msec and 16msec frame timing; USB 2.0 appears to have 125usec microframes but I don't know if any of the serial converters manage to use them. You'd run into latency issues if you're using a command-response protocol in RS232 with lots of back-and-forth traffic.
The USB port has been starting to take over the duties of RS-232 for the last few years.
You should seriously consider USB as an interface for your project.
Oh, yes; that might seem like a ludicrously obvious statement -- "duh! nobody's been using Serial for a decade now".
Not so easy: there is a lot more than mice and printers out there.
RS-232 has been the preferred interface for custom-build devices, scientific instruments, and low-production devices far long after everybody started using USB for mice and high volume consumer devices.
My most direct experience comes from amateur astronomy and accessibility computer accessories for the visually-impaired. Until not too long ago, all of the above were still mainly RS232 devices, and a common headache has been finding a way to plug those in a modern laptop. RS232-to-USB consumer adapted will sometimes work, sometimes not. At least one manufacturer of accessibility devices (a braille embosser) has stated to us that they don't recommend RS232-to-USB adapters because they have had (unspecified) problems with them.
I don't know the cause. Maybe USB components are more expensive, maybe it's the need to interface with legacy devices that would be expensive to redesign; maybe it's what the engineers know. Maybe it's just "ain't broken, don't fix it" or simple inertia.
It's only been in the last couple of years, but I've finally seen a number of these devices offered with USB ports instead of serial RS232; in some cases, RS-232 versions have been discontinued. It's just taking a little longer.
On the meta level, what you want to do is a bad idea. You're inventing your own standard for hardware, in a manner which is wholly inconsistent with established protocols.
You are much better directly using either USB or a DB-9 connector with RS-232. RS-232 is really quite good, but it's getting outdated(unfortunately, it's much simpler than usb).
For salable products, you'd want to have both. For researchy/geek products, USB is much better.
You should be able to enumerate your com ports from Windows and open a given com port as a file(I've done it).
The RJ45 port you are referring to is an Ethernet port, not a serial port.
If you are looking for a more current technology, you should investigate the USB interface. If you really want Ethernet, you might be interested in the XPort from Lantronix.
-- Edit --
What type of device are you looking to use as a host?
You're worried about an aging but common standard (RS-232) going away, but you're going to use a non-standard, that never was?
The documents you refer to appear to be an alternate wiring method for a typical RS-232 port.
By the way what you're referring to as RJ-45 is a wiring standard not an interface. RS-232 can be connected via DB-9, DB-25, RJ-45 or screw terminals. The voltages and signaling are part of the protocol. The connector type is determined more by convenience.
Most computers use an RJ-45 for ethernet. The only time I've seen RJ-45 connections for serial connections was on networking equipment or terminal servers.
http://site.gridconnect.com/docs/PDF/xportmanual.pdf
you mite get some ideas from reading this manual.
the way this manufacturer communicates with the product is by the rs-232 port on the camera and the Ethernet connection. the plug combines both the software to connect and the plug with samples.
Although I would like to have this setup , I am trying to make it myself rather than buying it.
You may just consider buying the product and just shairing back to this thread the way they comuncate and the wireing of the plug or at least the fact that the conversion from serial to lan a valid solution.
I am also with a laptop that I want to talk to a CNC machine by way of rs-232 (25 Pin serial) and the LAN connection on the laptop.
It is not about keeping the past alive or saying whitch standard is better or worse than another.
It's about being able to run the CNC machine with the laptop and How to wire the RS-232 to the LAN 45rj - nine pin connector on the laptop and what software to use to make it happen.
::::::NOTE::::::
Also I wish to have the ability to use a Microsoft sidewinder joy stick that uses another connection ; a """" A Game Port """"" another failed attempt to make things easier. Run the CNC for use as a CMM or Computer Measuring Machine.
A little known fact is that people should only give information , if they know what they are talking about.
Correct me if I'm wrong, but does the Yost wiring standard not allow one to connect to an RJ45 port in order to do serial communications?
http://yost.com/computers/RJ45-serial/
http://www.lammertbies.nl/comm/cable/yost-serial-rj45.html
All I'm wondering is how to actually access the port from the win32 API. Am I terribly off base here?
– Nicholas Sullivan
Maybe you are thinking about something like this...
http://www.comtrol.com/products/specifications/30130-1
Julianno Jungle