Today is...
Sunday, August 18, 2019
Welcome to the Modbus Community, about
the world's leading automation protocol.
PC to PLC Communications - best method? Using C/C++.
I was referred over here from We are developing a PC application in C/C++ and need to communicate to one or more Omron PLCs (CJ1M CPU12).

I am writing PC server code (in C/C++) and need to communicate with Omron PLCs. I have written PC code to communicate with PLCs before using the CX-Server Lite ActiveX component in VB6, however that solution will not work in this project because the software is a console/service application. I am working with our vendor and Omron in trying to obtain an API/SDK to communicate with the PLCs however we seem to be having a communication breakdown. Either I just don't understand what they are saying or they don't understand what I need. They keep referring me back to the CX-Server Lite ActiveX component and that just won't work for this project.

We need the ability to communicate to one or more PLCs to send commands to; query states of; and received notices from Omron PLCs (CJ1M CPU12). We are using C/C++ on the PC. What is the recommended communication method and where do I obtain (or what do I ask for) in a PC API/SDK to permit the PC to communicate with a PLC and vice versa? If there isn't an API/SDK then is there a document or white paper I should review? Third party API/SDK are acceptable if they work well.

The PLCs have serial and Ethernet connectivity. We would prefer network connectivity for greater flexibility.

The application is a material handling system. We move platforms containing a payload. Right now, it appears we will only have a single PLC using remote I/O. The PC server application maintains the location of the platforms and the information about their payload (if any). The PC server application instructs the PLC to GET a platform from or PUT a platform into a location. The command from the server to the PLC is simple: SOURCE and DESTINATION. The PC server wants basic updates as to the current state of the system such as: arrived at source level; getting platform; got platform; arrived at destination level; placing platform; platform placed; etc. The frequency is considered quite long - over a period of seconds up to a minute. So, there is no millisecond updates required. The PLC program knows what to do in order to get or put a platform.

We would prefer to stay OUT of the polling mode business and have the PLC actually send updates to the PC server as the PLC state/task changes. If an error occurs, the PLC needs to notify the PC server with an error code (part of the PLC code).

It has been suggested on the forums at to use simple 'protocol free' ASCII messages via either serial or Ethernet. We could make up our own structured ASCII messages for each direction. The Ethernet solution where we would use the Omron send / receive data function blocks in the CX-Programmer function block library, as well as the socket open, close function blocks etc looks enticing.

Do the experts here concur? Does anyone recommend an alternative method or an API/SDK?

Take a look at They offer many different communications tools that will work with VB 6.0 and VB.Net. Maybe they have something that will help.


By Michael Griffin on 27 November, 2007 - 11:20 pm

If you are using the Ethernet module, you might want to look at the "socket services" functions. I haven't used sockets with Omron PLCs, but it seems to be reasonably well documented. The socket services just send and receive packets of bytes, with the meaning of those bytes being up to you.

If you are using the sockets services to just do some basic handshaking, I would suggest just sending some bytes with each bit corresponding to some boolean state. This is probably easier to handle at the PLC end, and it should be straightforward to pack and unpack the bits at the PC end. There should be no problem sending integer values as well.

