speakerman

Fatal Error when going online

16 posts in this topic

Hey everyone; Having a problem with RSLogix5000 and a Contrologix L62 Processor. Was adding a MAVE block to a routine and a fatal error occurred as it was being created. I've verified the program offline and everything looks good up to that last live edit, which was the only outstanding change when the fatal error occurred. The last edit is not in the saved file. Now when I try to go online, I get a fatal error every time. I can't find a version of the program that will go online. I can't even upload from the controller and make a new file just to look at it. Aside from the obvious of stopping the controller and uploading a fresh copy of the saved program, does anyone know if there anything I can do to get online and perhaps repair the problem? The processor is running and the plant is running fine. The edit was for some ongoing work that has not been implemented, so it hasn't affected operations. The plant has no scheduled downtime for a couple of weeks, so stopping the controller is not an option right now. I'm hoping for a solution that can be performed in run mode. I've also looked into whether this customer has a Rockwell Support agreement, which at this point is a real thorn, as the tech support will do nothing without it. I've attached the fatal error message the program generated when it went down, in case someone has seen this before. Thank for any help that can be offered. Happy programming, speakerman.

Share this post


Link to post
Share on other sites
Your software crashed, not the PLC. That's why the plant is still running. If you had caused a major fault on the PLC you would probably not have time to post here

Share this post


Link to post
Share on other sites
No doubt Michael, I'd be running! So I may be re-installing RSLogix500 then, from the sounds of it.

Share this post


Link to post
Share on other sites
This is a bit of a shot in the dark. Close out or exit your RSLogix5000. Open up a file manager and find the folder that contains the ACD. Check to see if extra files for the project are present. Specifically, YouProjectName.Sem and/or a SQL Server Log Shipping Work File with your project name. These files appear when ever you open a project and sometimes, during a crash of RSL5K they don't get removing and act like a lock file. Consider moving these files out of this folder to a temp holding folder. Do not delete them! You might need these later. Restart RSL5K with your project open and attempt to go online, hopefully the RSL5K will correlate any changes between the offline and online copies and then allow you to continue your work. Edited by pcmccartney1

Share this post


Link to post
Share on other sites
Thanks for the suggestion pcmccartney1. Looked in the folder and there were SEM and WRK files present. Moved them out to a temporary folder, went online, got the same error. It made two new files like the ones I removed, and both are at zero K in size. It always crashes when the status display says the program has just begun "Correlating" the offline and online versions. When I try to do a clean upload, it goes for quite a while until it starts to build the routines, and then I get an EXCEPTION_ACCESS_VIOLATION error. The program is about 6.5 meg, nowhere near the maximum size, and has been edited successfully many times to date. Stumped so far. I'm almost afraid to try a clean upload even if I could get the chance with the plant down, but it seems there's little choice at this point. I've verified I can go online with the two other controllers onsite. The problem is only with this one. I'll let you know what happens.

Share this post


Link to post
Share on other sites
So I have a different question related to this problem: It has been suggested to try a repair of the RSLogix 5000 application, since it is the application that is crashing. I am not sure about this, the application works fine with the other two controllers. If this is done, will it screw up my version? The install is up to V17.1. Will the disk overwrite any updated files during the repair process?

Share this post


Link to post
Share on other sites
Okay, I've talked to Tech Support and they recommended I export the most recent saved file as an L5K version, then re-import it as an ACD file with a new name. That has been done, and I'm waiting for the chance to download this new file to the controller. We will be shutting down the plant for an hour later today, so I'll have my opportunity. Still no word on what caused the fatal errors in the first place, I'll pass on the logs to the Tech Support guys after we get through this problem. Keeping you posted, speakerman.

Share this post


Link to post
Share on other sites
Hey everyone; So we are up and running after a short delay. Seems the solution provided above did clean the file up and it did upload properly. Unfortunately, it also set all controlnet connections as scheduled by default, so it turned off our ethernet IP network for 9 critical pumps. It selected them as scheduled even though they weren't, and greyed out the selection to turn it back off. Tech support indicated afterwards I should have told them we had an unscheduled controlnet before we started, so word of caution to everyone. We ended up downloading my last best save before the crash, which was the file I had open when the fatal error occurred, and it worked fine, no problems so far. All the ethernet IP modules are back to being unscheduled, and the plant is able to run. In a previous thread, Ken Roach helped me to understand why this system was designed incorrectly from day one, with ethernet cards in every remote rack - and one of them was used for this drive network before we understood the trouble that may cause. I am working on getting it changed, but in the interim it does work fine, and until now has caused no issues. Tech Support said EVERYBODY uses controlnet scheduling, 99% of the time, and our facility is an exception. So, a quick poll - are they right? is it highly unusual to have a contrologix PLC system with the controlnet unscheduled? Ours is pretty small. 14% load, 5ms NUT. My face is ready for some egg... At least we're running. Lessons learned all round. Happy programming, speakerman.

