firebird0095

The front of the PLC shows an IO error. The Ethernet is integrated in the processor on the Compact Logix, but the lights are blinking and showing traffic on the line. The switches all come right back on as normal. I never get enough time when there is actually a problem to really troubleshoot this, so I am going to simulate the condition as soon as possible when production is not running. The "fix" for it is to power everything down and then back up again and it works. There seems to be something different about it when the whole building goes out.

Well I am back to ask the experts and see if anyone else has had a similar issue as I am not having any luck fixing this one. I have a completely separate (physical and subnet) ethernet for the machines. I have a compactlogix controller that is essentially a central control and monitor for some simple machines and building utilities and the I use Point IO spread out all over the building to interface with about 30 different pieces of equipment through three main drops with 1734-aent adapters. There is a Panelview Plus in the mix also to display everything that is going on. The problem is that after a power outage - either brown out or completely out - it all seems to lock up. The panelview will display numbers, but they are unchanging. The PV will sometimes have an error message about not being able to connect to the PLC. The outputs on my drop points are all off and stay off even though they should be cycling on and off. I have put battery backups on everything including switches to try to stop it, but it still gets messed up now and then. I am using the watchdog timer in the main controller, but I have not found a similar option for my drop points. Is there any way to force them to internally reset after the power comes back on? Has anyone else had this?

For some reason that never crossed my mind. I was thinking that the setting would be stored in the device and not in the program. I put an EEPROM in the PLC and am going to test it as soon as I get the machine down. I bet that is the fix. Thanks again.

I have a 1785-ENET A that is in operation and functioning on a 5/20. This is a connection to communicate between two different controllers. I must be doing something wrong in the setup and I need another viewpoint as I have been in it too long. If I go online through the serial connection and manually enter a static IP address everything will work on the ethernet connection. Then if I cycle the power the IP address is gone. It is as if it is trying to do BootP or DHCP even though I have not selected that option. The only thing that seems to hold me over through a power cycle is to set it to BootP and have the program running on a pc attached to my machine network. I really just want to enter a static IP address and have it never change. I do not want the machine to be dependent on any other piece of equipment. Is there is a certain order of operations to make this work? Is it possible? Does the series A module default to BootP or DHCP after a power cycle? There has to be something simple that I am missing, but I have combed through these forums and the manuals with no solution... When the maintenance guys lock out the machine I end up losing comms and then I get the phone call that everybody loves at 3am. Thanks for any help you may offer.

Can anyone tell me what changed or was fixed between 1756-L61 Series A to Series B? I have looked everywhere I can on the Rockwell site and only found release notes for the firmware, but nothing about hardware series changes. I don't have a Tech Connect contract and I have a hunch it is buried in there. Any help would be great. Thanks a lot.

The UDT and the parameters were two separate issues. As you said, they work just fine together and you do not have to use an entire tag address as in your example. You can use a parameter as just a portion of a tag. What I could not do is use a parameter as a string. I had already done the trick of creating string tags and using the parameters to go to the appropriate string tag, but I don't like it. The whole point of using parameter files is to reduce the hard coding and keep things flexible. Creating more tags goes against this when I should just be able to concatenate a string from a parameter onto the end of one of my strings. I still need to get the new software as was suggested and see if that fixes it. The UDT issue was with data logging a UDT in a PV+. It does not work for some reason. The UDTs I was trying to use were already in two places in the program for my PID, so I just logged them from the PID(.sp, .out, .pv) and that works. I am now having another data logging issue where it seems to log some variables and not others and I am not getting any error messages. Oh and by the way there are no troubleshooting tools built in, so you are just left to speculate and try different things until the allen bradley gods smile upon you and your PV+ begins to log data as if by magic. Keep the faith.