You might also want to look at the FINS protocol. The applications programming manual for the ethernet module has simple example C programs for FINS over UDP and FINS over TCP for reading an area of memory. You can probably cut and paste these examples to try out the communications. The examples are written for Unix, so if you are using Unix, Linux, BSD, Mac OS/X, etc., they will probably compile and run as is. If you are using some other operating system (e.g. Microsoft Windows), then you might have to modify them a bit to get them to compile and run (I'm not sure how much Microsoft deviates from the standards in this area). These are examples which demonstrate the functionality not "drivers", so you would have to rewrite them for your own application. They should be fairly close to what you need though.

The FINS samples are probably good examples to base some simple socket services test programs on as well. Opening sockets, constructing messages, sending packets, etc. should be the same in either case. It's just the contents of the packets that should be different.

As to whether to use polling or not, that depends upon the relationship between the PLC and the PC. If the PC is supposed to be just a dumb slave to the PLC, then your idea of the PLC sending messages whenever necessary to the PC may be fine. In this case though the PLC needs to be responsible for alerting the operator when something goes wrong with the communications.

If the PC is responsible for taking action on loss of communications, then I would suggest using a timed polling system. If the PLC is sending the messages unpredictably, the PC won't know if it isn't getting messages because there is nothing interesting happening, or if it isn't getting messages because there is something wrong. A polling interval of every 100 or 200 milliseconds is probably more than fast enough.

In either case (socket services or FINS), I would suggest just implementing only those commands that you actually need. A lot of protocols have scores of commands, but you usually only ever end up using 2 or 3.

Thank you all for your replies. Very interesting reading.

In this environment, each item (PC and PLC) is the master of its domain. The PC will not tell the PLC how to do it's job (i.e how to get and put platforms) and the PLC will not presume to "know where item 972341" is parked.

The communications should be very simple and straight forward. The machine is hard mapped into the PLC. The machine has levels and each level has a fixed number of spaces. The PLC knows how to get to each level and knows how to get/put platforms into each space.

The PC maintains the database of information to derived what level/space to get/put a platform. The PLC will not do anything unless it receives a valid instruction (message) from the PC in the form of something like:

<Source Level>/<Source Space> <Dest Level>/<Dest Space>

Example command messages (less colons):


As you can see, the messaging in pretty simple. Of coarse we want to expand beyond that with some additional information. We want the PLC to send back status updates when certain tasks have started and finished. All in all I think we have identified just over a dozen messages.

I looked into this manual:
W421-E1-02 SYSMAC CS and CJ Series ETN21 Construction of Applications

Is this the correct manual or is there something more modern I should review? The reason I ask is someone mentioned something about using function blocks so the PLC programmer doesn't have to write all that ladder logic to perform the Socket stuff. The FBs will do all the labor intensive stuff and all the PLC programmer has to supply is the destination IP/Port and data. And of coarse the ladder logic to create/decipher the data to/from the PC. True?

By Michael Griffin on 4 December, 2007 - 12:21 am

In reply to Van: In your original message, you referred to using the CJ1M CPU12 but intending to use Ethernet. I believe the CJ1M CPU12 doesn't have Ethernet built into the CPU, so I assume you intend to use the CJ1W-ETN21 Ethernet module. My original reply was based on this assumption. The manuals I looked at were:

Cat. No. W420-E1-04 SYSMAC CS and CJ Series CS1W-ETN21 (100Base-TX) CJ1W-ETN21 (100Base-TX) Ethernet Units Construction of Networks OPERATION MANUAL

and the

Cat. No. W421-E1-03 SYSMAC CS and CJ Series CS1W-ETN21 (100Base-TX) CJ1W-ETN21 (100Base-TX) Ethernet Units Construction of Applications OPERATION MANUAL

If you go to "", select "document library", and enter CJ1W-ETN21 in the "Enter a partial Part Number" field you should get these two documents as the search result.

The CJ1M-CPU12-ETN does have Ethernet built in. If this happens to be the CPU which you are actually using the manual for it refers to using the above two mentioned manuals for the Ethernet functionality of the CPU (which is supposed to be the same). However, the manual for the CJ1M-CPU12-ETN says that socket services (and email) is not supported on the Ethernet in this CPU. That means that if you are using this CPU, you will need to use the FINS protocol, not plain sockets. Also, not all of the FINS commands are available (although the essential ones should be).

The manual for the CJ1M-CPU12-ETN is: Cat. No. W441-E1-02 CJ-series Ethernet Functions CJ1M-CPU1@-ETN CJ1M CPU Units with Ethernet Functions.

The document number that you listed (W421-E1-02) was not recognised by the web site when I tried it. I assume you have an older version of the document.

If you are doing socket services communications, then I think the PLC does have to do a bunch of ladder logic to handle the read/write coordination. For UDP socket services, the manual shows about 16 rungs of ladder logic and for TCP, about 21 rungs. You can probably just type this into your program and change the addresses to suit.

You might also want to consider the FINS protocol. This is similar to socket services, but it puts an additional protocol layer on top of them. The PLC understands this protocol, so there doesn't seem to be as much to do at the PLC end to get it working. If you are using the CJ1M-CPU12-ETN then you will need to use FINS rather than socket services.

If you look in the applications manual (W421-E1-03), there are example programs for socket services (UDP and TCP) and FINS (UDP and TCP). This is a total of four examples (one for each of the four methods). These include ladder logic for socket services, and C code for a PC (four C example programs).

I tried one of the C programs to see if it would compile (I don't have an Omron PLC for actual testing though). I had to erase all the leading spaces and then inserting the indenting again, as the PDF seems to have various invisible characters that seem to upset the compiler (gcc in my case). There also happened to be a missing character in the example I chose (FINS UDP) where "bzero((char *) & s_addr,sizeof(ws_addr));" should have been "bzero((char *) &ws_addr,sizeof(ws_addr));" (note the missing letter 'w' in & s_addr). After that it compiled without error, although I still got various warnings.

Since you are sending messages from the PLC and looking for replies, I would suggest that you send a "message number" from the PLC with each request and echo it back from the PC to the PLC with the reply. The "message number" could be something as simple as a counter that you increment with each message (and wrap around back to zero when it reaches maximum). This makes it much easier to determine which reply corresponds to which request. You don't need to keep the "message number", just monitor it to see that it changes and that you got the reply back that you were waiting for.

The CJ1W-ETN21 Ethernet module by the way supports various other protocols besides socket services and FINS. These include email and FTP. None of these other protocols however appears to be suitable for what you are doing as they are quite slow.

By Nathan Boeger on 27 November, 2007 - 11:13 pm

I'm the culprit. He has technical requirements and is a C/C++ programmer. The usual OPC or ActiveX APIs/utilities probably won't work for him because he wants event based (PLC originated) communication as opposed to a polled system. I was hoping that Curt, Michael, or any of the usual crowd could geek it up with him.

Again, my experience with custom code for industrial applications are that: the benefits don't usually greatly exceed what you can do with off the shelf software, engineering time is much greater than anticipated, you run into a lot of really weird problems, and even if everything goes well - maintenance later will be a pain. I've gone behind several similar such systems written in a variety of languages on several operating systems, and this was a recurring theme. This is probably going to be the case unless you're truly large scale with a planned permanent staff to run and update the system (think Walmart).

You want to think with solving operating requirements including growth (x data points, y clients, screens, actual control requirements, acceptable lag time, IT supportable, etc) and engineer a solution based on that instead of beginning with engineering specs (triggered vs polled, raw data bandwidth, PLC memory/instructions, individual component MTBF, programming language/OS, etc).

I hope you get the suggestions you need here. This forum should be frequented by more (PC) technical users than the last.

Nathan Boeger
"Total SCADA Freedom"

By Michael Griffin on 29 November, 2007 - 1:09 am

In reply to Nathan Boeger: I made my replies to the original poster in a pair of other messages, but I will address your points here.

NB: "The usual OPC or ActiveX APIs/utilities probably won't work for him because he wants event based (PLC originated) communication as opposed to a polled system."

MG: I believe that what he actually said was that the Omron sales reps kept pointing him to an ActiveX component, which he couldn't use "because the software is a console/service application." Apparently he has used the ActiveX component before in GUI applications, but it won't work in this one which isn't a GUI app. I won't question his system design, because I don't really know what he is doing.

NB: "Again, my experience with custom code for industrial applications are that the benefits don't usually greatly exceed what you can do with off the shelf software,"

MG: That might be so if you can get an off the shelf software package that does what you need. I doubt there is one for the overall application being described. As for embedding the communications commands directly into his application, that looks to be fairly straightforward from what I could see. I
doubt that it would be any more difficult to do socket or FINS communications than it would be to interface to ActiveX or OPC. Omron even provides sample C code. You do need to know what you are doing if you write software. But then we've all seen bad PLC programs and that doesn't stop us from using PLCs either.

NB: "engineering time is much greater than anticipated, you run into a lot of really weird problems"

MG: I can't think of a single field of engineering where that doesn't happen.

NB: "and even if everything goes well - maintenance later will be a pain."

MG: That is usually due to a lack of documentation. One of the expected advantages of off the shelf software is that it is supposed to come with decent manuals. However, I've seen some very expensive off the shelf software systems from supposedly reputable companies with little or no documentation. These are even less maintainable because you don't even have the source code to fall back on. This is something that needs serious attention from anyone buying any type of software system.

NB: "You want to think with solving operating requirements including growth (x data points, y clients, screens".

MG: For custom software it's usually important to stay focused on the known requirements. If people let their imaginations run wild, then you end up with ever growing requirements that eventually have to be cut back when the project is late. Off the shelf software usually avoids this problem by simply saying "our software doesn't have that feature."

NB: "IT supportable,"

MG: If it's in a factory it may be more important to have it engineering or maintenance supportable. In many factories IT has nothing (officially) to do with production equipment. Again, the answer here is to keep everything simple, have good documentation, and don't assume the people maintaining it know very much (but assume they will understand it if you explain it to them).

NB: "engineer a solution based on that instead of beginning with engineering specs (triggered vs polled, raw data bandwidth, PLC memory/instructions, individual component MTBF, programming language/OS, etc)."

MG: Yes, first you have to get the requirements. The original poster seemed to know what he wanted to accomplish. At some point though someone has to get into the bandwidth, instructions, and programming languages and I think that is where the project was at.

You usually have some pretty reasonable points to make. If I had to sum up your comments on this subject though, you seem to be looking at things as though every piece of software were a SCADA system. It's not though. There are a lot of applications that aren't SCADA systems, and there's no off the shelf software that does what is needed either.

Even a SCADA system isn't really completely off the shelf, as it involves combining a SCADA package with hardware and extensive configuration. This leaves plenty of room for things to go wrong. Just have a look at all the questions we get about SCADA and MMI systems for examples of that.

The questions regarding custom software versus off the shelf software are really similar to those involving entire machines. If there is some off the shelf software or an off the shelf machine that does what you need, then it usually pays to simply use that. In many cases though, there isn't anything off the shelf, or the off the shelf solution is impractical because as well as doing what you need it does a hundred other things which make it overwhelmingly complex and unreliable.

Sometimes the simplest and most reliable solution or even the only solution is to create something specifically for that application. In fact, that is the whole premise behind a PLC. Almost every PLC program is a custom software application. There are things you can't do with a PLC though, so in these cases you have to fall back on more general programming environments.

Deciding on off the shelf versus custom for either software or entire machines requires experience, good judgement, and a clear understanding of the
process. Where most projects of any kind fail is in a lack of a clear idea of what needs to be done, a lack of a clear written specification of these requirements, and poor review of the progress of the project. A further point of failure is lack of good documentation which will allow the system to be operated and maintained later.

With respect to the project in question, I can't find any serious fault with what he is doing given what little I know about it. I suspect that I might do things a bit differently, but then I don't know all the details about this project. In particular, I don't see anything wrong with the PC polling the PLC provided the communications channel has lots of bandwidth (e.g. Ethernet). I
would try to have as much of the communications logic as possible at one end of the link (e.g. in the PC). I would probably also use a different
programming language (e.g. Python) that allowed for quicker development, easier testing, and didn't require complex specialized development software.

As far as communications methods are concerned, many PLC vendors make it difficult to interface with their hardware. In this case though Omron seems to have provided a useful amount of information. I must admit though that I haven't tried this with this particular hardware.

By Nathan Boeger on 30 November, 2007 - 12:49 am


Some of my comments were to backfill you guys on OP's original post on another forum - hopefully he can post a link since I can't seem to find it. I was the one who suggested that he come here to ask you guys how to implement this in C. I don't have the time to address each of your points now, but this will make an interesting discussion.

On the off the shelf versus engineered solution - no kidding, anything that you engineer on your own will be much more labor intensive than buying. That was my point. I agree that a well documented custom application is more maintainable that one that isn't. The nature of every real world custom project I've seen, large or small, is that inevitably someone will have to figure it out later. This is also true of off the shelf apps. They tend to have the advantage of economies of scale in their support and documentation. I will not vouch for general industrial software quality as it's historically been horrendous - but still better than custom written apps I've seen. The obvious advantage of custom apps is that you can write them to do exactly what you need and nothing more. I do appreciate both sides of the coin.

IT supportable is important in a factory. How much new blue hose do you see anyone laying? Everything's going IP. If not now, then in the future. I agree with you for small, specific projects - like embedded applications. But if this thing's gonna last and grow - IT supportability matters!

He still hasn't specified all that much about his ACTUAL REQUIREMENTS. That's why I keep prefacing the advice that I give. I'm looking for "higher level" requirements including possible growth, and he's only provided a technical wishlist. It's hard to tell if he's using the appropriate tools or not.

Nathan Boeger
"Total SCADA Freedom"

By Michael Griffin on 1 December, 2007 - 10:50 am

In reply to Nathan Boeger: You keep repeating that he should be using an off the shelf program. I haven't seen any actual suggestions for one though. If you know of an off the shelf package that will do the complete job with zero programming, perhaps you would like to tell us about it rather than just telling us he's doing it all wrong.

By Curt Wuollet on 29 November, 2007 - 10:28 pm

Ah, but Nathan, one must always remember the stunning accomplishments by those who simply didn't know all the reasons why it shouldn't work. And with shrinkwrap software, you run into a lot of really weird problems and waste a lot of time and maintenance is often impossible. Not to mention getting shook down on a regular basis. For my own part, I find time spent actually fixing problems to be far more interesting and entertaining than being asked idiotic questions by someone who knows less about the software than I do, and can't do anything about the problem should they happen to stumble upon it. I guess it's a matter of perspective. :^)

I hadn't heard mention from the inquisitor that they would use Linux and I'd get flamed for the advice I'd give someone about tying their PLC project's success to Windows.



By Nathan Boeger on 1 December, 2007 - 1:38 am

Can't argue with that point AT ALL. Reminds me of networking. It used to be that one would learn a thing, albeit small, about TCP/IP and networking before setting up a network. Now that everyone's set up a home router (pre-canned for a VERY SPECIFIC application), they're also networking experts. You wouldn't believe some of the, ugh, "creative" ideas I've heard. The nice thing about networking is that the functional learning curve is short from the perspective of a new user - I wouldn't say that about programming/software development.

I appreciate your perspective. Both of our viewpoints aside, idiots will be idiots with whatever you give them. They'll hose my Windows machine and get stuck trying to figure out how to use vi on your box.

By Michael Batchelor on 30 November, 2007 - 1:06 am

I have to say that I have been singing this same song for a number of years. It's easy enough to just search the archives here and find my name attached to lots of posts that make almost exactly the same points Nathan makes below. But as time marches on, I have to say that I'm now not so adamant about that position.

First of all, the skill set of the people to whom you are turning over the code when you leave is increasing dramatically every year. I won't say that there aren't a lot of plants that you wonder just how in blue blazes they manage to find their way to work in the mornings, but there are a *LOT* of guys out there who aren't stupid and can make reasonable modifications to well documented code.

Second, in practically all of the new canned SCADA packages much of the "hard" work is done in the custom scripting language. Just what is that if it's not program code? So, it's VBA instead of VB? If the plant staff is competent, they can do straight VB just as well as they can do VBA inside a container application.

Finally, some customers are balking at the licensing and support fees because they see these two points just as clearly as I do. If the customer says no to a canned package, then the answer is no. End of story. Deal with it.

I won't tell you that I haven't walked away from a few jobs that the customer wanted "custom code" where I was pretty sure they couldn't handle it. But in the same way that plants adapted to the newfangled stuff called steam, then later adapted to the newfangled stuff called electricity, they are now adapting to the newfangled stuff called computer programming. Just as system integrators must adapt or die, the plants are adapting to prevent dying. The stuff we talked about as the bleeding edge 10 years ago is now commonplace in the plants, and we have to get to the new bleeding edge. Custom code is clearly *NOT* the be all and end all to the system integration field. But I can't dismiss it as readily as I did just a few short years ago.

Michael Batchelor

By Nathan Boeger on 1 December, 2007 - 10:36 am

I hear what you're saying and there's a gray area, often pretty subtle. A lot of things fall into my "bad custom code" area that seem strikingly similar to my "good custom code" area. Many of these points can apply both ways to custom code and pre-canned packages.

I agree that an increasing number of people have some programming experience. General programming developments do make this easier: managed code will help mitigate memory leaks, better IDEs and debuggers are easier to use, etc. However, I doubt the percentages are good for people who can write complete solid industrial controls apps that can really compete with the usual suspects. Guys like Mike and Curt, who could get jobs as a programmers, are the exception.

Let me preface this paragraph by saying that I'm embarrassed by the lack of "built-in" functionality in most of the SCADA packages in our industry - backward compatibility of crap and marketing decisions seem to inhibit progress. There's no reason why they shouldn't be a 95% script free solution. You are necessarily correct that the "hardest things" will be done in script.

However, I strongly disagree with your conclusion, that "they can do straight VB just as well as they can do VBA inside a container application." - I prefer to think of it as a platform. The language is of little relevance. More importantly, you can't tie the complexity of the problem to that of the language itself. Their "hardest thing" will pale in comparison to the: thread timing, GUI work, memory management, error handling, and network/device/machine/SQL database interaction that the SCADA application developer gets paid to care of for you.

As applications become more distributed, deal with more devices and external databases, interoperate with Enterprise systems, etc, this becomes significantly more complex. Care to authenticate via Active Directory or Kerberos? Wouldn't it be easier if that functionality was pre-written for you? Further, the SCADA package should provide users with useful library functions that are relevant to the platform.

For example, the package should expose a simple VBA writeTag() function to write to the PLC. In plain Jane VB you'd have to deal with: drivers, OPC, or other complicated device specific functions. The SCADA package should be able to leverage specialization and economies of scale to provide a significantly enhanced industrial software platform than Microsoft Visual Studio - or gcc.


Obvious "bad" characteristics are:
1. Re-inventing the wheel for unnecessary applications. Writing your own complex comm protocol without a good reason, for example (makes sense in this post). The worst I've seen are typically (what should be) databases. Perl script, VB, C++, you name it, they're all very capable of generating memory intensive flat files.

2. Closed code, job security type stuff. I recently worked on an a web application for the military that's treated as a tactical tool, (poorly) designed by contractors. I couldn't edit their compiled Cold Fusion file. It didn't prevent me from doing anything, but was a pain to deal with. I've run across this in industrial settings as well. Precanned packages aren't immune here, but tend to be less restrictive and often have vendor support.

3. #1 offender. People having no idea what their skill set really is. Curt and Mike can probably write an entire application. If they're smart, they won't start from scratch. IMO, most people that have done "some programming" don't have a clue what they're up against in writing an industrial control application.

1. Leveraging technologies - ie, grab a techie kid with a LAMP skill set and he should be able to quickly provide things that your SCADA package can't - through a browser. IMO this isn't really "custom code" like a compiled program written from scratch. He's utilizing Linux, Apache, MySQL, and PHP.

2. Specialized applications. The key is that you have a very specific need THAT ISN'T GOING TO CHANGE! Your old industrial barcode scanner broadcasts a UDP datagram every time it scans. Want a hook into that from a PC? Go 'head and write a custom app.

If you stray from #1 or #2, you'd better have a support staff.

Oh gosh, too long...

Nathan Boeger
"Total SCADA Freedom"

As a matter of fact, you need not write driving for each PLC. Please visit
HMITalk ActiveX can give you a great help.

By Michael Griffin on 28 November, 2007 - 12:05 am

To add to my previous reply, you can have the communications polling driven by the PC but still have the overall control of the system driven by the PLC. That is, the PC would simply poll certain memory addresses in the PLC on a regular basis (e.g. every 100 or 200 ms) to read and write data. The PLC and PC would simply set bits (or integers, etc.) in those addresses to handshake back and forth. The PC would be initiating the communications, but the PLC could still be the master and the PC the slave as far as overall control of the system is concerned.

Another way to look at it is the the transporting of the data between the two would be independent of the nature of the messages being sent between them. This might be easier to implement at the PLC end, especially if you are using the FINS protocol.

By Nathan Boeger on 29 November, 2007 - 1:12 am


Thanks for stepping up! The ironic thing is that your conclusion led back in a giant circle to the PC polling the PLC on a regular basis. He wanted the (theoretically more efficient) PLC driven event based system - conceptually like using triggers in an SQL database. I agree with your conclusion using the PC as the "master" - it can do a lot more during a loss of comms. I guess you could have both sides freak out - I'd hate to be that operator during a network problem. Both devices could call and send you text messages.

Once again I reiterate that polling traffic is negligible on a modern network - unless you're doing some uber-fast heavy application on a slow network, in which case you'd consider scan time versus average poll time. But, IMO, this still gets you back to the same starting point. If I had to write that sort of application, I'd have a really chatty PLC spewin' little bits of UDP, with few nodes on that VLAN. The PLC could conditionally transmit a packet before the poll cycle. In the real world that still turns out to be more characteristic of a polled system. Besides, this tends to be more relevant in an error condition. So your PLC sent the packet Instantaneously - what's that mean when the PC doesn't respond? This whole idea is silly without caring about the response. Suppose the PC responds in 50 miliseconds, great. But how do you know what to expect 2 seconds later? Ugh oh, don't look now, we're polling. Your switch can easily handle light rapid traffic. Networking is the easy part of the path you're about to travel. Just don't overthink the implementation details without considering why you're doing them.

Nathan Boeger
Total SCADA Freedom

By Michael Griffin on 1 December, 2007 - 12:49 am

In reply to Nathan Boeger: The intent that I was trying to convey was that the ActiveX package that the Omron reps were pointing him to looked to be unnecessary. There are both "socket services" and FINS, neither of which requires it (nor is OPC required). The documentation that Omron has provided looks to be better than that from many other PLC vendors.

As for polling versus event driven messaging, I wouldn't say that I came to a specific recommendation. Either method will work, and there is something to said in favour of both. I have used both methods in different applications. I did suggest looking at whether having the PC poll using the FINS protocol would result in a much simpler program at the PLC end.

The point I was trying to get across in the paragraph from my reply that you picked out was that it is possible for the PC to drive the polling while the PLC still acts as the logical control "master" for the cell. The PC is responsible for transferring the bits back and forth while the PLC still tells it what actions to take.

An event driven messaging system though is usually fairly straightforward. The PLC sends a command and the PC sends back a reply. If it may take some time for the PC to comply with the command, then the PC could give an immediate acknowledge followed later by a second reply with the final answer. If you simply want the PLC to check the status of the PC without having the PC take any other action, then you can define a status message (the PLC asks for status, and the PC responds with "OK", or something similar). I've done PC based production test systems like this and it has its advantages where the PLC has communications bottlenecks (either in the serial communications to the PLC, or across the PLC backplane to the CPU).

Event driven messaging is not that uncommon in industrial control. For example, a lot of bar code readers work this way. You send a read command, the reader reads, it sends back a reply. If you don't get a reply within a set period of time, this is a fault.

I think the two choices are:

A) Use the FINS protocol. This requires (at least at first glance) having the PC poll the PLC. Advantage - it may require less programming in the PLC. Disadvantage - I'm not sure if there is any, but then I haven't looked into the problem very deeply.

