speakerman

MrPLC Member
  • Content count

    84
  • Joined

  • Last visited

Community Reputation

3 Neutral

About speakerman

  • Rank
    Sparky
  • Birthday 10/06/65

Contact Methods

  • Website URL http://www.innotechglobal.com

Profile Information

  • Location British Columbia
  • Country Canada
  • Interests High resolution audio playback systems for music listening or movies, carpentry and cabinet making, cars and driving, great food, great experiences of almost any kind.

Recent Profile Visitors

1870 profile views
  1. [Demo Software] - Allen-Bradley Logix Family Tag Browser

    Thanks for the trial download. Will give it a look. Price? Happy programming, speakerman.
  2. Hey Leo; I have a manual for that series of PLC, and I know it can be programmed with ProWorx NXT or 32. You do need to know what it was programmed in, and the program printout should identify that somewhere in the header or footer. Otherwise post some pics of the soft copy and it may be apparent. We have a 984-245 here at our plant, and will be phasing it out at some point, but have been able to find refurbished spares and they can also be repaired. It's expensive though. Depending on the application you may have better luck changing the PLC entirely should something fail. You have the program, so that makes it easier. I've uploaded the manual for the PLC familyCompact.pdf in case you need that. Happy programming, Speakerman.
  3. Hey Modiconbob; Thanks for the reply. It's RG-11 trunk, quad shield, but we have since discovered the route has been done improperly to the one drop we're having issues with. The original cable is in conduit on the side of the cable trays, passing above drop 9 on the way to drop 7. There used to be the terminal resistor in drop 7, but when 9 was added they just pulled a tech cable of RG-11 back to 9, laying it in the cable tray with everything from 240VAC to 600 three-phase. It has been this way for a long time without the issue cropping up as far as we know, but over time more and more stuff has been added to that cable tray, so the chance for noise has been slowly increasing over the years. The whole network is about 1200', but most drops are within the first 500. There's a 650' run from drop 5 to drop 7, (They are not in numerical order. It's 1, 8, 2, 3, 10, 4, 6, 5, 7, and 9 in that order. From 8 to 5 is about 400' total. The document with that information has been taken away right now; it's not handy so I can't be exact. We have a plan to add more conduit down to the PLC cabinet, then pull the original trunk cable back to drop 9 and pull a new RG-11 in the remaining conduit to drop 7, making it the end of the line again. This will eliminate the tech cable in the cable tray, and all the coax will be in proper conduit isolated from the rest of the wires. Putting drop 9 in line to drop 7 instead of daisy-chaining back will reduce the length by about 100' overall. Drop 9 has about 4 to 6 retries per second on average. The other drops have between 1 and 2, sometimes none. Very occasionally we'll see three retries in a second on the other drops. The drops closest to the head are the best, obviously, and have the fewest of all. The duration of the dropouts on drop 9 are so far only for one scan of the PLC, and maybe once a day on average, so it is very marginal at this point. We do not have testing equipment for the cable system onsite, and were looking for a contractor from Schneider who could come and assess it. Now that we've discovered this routing issue, we'll address it for sure and see how many retries we have after that is done. Thanks for anything you have to add. This may be a "we post our resolution" kind of path, and that's fine with me. Originally we didn't think we had a cable problem, but now it looks like we do. Will let you know what happens when the cable is re-done. Happy programming, speakerman.
  4. Hello everyone; Long time no chat, been way too busy. Got to cruise the forums for some pay-back after this, it's been a while since I gave back. We've run into a problem beyond my experience, so I have a question for people well versed in the Modicon PLC remote I/O world. We're having some drop-outs with a remote rack of a quantum PLC system, and can find no problems with the cables, taps, or the RIO drop card. We're seeing what seems like a lot of retries, but then we don't know what constitutes a lot. There are 10 drops on this PLC. Drops 1, 9, and 10 are quantum and drops 2-8 are old 800 series. It's a CRP931-00 remote I/O head with a bunch of J890-001 cards, and two CRA-931-00 for the new racks. Funny, but the two quantum racks have the most retries of all the cards. A couple of the 800 series have almost no retries by comparison. The quantum drop 9 has had dropouts at random, sometimes twice or three times a day, sometimes none for a couple days. Causes major problems, obviously. Drop 9 is actually at the end of the trunk cable, so it's got the terminal resistor on one tap. Drop 10 was added later between drops 3 and 4, and has more retries than either of them, but no dropouts. We've asked Schneider for a contractor who can perform a RIO cable network integrity test, but it seems to mostly be these two quantum heads with the most retries, and only the one has been dropping out. Is there anyone who has seen something like this and can comment? We've changed almost everything around it and there's been no change to the retries, and the occasional drop-out still happens. Hope things are going great for everyone out there. Happy programming, speakerman.
  5. Fatal Error when going online

    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.
  6. Embedded Variables CCW Micro 810

    Hey everyone; Thanks KidPLC, this is very helpful. It's is a long time after your post, but I am just now looking at a Micrologix 810 and LCD combination, and this is the only post I could find pertaining to that model. I'm trying to find out more on the LCD and what it can do. The on-screen menu lists the ability to modify variables, but the manual states "This feature is not yet implemented…" So does anyone know if and when it will be, or if perhaps it has been by now? The LCD is pretty useless without this functionality, and it is in the menu, so one would think it would eventually "be implemented"… Any Allen Bradley moderators or power users here know the skinny on this one? Thanks, Speakerman.
  7. Fatal Error when going online

    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.
  8. Fatal Error when going online

    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.
  9. Fatal Error when going online

    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.
  10. Fatal Error when going online

    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.
  11. Fatal Error when going online

    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?
  12. Fatal Error when going online

    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.
  13. Fatal Error when going online

    No doubt Michael, I'd be running! So I may be re-installing RSLogix500 then, from the sounds of it.
  14. Fatal Error when going online

    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.
  15. Omron Ethernet/IP to Allen-Bradley Ethernet/IP

    Hey lostcontrol; It's been a long time, sorry to leave it hanging. We haven't had an opportunity to finish this, the plant has had other priorities. We are so close to trying it, the network infrastructure is almost complete back to the CPU rack. I'll let you know how it turns out. Happy programming, speakerman.