Thanks for the input guys. I like the idea of only creating one screen and switching variables on the fly purely for the reduced memory usage and reduced chances for me to type something wrong and screw it up. Since nobody seems to have much experience with parameter files I will tell you what I have done and maybe someone can use it. Assumptions - We have 20 different machines and we want to display the same info for each machine on each of 20 different screens. Your data from the machines is stored in arrays or even better, UDTs. This allows us to play with the array index to pick the machine we want. 1) Create 20 parameter files. Lets use the first machine (machine 0 in computer world) as an example. Under "Graphics", right click on "Parameters" and select new. A box will pop up with a header in it, and below the header type #1=0. Hit save and type 0 as the component name. You now have a parameter file 0 that contains only 1 parameter(I don't know why AB cannot be consistent and start parameters at 0) and that parameter is the array index for our machine 0. Now you need to create 19 more parameter files. File 1 will contain #1=1, file 2 will contain #1=2... The #1 is the parameter number and the part to the right of the "=" is what the parameter file will return for that parameter when called. 2) Now you create your universal screen that you want to use for all 20 machines - let's call it SuperScreen. Say for example you have a box on that screen where you want to enter temperature. The variable for temperature is in the format of Machine[X].temp since we created a UDT that defines each machine, or it could be just Temp[X] if you created an array of DINTs to hold your temps. Instead of making 20 screens and changing from Machine[0].temp to Machine[1].temp... All we have to do is use Machine[#1].temp as our tag address and make sure we specify which parameter screen to use at runtime and the value in parameter #1 of that parameter file will be substituted as our array index. 3) Now you want to use this screen. On your main screen create a Goto Display button and under Display Settings select SuperScreen as your display and 0 as your parameter file. This will open our universal screen and display the data for machine 0. My problem comes when I want to use a parameter for something other then an address. Otherwise it works pretty well. Hopefully that makes sense. It really does make life a lot easier using parameter files. Hopefully AB will continue to enhance these functions and allow greater flexibility in working with strings and creating more powerful code. Thanks again.

I am using a PV+ with a compactlogix L32E processor. 1) In my program I have created a user defined data type that contains several different variables relating to one piece of equipment. I need to data log and trend several of these variables, but when I try to do this FTView lets me compile and does not complain while the PV itself claims I have used an invalid tag format for the data log. With a little help file research, it says - "You cannot log data for string tags, array tags, parameters or expressions, and you cannot use tag placeholders in your data log model." I am guessing it is considering my variables inside my user defined data type as parameters. It will however let me trend the variables embedded in the PID data type. What is the difference? Is there any way around this aside from creating independent tags somewhere else and MOVing everything? 2) I have a screen in the PV+ that uses a parameter file so that I have one screen that accesses 20 different sets of variables depending on the parameters sent when I open the screen. I want the title at the top of the screen to change to display what machine the operator is currently looking at. How can I use a value from a parameter file in a string for a textbox? Example - I created a parameter as #2='11' and attempted to use parameter #2 in my textbox as a string variable to display as "DCM 11" and that did not work. There has to be a way. Thanks

Thanks Paul. That's not what I wanted to hear. I cannot find anywhere a list of faults that you can catch and those you cannot. I wish this was a more powerful feature. I would like to be able to just disable the routine after a fault occurs that caused the watchdog to trip since it is always the email routine that is separate from the part that is doing the real work. I have tried to account for every possible error with email, but now I think that sometimes our server just takes a couple of seconds to respond. The last time it faulted it was trying to send a valid email string. I increased the watchdog to 5 seconds and we will see what happens. I would like to disable it and be able to put in my own where I want them.

I need some help with a fault handling routine using a CompactLogix L32E. I have looked all through this forum but cannot find any previous posts directly related to my current problem. If this has been done before please leave me a link. I have followed the instructions here - http://literature.rockwellautomation.com/i...pm014_-en-p.pdf - but I am still having an issue. I am sending emails with this processor, and every once in a while there is a gremlin that I have not killed yet and he mucks up the works while sending an email and my processor faults out due to the watchdog timer expiring. I will eventually find the real source of the problem, but in the meantime I cannot allow the processor to shut down. I have created fault routines for the controller and the program that simply use a GSV to get the fault and a SSV to send back 0 for the type and code. According to the manual above this should clear the fault and let my processor go on with life. It doesn't seem to work. The type 6 code 1 task watchdog fault is listed on page 28 of that manual and there is no mention of it not being recoverable - am I missing something? I feel like there should be more to it than simply resetting the fault codes. Do I have to reset the watchdog timer? If this thing shuts down when I am not here to catch it I am going to be in big trouble. Is it a valid test to intentionally create an infinite loop forcing the watchdog timer to finish and see if the processor keeps running when I trigger it? If there is any better literature please let me know. Thanks