B) Use a custom master/slave protocol over socket services. If the PC is the master, this requires polling. If the PLC is the master, this could be either polling or event driven messaging. The event driven messaging might be simpler under this scenario.

If this were my project, I would sketch out on paper solutions using both methods and then weigh up the pros and cons of each. At this point, all I could say is that it appears that either method would likely work.

By Nathan Boeger on 3 December, 2007 - 11:45 pm

Got it, and I agree. OP's requirements are pretty fundamental - thanks for the help. Hopefully it provides him with enough good info to get started. You were one of the main reasons I pointed him over here.

Nathan Boeger
"Design Simplicity Cures Engineered Complexity"

By Angel Granja on 3 January, 2008 - 10:57 pm

Try Using Hostlink commands if you do VB can access all DM values or Input and Output bits using RS232. i.e. Get the Hostlink commands directly from an Omron vendor.

By Juan Miguel Taboada Godoy on 4 January, 2008 - 10:51 pm

If you can use Ethernet maybe you have Modbus enabled and then implement a library to access to your PLCs through Modbus protocol. You can find a Python library for Modbus comunication over Ethernet (you will not have problems to convert it to C++) at Also you can find Modbus libraries example in C from Advantech, their ADAM 5xxx series has it in the documentation CD, so probably you can find it on Internet also.


