Sign in to follow this  
Followers 0
Van

PC to PLC Communications - best method?

13 posts in this topic

I am a PC programmer and I know some basic PLC programming. I am part of a project where I am writing PC server code (in C/C++) to communicate with Omron PLCs. I have written PC code to communicate with PLCs before using the CX-Server Lite OCX (Active X) component in VB6 however that will not work in this project. There is no GUI on the PC side (it's 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 ActiveX component and that just won't work in this case. Someone recommended this site. I 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. I have been reading a lot of posts in the forum however I am not a PLC expert and thus am unfamiliar with a lot of the terminology used here. Please treat me with kid gloves! The PLCs have serial (Toolbus?) and Ethernet connectivity. I would prefer network connectivity for greater flexibility. If anyone could point me in the write direction I would appreciate it. Edited by Van

Share this post


Link to post
Share on other sites
I do not get into this stuff but could you use an OPC driver? There are several around and a search will find you one here.

Share this post


Link to post
Share on other sites
We have used InGear products with Rockwell PLC's for many years. If their product works as well with Omron PLC's I would suggest you take a close look. http://www.ingeardrivers.com/.

Share this post


Link to post
Share on other sites
Thank you for your replies. I have made an inquiry to the above link. I have stumbled onto Modbus ( www.modbus.org ). Will Modbus satisfy our requirements? What are the Pro's and Cons of using Modbus? Does anyone know if the CJ1M CPU12 natively support Modbus? Edited by Van

Share this post


Link to post
Share on other sites
As far as I know the Serial Ports on the CPU DO NOT support Modbus. Only the SCU [serial Communication Board] or SCU [serial Communication Unit] can be configured for Modbus. With regards to your questions "Will Modbus satisfy our requirements?" and "What are the Pro's and Cons of using Modbus?" that is difficult to answer without knowing the full extent of the application. How much data? At what frequency is the data polled [secs, mins, hourly, daily]? If you are controlling parts of the PLC application from the PC Host [Recipes, Timers, Counters etc.] what response time do you expect from the PLC? How many PLC's on the network? All questions that need to be defined before network performance can be evaluated to see if it suits the application. My 2cents

Share this post


Link to post
Share on other sites
The application is a material handling device. 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 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 - a period of seconds up to a minute. So, there is no millisecond updates required. The PLC knows what to do to get or put a platform. It just isn't smart enough to keep a database of what is where - which is where the PC server comes in. 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).

Share this post


Link to post
Share on other sites
The PLC knows what to do to get or put a platform. It just isn't smart enough to keep a database of what is where - which is where the PC server comes in. I thimk you might be underestimating the capabilities of the PLC. The Data Table Instructions and File Memory Instructions offer an extremely flexible and powerful method of tracking, storing and handling large amounts of data. Furthermore the ability to declare variable as an "array" in the latest version of CX Programmer expands these capabilities still further. I am a proponent of exploring every "WHAT IF" situation that could possibly occur. In your application you are relying on the host PC to keep track of all your pallet locations. If the PC faults [which it will inevitably do at some point] this may result in incomplete of corrupted data for your storage system. How will you move product if this happens? How will the PC know if it it has been moved? Take a long hard look at having the PLC track and store this data. A method of synchronizing [uploading the data] from the PLC to the PC at power up could be implemented. Personally I wouldn't consider designing such a system without some form of manual backup/control using an HMI. My 3 cents.

Share this post


Link to post
Share on other sites
No need to beat OP up for saying "smart enough". Nobody's challenging the fact that PLCs are powerful. If you think they can do everything as well as a general purpose PC, you're sadly mistaken. How much data you have and what you want to do with it is the driving question in deciding where to store it. Want to see realtime states and buffer a short term history - the PLC will be fine. Need to log long term production history, do analysis, and generate reports - use a PC and probably an SQL database. Just because the PLC can do it doesn't mean it's the most appropriate place to store data. For custom programming I'd recommend finding whatever standard makes sense. Modbus and OPC are your options there. A few companies exist that sell vendor specific "driver" APIs (this one does an ActiveX version for other brands). Unfortunately, I don't know of any for Omron. Custom programming may or may not be necessary depending on your requirements. Coming from PC programming, you'll be surprised at what a pain communicating with devices is. Your comment about the PLC initiating communication as opposed to PC polling is a good idea, but not how PLCs were designed to work. You can probably have the PLC programmer write specific code (ladder) to set triggers that conditionally communicate with your PC. In general, this isn't possible. It would be nice if you could just say, "hey PLC, notify me when any registers change value". This gets into standards. The way it works going down the OPC path is: your program (the OPC client) subscribes to the registers that it wants to watch, specifying some sort of update rate. You don't want all the clients bogging the PLC down with read requests, but the OPC server is managing a (typically) poll based system. Nice thing about OPC Servers is that they are written for the specific PLCs - so the authors (who should be experts on that system) can take advantage of relevant PLC supported features. You don't need to know all the details to write the client software. Coming in as a C programmer with no PLC knowledge/experience makes it difficult, to say the least, to write the communication portion. I'd recommend that you continue to research existing solutions to your problem. Unfortunately, the open source community isn't much help here. You may find cool commercial APIs. I don't know much in depth about Modbus, that may do it for you. I'd say your better bet would be to find an application that can do what you want without writing the code. Pretty much all industrial software is "application creation" applications. You may not be programming in C, but you'll probably have to program something to tailor the program to your job. Just don't let your pride or a spec that come from someone who didn't know what they're talking about turn a simple problem into a mess. Edited by Nathan

Share this post


Link to post
Share on other sites
An SCU card for the CJ1 or CS1 could be set up as a Modbus master with the PC as a slave and initiate communications I guess but the Modbus slave software for the PC may be the problem. The latest CJ1M with the latest version of CX-Programmer has a really quick easy setup for Modbus RTU slave in the SCU when online - Modbus RTU master I think still requires a protocol in the SCU and use of the PMCR function in the PLC. The CP1L has Modbus Easy Master and is a sign of things to come but I do not know if it available for the CJ1 yet.

Share this post


Link to post
Share on other sites
Hi, I posted earlier but 'pulled the pin' and offer this comment as an alternate: Why not use simple 'protocol free' ascii messages via either serial or ethernet. You could make up your own structured ascii messages for each direction. Serial: use two ports on PLC (add a CJ1W-SCU21 2x RS232 ports) and two ports on PC, one line for PC to PLC comms messages, one line for PLC to PC comms messages. Use TXDU and RXDU ladder commands to send / received messages from the serial ports. This would be simple and easy to set up, and using simple ascii messages requires no specialist protocol knowledge. Ethernet would be better because you wouldn't need to worry about any corruption of data. (Add a CJ1W-ETN21 ethernet unit to PLC) 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. Some form of 'valid data' response should be sent as a reply from either the PLC or PC respectively to confirm to the sending device that data was received (if not, the sending device would send again, or perform some fault logic) Nibroc Edited by Nibroc

Share this post


Link to post
Share on other sites
I do have basic PLC ladder logic experience. I have programmed several PLC ladder logic programs but nothing very sophisticated. For this project we do require a PC to maintain a SQL database of the platforms and their payloads. The PLC just isn't capable of doing what the PC can do in terms of storing, sorting, anticipating, analyzing, etc. There is a lot more to the server code than what most people think. IMHO that's just not what a PLC is designed for. A PLC is finite state machine for which it performs magnificently. FYI, we have determined that MODBUS isn't the way to go. Ah ha! Now we are getting somewhere. Thank you very much! So we can develop our own messaging system using the SEND RECEIVE DATA FUNCTION BLOCKS? This is perfect! We will look into this. Is there a certain Omron publication that you would recommend reading? Whitepapers? Also, does any know which sample code in PC and PLC that uses these methods? Edited by Van

Share this post


Link to post
Share on other sites
Have you looked in the download section for omron ? There are example programs for VB (which i am sure you could convert to C+) http://forums.mrplc.com/index.php?autocom=downloads&showfile=181 http://forums.mrplc.com/index.php?autocom=downloads&showfile=62

Share this post


Link to post
Share on other sites
Nobody here said that a PLC is an SQL database or general purpose PC. They were making sure you couldn't solve your requirements in the PLC - trying to save you a lot of complexity. No need to get into automata theory here, it's not relevant and few people on this forum know what you're talking about. It sounds like you're on the right track with the PLC messaging instruction. Keep in mind that you're writing job security in for yourself - maintaining a custom system will almost certainly be a headache for someone else later. Your system will necessarily include PLC side logic in addition to your C++ application and whatever custom communication protocol you come up with. It should be great in terms of what you asked for, but a lot to upgrade or troubleshoot for someone else - document well. I'd recommend asking the same question to the guys at the control.com forum. They used to be the Puffin PLC project (formerly LinuxPLC.org) and they're more aligned to your background. Edited by Nathan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0