Peter - I am checking out your website and will be in contact with you. The +/-.250 is for the transition to fast speed occurs when the machine is at intermediate speed which is 20-30in/sec - technically I should say +.5/-0 because it is always late and never early. It is +/-.250 from and average point that is somewhere after my setpoint. When it is at fast speed 100-200in/sec and I try to get a low impact cushion it completely misses it and I get nothing. I am liking the sound of your design, and If I can capture shot data real time then I can do some really cool stuff. I have a dream of ethernet everywhere and I am trying my best to set myself up to do it. I have one machine now that is all ethernet, and everyone realizes how nice it is when I can connect wireless anywhere in the building even when I am plugged in and working on a different machine. I still have to convince them that we need to spend the $ for ethernet everywhere. Paul - I am trying my best to get up to speed on all of the safety system stuff, but sitting around drawing schematics for relay systems and then trying to convince my wiring tech to do it all are making my hair fall out. There is a cost associated with ease of installation, and that is what is coming into play for me. With a three zone system and the number of interlocks I have I am not very far off from ABs smallest safety controller. I am trying to bring a place up to speed that has had no engineers at all for years and no controls engineers ever. I am in up to my ears. Even now, I only get to do controls part time. I am doing design work the rest of the time. Thanks a lot everyone.

Thanks for all the input guys. I did not want to come off as whining, I just have some pet peeves and wondered about the alternatives. The best thing I found for the maintenance guys was I got them an old computer that actually has two serial ports so I can leave the DF1 driver and Pic driver running all the time and they never have to swap it. Before, they used to use my computer for troubleshooting and it only has one port. Invariably they would get stuck trying to get rid of the PIC driver to load DF1. Either way, it is resolved and I am getting a serial card for my computer so I can do the same thing. I had the feeling that the other guys price difference came with some flaws and aggravation of their own, but having never used them I wanted to be sure. I do not think Mitsubishi is better, as I have never used one - we just have a few around in accessory equipment that do basic jobs. Also, I did not mean that I was asking for product support for the 30 year old PLC2s. I don't bother calling support for them - I just replace them. It is a good excuse for me to get a new PLC! My application is high pressure die casting. I drive a hydraulic cylinder to inject the metal, and it runs in either three distinct speeds increasing as it goes forward or in a ramping type mode. I read an encoder into a high speed counter card and then drive either an analog output to a proportional throttling valve or several discrete outputs to multiple DCVs in a binary throttling system. The critical point is the transition between intermediate speed and fast shot. The time it takes for everything to accelerate is nearly constant, so if the transition point moves then the point where I get full speed is all over the place. The more consistent I can make this the more consistent the parts will be. I also put in a fourth speed to choke it off at the end and cushion the impact on machines that have proportional valves on them. This is where you really need high speed because everything is up to full speed at 100-200in/sec. I have a PLC5 running a machine now, and the best it can do on fast shot transition is +/-.250. This is ok for the parts we are running now, but I would like better. I think this is basically block transfer time stacking up on top of scan time and making a little delay for me. Some shots it nails it right on the setpoint because it caught the scan at the right time. Other times it will be up to 3/4" late but usually only 1/2". If there are other hardware based solutions outside of a PLC that can do this I would be interested, but only if they are as programmable as a PLC. I like the ability to add steps to the cycle or ramps etc. The ethernet/IP is a dream for me at this point - programming purely on ethernet would be excellent. I have only convinced the powers that be to spend money on ethernet once, so I have one machine that I can troubleshoot from my desk. Now everybody is seeing the possibilities. I would like to network them all together and have a plantwide monitoring/troubleshooting capability. We are so far from that at this point I cannot really put too much stock in it. I have to get all of the machines working properly first. The sad thing is that the programs I am changing are factory programs that are actually custom made for the machine. There are no unnecessary functions, just poor and wasteful programming practices - and my biggest pet peeve of all - no comments. Paul - I love the bit about Microsoft PLCs - all very true. My point was just that PLCs have not kept up with PCs in terms of basic ease of use things. I understand the difficulties involved, and yes I have written device drivers and embedded operating systems in another life. I did not do any huge projects, just some embedded C and pic chips. It took a big shift in my programming state of mind to go from that to PLCs. While you guys are giving your opinions, what about safety controllers. Has anyone used any of the smaller AB safety plcs and or the safety modules for the logix line? I have only used relay based safety systems, but ease of installation and design with a programmable controller has gotten my attention. Any thoughts or opinions? System is three to four zones with a robot and up to two presses and an average of 10-15 interlocks. I have tried the MSR300 series relays, but I would like more flexibility and really need the fourth zone. I guess I just need to get some old programming buddies together and start a company making PLCs with only an ethernet and usb port and free programming software. The whole thing will be redundant control and safety rated as standard. I will let you guys know when we are up and running!