By Michael Griffin on 6 January, 2008 - 4:49 pm

In reply to Juan Miguel Taboada Godoy: I was interested in your Modbus library, so I had a look at the and files (MATH_BIN is imported by MODBUS_TCP). As I don't know Spanish, I am not quite sure how you intended it to be used, and if there are some other important parts to the project (I am referring to the Modbus/TCP only, not the rest of likindoy).

However, in the course of looking over the code, I noticed a few areas which could be optimised for speed. I rewrote some of the code and got the following improvements in these functions.

msg2modbus - 5.0 times faster.

modbus2msg - 15.5 times faster.

inversorbin - 9 times faster. (This is typical, but varies slightly depending upon the data).

hex1tobin - 2 to 24 times faster (depending on the data being converted). Actual speed up on real data is probably more on the order of 3 to 5 times, assuming the data contains mainly zeros. The speed of the algorithm you are using depends upon the data being converted, while the algorithm I used is linear except when errors are encountered.

bin1tohex - I would expect similar results for this function as with hex1tobin, but I didn't test it.

With the rewritten functions, the functions hextobin and zeros are no longer used (so there's no need to optimise these).

I ran both sets of algorithms side by side and got identical results from them for the same inputs over a large set of test data.

If you are interested in these results, please reply and we can discuss this further.

By Juan Miguel Taboada Godoy on 8 January, 2008 - 1:24 am

Yes, I am interested to check the improvements you have done to that library. You can contact me at my email address or through the Likindoy project website, and I will add your patched to the source code.

About the source code, it will be translated slowly, but first we would like to get the website translated as soon as possible.