Sign in to follow this  
Followers 0
waterboy

Can these errors be cause by a running PLC program?

37 posts in this topic

Thanks for the detailed reply. I will review this in much more detail this evening but I just wanted to say that the ethernet is clean and not very busy. I can watch the packets come into each PLC (I used a port aggregator) and also out of the server and the PLCs see nowhere near the 2000 packets/sec and i'm not sure the server does either. I will watch it again with that very low bandwidth limit in mind and report back. IGMP snooping is enabled on both managed switches and there is very little broadcast traffic. I am quite concerned about your RSlinx comments. Thats a very expensive piece of software to have perform so poorly. But the blinking you describe is indeed what I am seeing. And I am sure having a heck of a time getting ahold of anyone at Rockwell with any real answers or even valid tests to perform. I understand the difference between the CompactLogix and the Controllogix you describe but the commonality of these two is the CPU usage. For example, I have 2 Contrologix PLC's and I am seeing high usage in one CPU running v17 firmware and Very low cpu usage in a v16 . And the one with the V16 should be busier than the one running V17. ALL the CompactLogix and the high usage Contrologix were written near the same time. Thats the only reason I compare them the way I do. Since I don't currently have the skills to write the program, I recognize that its easy for me to believe something in the program or possibly a corruption in the program file is to blame for the excessive CPU usage. Perhaps some setting in the tasks, I dont know, I've just started working with these CLX series and there are a lot of variables to consider. But I have spent an exhausting amount of time looking at everything else that I do know about and have made no real progress until I played with the timeslice setting in the PLC. Then reported comm errors got much better but the data blinking still occurs. One post reported that exporting the program files to L5K and then reimporting them back in would correct any corruption and subsequent unexplainably High CPU usage so the boss has agreed to do that tomorrow. In any case that will put this corruption issue to bed and I can move on to something else. And now I have to consider that RSLinx itself just cant handle it. . . I wouldnt have thought that.

Share this post


Link to post
Share on other sites
Update: Rockwell Tech support just told me that RSLinx is not compatible with GE's OPC driver. Said they will conflict. That was an interesting revelation. Could they be confused as to what the OPC driver really is in iFix? Surely they are compatible. Second update: Bandwidth used at the compactLogix PLC was never greater than 100 Packets / second Edited by waterboy

Share this post


Link to post
Share on other sites
Paul - thanks for all the pertinant poop. You had some good tidbits on RSLinx and Logix. Waterboy - you mentioned that you dont have the CPU problems with the v16 processor but do with the v17. Possibly an issue with 17? I know there is a fairly recent update to that firmware rev. Might be worth looking into. Also going the other direction, have you considered reving back the 17 to 16 to see if the problem goes away. Might be worth looking into while you're down if the export/import method doesnt fix your problem. Here's an method I have from my rep a while back: "save your v17 file as .L5K format. Open the file in a text editor and change the "major" v17 to v16. Then open the .L5K file with RSLogix 5000. You may encounter an error or two as you have to make a few changes but this does work. Starting in v17 and looking forward (e.g. v18 down to v17) will be supported as an option in the controller properties." Good luck

Share this post


Link to post
Share on other sites
I have GE support coming out tomorrow to put thier blessing on all things GE, then Rockwell will be next. We tried the L5K export / Import and it made no difference. Didnt try a version downgrade, but its in the cards. I will need to dissect Pauls reply as there are many terms in there that I'm not familiar enough with, Unsolicited vs solicited, connected vs unconnected are but 2 examples . Creating the UDT would be a non trivial issue as well. But the low packet/sec count seem to indicate that traffic load isnt the issue.
1 person likes this

Share this post


Link to post
Share on other sites
Creating the UDTs and all the dominos that follow is a pretty tall order at the moment. Its a good idea to be sure and I would but nothing I have seen suggests a traffic issue, it all points back to either RSLinx choking on something that it would choke on no matter what data was passing through it, or the PLC's themselves just shutting up for a time. If you disagree with that assessment I would certainly reconsider.

Share this post


Link to post
Share on other sites
Try a Kepware OPC server instead of RsLinx. I think you can download and run in demo for a brief period. This will eliminate the RSlinx question.

Share this post


Link to post
Share on other sites
I'm not at all resistant to that and I'll look at them again after I post this, but I don't use OPC for the PLC5's, I use GE's ABR driver to RSLinx so RSLinx would have to remain in place for those PLC's. I would have to readdress my entire database to use OPC with the PLC5s. If thats even possible.

Share this post


Link to post
Share on other sites
You can check RS-Linx easily. Check out the process CPU usage using Windows Task Scheduler. The same thing can happen also internally in iFix and Cimplicity PE. But it is much harder to check on the tasks/processes internally. The other poster is right. When you do online edits, CLX essentially suffers from memory fragmentation over time. Only way of cleaning this up is to periodically upload and then download while offline. It's the sort of maintenance task that you should probably make routine about once every year or two.