I already know how to get Linx to see our equipment and have no problem doing it, but it is still annoying that everything has different drivers and cables. It is nearly impossible to teach maintenance guys how to get online for troubleshooting. The first AB PLC class is all how to get online - an entire class for two days about how to get online - it should not be that difficult. There have been several robust and standardized communication schemes in the PC industry for 20 plus years. I still think that there should be a usb plug in every processor from PLC5 and up. Why do I have to load drivers? I can plug in a printer and not have to load its drivers every time. See where I am going with this? It is not that it is difficult or that I can't figure it out - it is just annoying. User friendly it is not. Put it this way - AB PLCs would be a lot easier to use if Microsoft made them - now that is saying something(I didn't say reliable). I have no real use for MSG instructions where I am now. Each PLC is in one rack and runs one machine and does not talk to anyone else. All it needs to do is sit there and run really fast. I optimize my programs to remove all waste and I even organize my instructions to speed up the processing when in auto mode. I usually can cut scan times by about 30-40% from what was there. Now if I had some hardware to help me go even faster then I can make the machines even more accurate and precise. My machines move very fast, so every ms of scan time is about 0.1" of inconsistency. I trust AB products. We have processors here that are getting close to 30 years old and they are still kicking. They make good stuff. The tech support issue is annoying, and I agree that when you pay thousands of dollars for a single product that it should be supported without a contract. There are other suppliers that answer questions happily. I did not say hold my hand and teach me how to use it, but when there is a problem with their product they should help you troubleshoot it - that is simply standing behind your product. I do not have a support contract with the CNC machine dealers, Parker, Rexroth, Keyence, or anyone else but they answer questions when I get stuck. I really do not like the fact that you cannot get to all of their support site without the contract. I can sympathize with Peter not wanting to answer questions all day, but the website is the most valuable resource most of us self taught people could draw from to figure it out ourselves and not have to call tech support. That is why they want to charge for it. It just does not seem right to me. All of that is annoying, but it is not a deal breaker. The deal breaker is the cost. Plain and simple they cost too much. The hardware is overpriced in the first place, and I do not think you should have to pay for the software for programming. You just keep getting nailed with add on costs. I only have legacy equipment to work with here, and upgrading is not going to happen any time soon at AB prices. I learned on the Logix platform and have gone backwards so I know the difference there and would love to have them instead of the antiquated stuff I have now. Thank God for Ebay. OK - anyway - the point here was not to write a book about my AB pet peeves. I want to know about the alternatives. Please someone who has used other systems give me some specifics and comparisons.

Admin - feel free to move this if the AB forum is not the appropriate place for this. I am getting fed up with AB controllers. The communication is always a pain. Different drivers, different wires, unsupported firmware... not to mention extremely high cost. I just got one of the new control logix systems to test here, and it is a royal pain in the butt. They are very expensive and then you have to spend another appendage to get the software to program them. I do not want to make that step out of blind brand loyalty and complete ignorance. I am now thinking about switching brands. We have some equipment here with Mitsubishi controllers, and I have heard others speak highly of them although I have never tinkered with them - they never need it. I need a controller that has high speed capability (controllogix speed or better) and I would need to have an HMI with similar capabilities to the PV plus. I currently work with mostly older PLC5 and SLC500 systems with either PV or PV plus HMIs. I do not want to have to do a dance to talk to the thing either. Ethernet is much prefered for networking, and USB or RS232 for programming. As for complexity of the machines, there are max 300 discrete IOs with encoders and analog in/out too. When I reprogram a machine I usually end up with less than 400 lines of code with a modest amount of math. In my industry, the iron has not changed - just the controls. Upgrading the controls makes a big difference in consistency and reliability and that is my final goal. I would like something to ease the AB pain but be just as reliable and preferably faster processing - aka have my cake and eat it too. Am I crazy? Has anyone else switched? What difficulties lie ahead? How does cost compare? Please enlighten me to the possibilities. PS - something with safety control modules in the same chassis as an option would be really handy too. Thanks - and have a good Easter weekend