AB Development scenario

[chrgibson 0]

Hi all, very informative forum from what I can see, so hopefully this will be the place I can get some support. I have been tasked with a full traceability system on three production lines using Allen Bradley PLCs. There is already a DH+ network and we will be using Keyence barcode scanners. Myself and my colleague have been looking at PLC to DH+ to VB6 communication and seem to have settled upon using the OPCDAAuto.dll along with an OPC server to map the data we require. Each line will have around 40 nodes and its own PC to collect the data. There will be around 20 tags or so for each machine. These tags will be grouped into 3+ groups so I can receive events separately and reduce processing. We will struggle to create enough of load test to be 100% confident this solution will cope with amount of data flowing around. First tests seem positive, but will this prototype scale up to full production size? I've little to no experience in OPC or DH+ and have only just noticed the syncread method so I can pull data from DH+ myself (from a single 'data ready' bit tag possibly). Would this be a better method? Also, I'm looking for the documentation for the automation DLL, does anyone have a link? Thanks in advance!

[JesperMP 2]

Hi chrgibson. How many bar codes do you have to scan per minute ? DH+ is not a very high-performant network standard. I works pretty well with medium datavolumes up to 7-10 nodes. At 40 nodes you may have a problem. 20 tags per node does not sound so much, but I would use every trick possible to reduce the network load. Group all tags into one contigous block of data. Do not poll the data cyclically, in stead send the data on event from each node. This is easier than you think as RSLinx (the OPC server I believe you will be using) can easily be set to accept "unsolicited messages". If this does not bring the network traffic to acceptable levels, you may have to split into multiple DH+ networks. For this you can have several DH+ cards in one PC, or you can use a ControlLogix chassis with one or more DHRIO cards and one ENBT card to route from ethernet to multiple DH+ networks. edit: Also consider if the DH+ network is in use already. If there are some HMI panels or cyclical datatransfers going on on the the existing system, then you may not be able to put further network load on the already utilised network. Edited 31 Mar 2008 by JesperMP

[chrgibson 0]

We will be scanning around 3 per minute per process, and we have around 25-30 processes. The Keyence scanners will be daisy chained, the PLC will fire the scanner and I will simply receive the result through the com port. I'm not worried about the scanning and validation, because I will be using MSMQ to make sure the application is always responsive. I'd prefer not to go down this route until we've exhausted all our streamlining ideas!Thanks again for the help. Edited 31 Mar 2008 by chrgibson

[JesperMP 2]

3 times 20 tags (words ?) per minute, times 30. OK, that is not so extreme. I envisioned a conveyor system with scanners reading barcodes with several reads per scond per node. I would definitely send the data on event in stead of polling each node. In your case it will make a huge difference. I have a manual for PLC5 with a chart for DH+ response times according to number of nodes and amount of data (I guess it doesnt make such a difference with SLC5/04 or PLC5). The closest match to your situation is 22 nodes with 50 words per node, which results in an average response time of 0.6 seconds. Probably OK for your application. If I were you, I would setup a full-scale test. You can initiate simulated scanner reads in the SLC code. Then you can setup a test to see if your PC application misses any of the scanner "reads".

[chrgibson 0]

The PLC will only be used to fire the scanner, everything else will be handled externally. It must get a good read to validate the part and continue in the process, which means the process will wait until the part has a good scan. There will be no chance we will miss a barcode scan.Thanks Jesper!

[JesperMP 2]

What I suggest is for testing the network capacity. So you should simulate the datatransfers from the PLCs to the PC. You can send a count value that increments for each transfer, and then see if you miss any over a long period of time (if there are gaps in the logged count values).

[kaiser_will 65]

Keep in mind that DH+ is limited to 64 device addresses per network (processors and PC links in your case). But I have found DH+ to be optimum for most my applications when limiting to 20-25 addresses per network. There are some configuration options available to squeeze in more nodes. You might have to consider multiple DH+ networks, which you can bridge into a ControlLogix bridge. This might be a good option for you, with handshaking logic in the bridge for barcode reading and to verify that the data made it to the database.

[chrgibson 0]

Well we've got it setup now with two test processes with around 10-15 tags in each, we dont envisage any more tags, but I'm a little unsure what is meant by: If we use a WORD or DWORD then the OPC server seems to constantly poll, but if its an INT or LONG then the values are not visibly polled. Does OPC poll the data internally? Or a more relevant question is do you mean we'll be ok as long as the VB app isnt polling?I'll be setting up a test including counters that will be logged, three cells is our maximum test at the moment.

[Gerry 13]

"send data on event" means the PLC monitors the relevant data in its data table for change and on detecting a change, initiates a message to the logging computer. This requires some ladder programming in the PLC. In AB-speak, these are unsolicited messages. Your "cheaper alternative to RSLinx" needs to be able to handle these (sort of like an interrupt). Using this strategy means the computer is only listening to the network and not adding a lot of traffic by polling each PLC looking for changes. The polling needs to be at least twice as fast as the fastest possible rate of change in the data being monitored. If your VB app isn't polling and the PLC's aren't programmed to report on exception then you won't get any data.

[chrgibson 0]