Share this post


Link to post
Share on other sites
I wouldn't believe that 99% of ControlNet is scheduled. I know that here on our site that we do a lot of messaging that is unscheduled. Unscheduled traffic is non time critical data. We do have scheduled ControlNet as well. The problem always with this is that you mayl need to re-schedule the network if you change certain parts. If you have a large network or a very critical process that can't be stopped only on very rare occasions, then this may cause problems. I know someone like Ken will be able to tell you a lot more on this subject.

Share this post


Link to post
Share on other sites
Since ControlNet has been around for a long time and because any legacy ControlNet system needs to be scheduled this habit has been "migrated" over to the new Logix Class systems, albeit the new platform allows for both scheduled and unscheduled networking. Maybe 99% is a bit of a push; I'd lower it to some 75-80% of the functional Logix ControlNet networking. However, in this day and age, when comparing ControlNet's capabilities and deployment requirements with the EtherNet/IP's ones, unless strict determinism is a must, the usage of the more modern Ethernet networking should prevail. I don't really see the reason for operating Logix unscheduled CNet networking but on a temporary basis, when migrating from a legacy control platform and awaiting the replacement of the modules and media with Ethernet equivalents. The deployment and maintenance of CNet coax media is exponentially more complex than the Cat.5-6/RJ45 one; there really aren't any advantages when running Logix unscheduled CNet when compared to EtherNet/IP but plenty of drawbacks. Moreover, scheduled Logix CNet networking does not make sense unless the system services a highly critical application, such as a nuclear power plant, chemical/refinery operation or other hazardous environment works; for a 24/7/365 process, scheduled CNet networking also implies redundancy, doubling-up the "engineering load" since, as it has already been mentioned, any component's replacement will most likely require re-scheduling hence idling of one of the two (redundant) systems at a time. Edited by dmargineau

Share this post


Link to post
Share on other sites
Interesting, this was my thought exactly. We do have a scheduled controlnet, just the ethernet IP portion is not scheduled. Most of the analog cards are, but we had to add and change a couple on the run, so we weren't able to schedule them at that time. Everything worked just fine until we could get them into the schedule a few months later. We do plan to move these ethernet connections into rack 1, and then the controlnet issue goes away. I think that may happen faster now it's caused downtime.

Share this post


Link to post
Share on other sites
Let's clarify one significant issue here though: Only the ControNet networks are exposed to "scheduling"; EtherNet/IP networks, just as any Ethernet based networking protocols, cannot be scheduled; connections over Ethernet could be "managed" (prioritized)via "Managed"type switches, however, they are overall functioning on a "first-come-first-served" basis.

Share this post


Link to post
Share on other sites
Yes, dmargineau, I forgot to restate that as of now the ethernet IP is done through an ENBT card in a remote rack. The configuration dialogue does ask if we want to schedule their connection over controlnet, and of course it is deselected. It has worked flawlessly so far, as the amount of data is relatively small. Our controlnet itself has always been scheduled, and will continue to be. Once we have the dedicated EIP card hooked up in rack 1, we can add more unscheduled EIP modules to it there. We have four more items to integrate on EIP, and they're on hold until the network to the rack 1 card is complete.

Share this post


Link to post
Share on other sites
Hey everyone; Quick note, we completed the installation of the ENBT card in rack one, and the connections from the old card in rack 3 have been moved to it and are working perfectly. Happy programming, speakerman.

Share this post


Link to post
Share on other sites
These sort of "crashes" were fairly common in the early days of CLX. There was never any explanation or repeatability -- but the fix was always to export to L5K and re-import. I don't recall experiencing it since version 15 came out, but I guess, from your experience, the gremlin still exists. What you say tech support told you to do sounds a bit odd - I would have suggested: export the offending program to L5Ksave the offending ACD under a new name & closeimport the L5K (should create ACD with original name)go onlineI've done this more than twice in the past.

Share this post


Link to post
Share on other sites

I had this same fatal error and have resolved it ( without scheduled controlnet )

I exported latest file to L5K. Imported into new project with different name. Logic window showed errors with line number in the notepad file which opened automatically. Took me to a crazy old CPT instruction with the largest equation I've ever seen inside it. Deleted CPT instruction, verify controller, could not verify that routines location anymore. Created new routine with different name and copied the good rungs into it. Deleted old routine. Renamed new routine what it used to be. Error free, can now open from upload no issues. Thank you Speakerman for keeping this updated! Hope this helps any future shenanigans.

Dan-o

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