Share this post


Link to post
Share on other sites
You are correct. Rockwell is just outright telling fibs. Shame on them for denigrating the competition. I guess the next move was to tell you to call your sales droid and order up a copy of RS-View SE, right? The only reason to tell you this is if they think you are stupid. Has Rockwell been taking lessons from AT&T on how to treat customers? Whenever you set up OPC clients, you MUST specify the OPC server to use. This isn't just to allow you to contact remote vs. local servers. You can have an arbitrary number of OPC servers running on the same machine without conflicts. If iFix has an OPC server running too, there is NO effect on RS-Linx. If iFIX has a "direct driver" to talk to the CLX while bypassing RS-Linx, so be it. It just opens a parallel connection. Again, no impact to RS-Linx. The only time you get conflicts is with hardware ports, such as when RS-Linx Enterprise tries to steal the serial port and won't let go so that you can use RS-Linx Classic for programming. By the way as to your versioning questions, my recent experience in which RS-Linx acted unstable was with Rev. 16. Rev. 17 just came out and I was a little skittish about running it until Rockwell had at least 2 or 3 months of run time to verify that everything was in good working order. Now...to get back to the concept of connections...this is very important especially if you are doing unsolicited messaging which you haven't verified yet. The way to check is to go into iFix and inspect the tag configuration information for the tags pointing to the CLX PLC. A "connection" to a CLX PLC is somewhat akin to a "socket" if you've ever done any network programming using a sockets library. If not, it's not important. What is important is that when you connect to a PLC to receive data, the PLC has to allocate some memory for buffering and such. The memory that is allocates is a "connection". Connections are NOT multiplexed. If you are doing solicited communication, then typically the number of connections is just one or two. I believe Rockwell has a formula for this buried in their manuals. The reason is that the HMI just opens a pipe (a TCP connection) and starts sending requests and receiving responses down that pipe. Unsolicited communications is a bit more complicated. There is probably some optimization going on but essentially Rockwell says that each unsolicited object that you set up consumes one connection, or something close to that sort of ratio. The connection now stores the overhead that the PLC has to remember about which blocks of memory to monitor, and perhaps some status bits if it only sends a packet on change of state. Depending on the Ethernet card, you might only get 128 connections to play with. Once you exceed the connection limit, then at least according to the manual, there is some potential for multiplexing going on in order to keep the load under control but you are definitely approaching a performance boundary. SOOO...using UDT's and arrays where appropriate isn't just about minimizing packet loads. It also involves optimizing your connections. Again, consult the Rockwell instructions very closely to understand why/when/where this can affect you and again, look closely at your point/tag database in iFix to get a good understanding of how your actual IO is being implemented, including scan rate and the way in which the communication is set up. I have seen a number of setups where the total amount of communication is actually trivially small but the CLX processor chokes because an obscene number of connections were formed. The way that you might be able to detect if this is a problem is to try mixing unsolicited and solicited settings in your HMI. If you suddenly start noticing that some updates continue working while others keep failing, then adjust your strategy based on what you notice. I went through a semi-mechanical conversion recently for a fairly large CLX project. Everything was rock steady with the PLC-5's. With the CLX, I had nothing but trouble almost semi-randomly all the time. So I went after communication optimization. I eventually got 95% of the polling down to just 10 total packets (monitoring about 300-400 data points), and things were much better. We only had momentary communication losses once a week or so. After switching to Kepware (and tearing my hair out rewriting all the paths), they all disappeared. I didn't try using RS-Linx Enterprise instead of RS-Linx Classic. I've heard (since I believe based on the CD's I've received) that RS-Linx Enterprise is rebranded Kepware. But I haven't used Enterprise outside of working with Panelview+ programming. Edited by paulengr

Share this post


Link to post
Share on other sites
You can make OPC work with PLC-5's. But there's no reason to readdress anything. Just leave the PLC-5's alone. It's working fine. You can have as many OPC servers as you want (and have CPU and memory for). During some preliminary testing, I had RS-Linx talking to PLC-5's "both ways" (to verify it works), and I also had different OPC servers running on the same server alongside RS-Linx.
1 person likes this

Share this post


Link to post
Share on other sites
FYI This isn't strictly related to this post but GE mentioned that in the latest release V2.54 of RSLinx - If you use the the "Remote Devices via Linx Gateway" driver you have to assign the paths using hostnames instead of IP's as has been the case in the past. Can't use IPs at all in this driver. This doesn't affect me but I thought it might affect someone else. Rumor is that they will reverse that decision in later releases. Just FYI I just got Kepware with a couple demo keys and am poking around at it. Its a lot different that what I am used to. I havent yet seen where to enter tag names instead of blocks.

Share this post


Link to post
Share on other sites

Hi waterboy, did you manage to figure out the solution?

I am having a similar issue by collecting data to IP21 through RSlinx Gateway from ControlLogix PLCs.

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