Well I don't get any data change events in Visual Basic/OPC until the PLC writes to the parts of the data table I'm monitoring. This means our 'end of cycle' data (the majority of all data) will only come in once per 30 seconds. What I've done is setup a group in the OPC server that contains all the 'end of cycle' data, and another group that has all the safety and line stop bits. What this means is I only have to run through all the end of cycle data once. The safety/line stop group simply logs the on/off states of the bits, and this can happen any time, but 99.9% of the time there will be no changes to these bits and therefore no data events to handle.

[paulengr 44]

Although OPC certainly supports it, I haven't really seen any practical OPC implementations which don't poll continuously with PLC-5 and SLC since these processors don't generally support "change of state". That being said, your second idea of using the PLC to set a single bit or word to mark change of state is a programmatic solution to the problem but does minimize the amount of polling. If you are reading several words in a row (several bits, words, or even reals, in the same table), RS-Linx at least will optimize away the details and issue a single big read, at least up to what fits into a single packet (you should probably try to stay under 100-200 words at most). If that's the amount of data you plan on monitoring anyways, there is NO difference in bandwidth/CPU load between polling a single word and a whole bunch of them.

[chrgibson 0]

Thanks guys! I think the best way forward is to further group our data into arrays of data. This should leave us with 3-4 bits/arrays of data per process. Since we are not heavily reliant on speed, it shouldn't cause us any issues.

[JesperMP 2]

We do exactly that with both PLC5 and SLC500.In the PLCs there is programmed message blocks that are triggered upon event. In RSLinx, the OPC topic is setup to accept "unsolicited messages". Thus no polling, and the data is recieved at the OPC server as fast as possible with minimal network load.

[chrgibson 0]

Hi all, just wondering where I can get the specification/documentation for the OPCDAAuto.dll? We've noticed over the last week a couple of show stopping OPC crashes (the actual OPC server not our applications), once this happens we don't receive any data arrival events for the group that crashed. I'm using the OPCItem.write syntax to allow me to write arrays back to the PLC. The syncwrite method was allowing me to write an array but was only writing the first value (without errors).

[OkiePC 14]

If you are monitoring parts of data tables from 40 nodes, you will be looking at at least several seconds to make the full rounds. Make sure you don't beat up the network or tie up the token for too long, or any other DH+ functionality (RSLogix/RSLinx for example) will suffer. As stated earlier, you need to be able to receive explicit messages from the PLCs and do NO monitoring of 40 nodes. My personal "red flag" for DH+ networks is 12 nodes. More than that, and I know that I must be very careful what I do with them. Case in point: My previous employer kept adding nodes to a simple, reliable DH+ network, Panelview standard terminals (with about 200 tags each) added to the 7 exisitng PLC5/40s. After node ten was added (the third "upgrade" with a panelview), all the HMI response times were noticeably slower. I tried to warn them...but...one of the many reasons I don't work there anymore. Too bad you can't regulate comms in a Panelview...I am glad I left before they got all 14 nodes to chatting constantly. Sure, you could have 64 nodes on a flawless network with no trouble if there is no messaging going on. But as soon as you start depending on the token passing scheme, you will hit some restrictions.

[paulengr 44]

The best way to get information on OPCDAAAuto.dll is of course to spend $5000 to become a OPC Foundation member! Yes, I think it's outrageous too for a supposedly "open" specification. The OPC Foundation gives away copies of a reference implementation, and that's what that DLL is. It's also the reason that essentially every OPC-compliant vendor gives it away, because they can. However, that's also a huge hint. If you search on the web sites of Kepware or Matrikon and get a manual, that same manually will work unchanged in the version that Rockwell compiled and gives away! OPC has a problem. It's called OLE/ActiveX/COM/DCOM, whatever you want to call it. It's part of Windows. And it is designed extremely poorly. Until OPC-UA gets rolled out, everything OPC is related to Windows. If you lose connection to a processor and keep polling, eventually the OPC client will crash. The correct approach to get around this according to Rockwell is to close your OPC connection and then reopen it whenever you lose connection to the processor. Rockwell has some "hidden" values within the RS-Linx OPC Server itself which give you status information on the state of the processor connection. Kepware and Matrikon also have similar information. The trick is to monitor those status registers and at least with the RS-Linx implementation, purposely close the connection if you detect that you've lost processor connection, and then reopen it. This can/should be done with a timer. If you don't do this, RS-Linx will effectively "lockup" on you, just as you described because the buffers within Windows will overflow. We've fought this one (and won) with ControlLogix talking to Cimplicity PE.

[chrgibson 0]

Our tags are very simple: Events(10) INT eg. Machine Faults, Power, Safety Guards Data(7) INT eg. Cycle Times, Force Measurements, Pass/Fail Acknowledgements(5) INT eg. Handshaking between applications and PLC/OPC I'm not sure how I can even detect the crash in VB, let alone restart it. Edited 17 Apr 2008 by chrgibson

[paulengr 44]

Rockwell has a bunch of "hidden" tags in their OPC server that give you connection status information. Read the manual and/or contact Rockwell. Simply monitor those tag values to detect when the PLC goes down. As to restarting it, this is pretty easy. You have to execute an "OPEN" command with the OPC driver. Closing the connection and opening it is how you "restart" it. You don't have to actually force RS-Linx itself to restart, only to close the OPC session with it and re-open it.