I have here a unit of King Pigeon S275 Remote Terminal Unit..
this RTU has communication modules for GSM, GPRS and TCP/IP (via RJ45 connection)
I can also communicate with this RTU by connecting it to my computer via USB .
The Manual I uploaded in this link...
https://www.mediafire.com/?gnfzfz5l7pess1p
This RTU can be configured using a configurator Software that is included in the purchase. By using that configurator software, you can also see the data/readings of all sensors connected to it, you can also see the status of all Digital Input/contacts connected to the RTU...
I have been researching about MODBUS the past days and I would like to create my own MODBUS program so that the S275 RTU can also send the sensors' data, or all the I/O data to my own program....
However ... I still do not know where I can start ...
Can I make this Modbus Program
1. using VB?
2. using PHP?
What other parameters do I need to know ?
and tutorials for making this modbus software...
I also uploaded here the S275's;
1. GPRS Custom Protocol
2. MODBUS TCP Handshake Communication Protocol
3. Register Address
https://www.mediafire.com/?khnfu53a4p12nrd
Thanks
PHP and ModBus sounds challenging. You want to control a serial port via PHP.
The easiest way is to get/purchase a library for ModBus/RTU.
Otherwise you have to implement the whole protocol by yourself from http://www.modbus.org/specs.php
You can use nmodbus API to add how reference in your VB or C# project.
There you have the manual.
Supports serial ASCII, serial RTU, serial over USB ASCII, serial over USB RTU, TCP, and UDP protocols.
These kinds of RTU’s are pretty inexpensive which means your greatest cost will be the time you will spend developing and debugging a driver. With that in mind I would first check if the RTU comes with its own OPC Server. Implementing an OPC client in C# or vb.net is very straight forward with plenty of code example out there. Some examples can be found here:
https://opcfoundation.org/developer-tools/developer-kits-unified-architecture/-net-stack-and-sample-applications/
If the RTU does not come with its own OPC server then, you can purchase a Modbus OPC Server from $900 to $2000 which will still be much more cost effective than writing and debugging your own driver and tends to be easier to setup. It will also significantly reduce the time to deliver your solution to your end customer which will be important if keep to project schedule is critical. I would check out, https://www.kepware.com/ and http://www.matrikonopc.com/
The other advantage of OPC is that it is a standardized interface which means should the RTU be replaced with a different model that supports a different protocol you would only have to purchase a new OPC server without the need to update your source code.
If the RTU does not have an OPC server or spending up to $2000 also not an option then there is plenty of open source implementations of the Modbus protocol, however implementation tends to be a bit more complex.
No problem, I used PHPModBus in several projects and it works like a charm!
This library supports Modbus TCP and UDP.
Try it, it is quite easy and straightforward.
Related
I'm using VBA for Excel to communicate with hardware via serial communication. The code uses API calls similar to this here: http://dev.emcelettronica.com/serial-port-communication-in-excel-vba.
I've been successful with rs232 but it isn't working with rs485. After sending data and reading back the response, the read times out and it reads the same data that was sent.
I have access to software that someone else developed and their software works, so I know that the hardware is ok. I used a serial port sniffer and their code seems to have a lot of redundancy but it looks like its using the same configuration and sending the same data as my code. But their code gets a valid response while mine doesn't.
Could someone share some basic troubleshooting tips for this type of problem?
A major difference between rs232 and rs485 is that rs485 has an additional configuration setting for wire mode. The rs485 can support 2-wire or 4-wire configurations, with 3 different 2-wire configurations. Once I selected the correct configuration, the same code that I used for rs232 worked for rs485.
I have got a Siemens PLC (S7 315-2 PN/DP PLC), which has got a built in Ethernet port.
I want to establish communication between PLC and my PC through TCP/IP (VB.NET based program).
How can it be done ? is any demo or example program available for this ?
Try also Snap7, 32/64 bit with .NET/mono wrappers ready
Libnodave has examples for many languages and VB.NET is one of them. I have used it a lot my self with Pascal and C.
If you want to send data based on events you could also use the 315's build-in Ethernet cummunication blocks and send a data packet (like emulated XML or JSON) each time something interresting happens. I did it a few times and it works very well.
I used to suport live555 client on android. it was supposed use rtp over udp/tcp. now I was asked to run it directly on udp/tcp in single program. Frankly, without rtcp/rtp, how could udp frames be reordered?
You would need to develop your own protocol. I'd suggest looking at how TFTP is implemented. Keep in mind however that with UDP datagrams, there are no guarantees; you will be responsible for ensuring out of order data is discarded and that lost/undelivered datagrams are handled/tolerated by your protocol.
We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
+--------------+ +--------------+ +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+ +--------------+ +--------+
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.
I'm building an Objective-C app that has both a server and a client. The client can send updates to the server, and the server needs to be able to send updates to each connected client. I've been thinking about how best to implement this system, but am asking for your suggestions.
Currently, I'm thinking that when new updates are available, the server will use threads to send the update to each client in turn. If a client times out, they are disconnected.
I have very little networking experience, so am asking your insight.
Do you think that this system would work well?
If so, do you have any suggestions about how to do the threading? Any NS classes you can point me at? There's got to be some kind of queue I can use, I'm thinking.
Any other thoughts?
EDIT: I do not expect the client count to get much above 50 or so, at the max.
As long as both client and server are OS X apps and can both be written in Objective-C using the Cocoa frameworks, I would highly recommend you take a look at the Distributed Objects (DO) technology in Cocoa. I won't try to give a tutorial in Distributed Objects here, just explain why it might be useful...
DO handles asynchronous network details for you (all your client updates could happen on a single thread). In addition the semantics of communication with a remote object (client to server or visa versa; DO is bidirectional once the connection is established) are very similar to in-process communication. In other words, once you have a reference to the remote object (really an NSDistantObject which acts as a proxy to the object on the other end of the connection), your client code can send messages to the remote object as if it were local:
[remoteServer update:client];
from the client or
[[remoteClientList objectAtIndex:i] update:server];
from the server. I'll leave the details of setting up the connection and for getting the remoteServer or remoteClient reference to you after reading the Distributed Objects programming guide.
The downside of using DO is that you are tied to Cocoa; it will be very difficult to write a non-Cocoa client or server that communicates using Distirbuted Objects. If there's a chance you may want to have non-Cocoa client or server implementations, you should not use DO. In this case, I would recommend something simple with a lot of cross-platform and language support. A REST-style API over HTTP is a good option. Have a look at the Cocoa URL Loading System documentation for info on how to implement HTTP requests and responses. Have a look at Apple's CocoaHTTPServer example code or a code.google.com project of the same name for info on implementing an HTTP server in your Cocoa code.
As a very last option, you can take a look at the Cocoa Stream Programming Guide if you want to implement your own network protocol. NSStream's subclasses will let you listen on a network socket and handle asynchronous reads/writes to/from that socket. A lot of people use AsyncSocket for this purpose. It wraps the (lower-level) CFStream and CFSocket and makes writing network code somewhat easier.
When the server sends updates to the clients, it would probably be easier to just have one thread handle them all, and just use async sockets. Of course this would depend on how many clients you had to deal with too.
There's several networking examples in the apple developer side.
One I would recommend that you check out is the URLCache, which can be downloaded.
Quoting from the Apple's documentation for this example:
URLCache is a sample iPhone application that demonstrates how to download a resource off the web, store it in the application's data directory, and use the local copy of the resource. URLCache also demonstrates how to implement a couple of caching policies:
An interesting option is the BLIP protocol from Jens Alfke. It's like a stripped down version of BEEP: a message oriented networking system. It basically provides the low-level abstractions for a bidirectional message pipe so you can concentrate on layering your communication protocol on top of it.
It has some worthy followers such as Marcus Zarra (author of the CoreData bible) and Gus Mueller of Flying Meat software.
I don't know how you plan to design you system, but usually a server cannot connect to a client; the client must initiate the communication. With a low limit of 50 clients, you may not be looking at a web-server/client-like implementation...
That said, there are basically two ways to handle client server communication:
1. The client polls the server periodically to get updates
2. The client keeps a connection open to the server and the the server responds with a well known (as in both sides understand it) protocol.