PLCMentor.com

Yeah there are no separate rung titles and rung comments in the 5000. I actually like the advanced diagnostics presentation better in the PLC5 and SLC but you did have to set them up properly. The browse logic does give you similar capabilities just with more clutter and a little less convenience. On the plus side, the 5000 stuff lets you organize your program so much better that I rarely miss the advanced diagnostics and really dont need the browse function much either. On the whole, there are not many things I want back from the pre 5000 days.

Well since nobody else has taken a stab at this I will - with a qualification that I have not used the flex logix plcs; however, I do use a fair amount of flex I/O. My assumption here is that you are also using primarily flex i/o with this system. With that said, I would think it would be relatively painless to add and AENT and convert your I/O to remote I/O on either a compact logix platform or control logix platform. You could go with one of the other networks, but I have found Ethernet I/P to be a solid communication medium and easy to setup and troubleshoot.

Ok you mention that your ramp needs to be closed loop. I think what you are saying is that you need to control the pressure closed loop (thus the PID) and then you need to ramp that pressure from 100 to 1000 psi. In thinking about this, you need to separate the two tasks. You have a need to control the pressure and the PID instruction is the best means in which to do this. Then you need to ramp the SETPOINT of the PID from 100 to 1000. During the ramp your PID will work to maintain the feedback pressure at the setpoint required. You can ramp the setpoint by simply adding to it a controlled amount controlled by a timer or an STI (timed interrupt) routine. There is also a ramp instruction (RMP), but I have never used it. It may be a little overkill for your requirements. Now if you had a linear response on your output and input I would just ramp your output signal and do without the PID to simplify things. I suspect from your post that you need to control your pressure as there are factors that can cause the pressure to be different at a set output.

Check with your rep. sometimes they will just let you renew your support if it's close - never know until you ask. You can always use a rule of thumb with Rockwell - if I ain't paying, I ain't getting.

Michael, I just saw this and I really like how you use the structured text to load up your UDT! Very nice and straightforward. I have always used aliases and left them outside the UDT structure. It has always worked well for me but I like how you handle this and I may have to contemplate a future change... Using the SLC type tag names in the Logix drives me crazy also. The tagnames and UDT's are two of the best things about the logix. Why would anyone not use them? I will add that I split my UDTs into two halves. I have an interface UDT and a behind the scenes UDT. The interface UDT contains everything I need to interface with the SCADA (start/stop pushbuttons, status, etc). The other UDT has all the internal stuff that the SCADA doesnt care about (start/stop timers, alarm timers and other misc bits and words). Also, I would be interested in seeing how you handle your alarming. That is something I am never happy with. One point on the comments about the Logix vs. CompactLogix is that I believe the CompactLogix is underused by many designers. I am amazed when I come into a facility and they have small mini processes or machines with the daddy logix on it. The compact platform is a very capable little machine and can handle a lot of load. Bob, I would be surprised too! Sounds like a cool system and a beast of a process. Sign me up when you put that tour together!

Well as usual, Ron pretty much sums it all up. I think the Logix platform is fantastic. The tag based structure, UDTs, flexibility in programming languages and other things make it a great system for the programmer. As mentioned by a previous user, a program can be developed in such a way as to make quick implementation easy. Documentation of the program due to UDT's is quicker and easier. Communications are generally much easier to setup and implement. Lots of plusses. If you are familiar with the 500 then the ladder logic should be fairly easy to bridge over to. Much of the other areas of the software are very different and will take a learning curve. In fact the system is powerful enough where I doubt anyone has fully explored all you can really do with it. That all said, with flexibility often comes the ability to make things complicated. As Ron mentioned this can make it tough for the maintenance guys that have to come in and troubleshoot. There are a lot of things that a programmer can do to make it easy on themselves which makes it hard on the maintenance staff when troubleshooting. Just keep this in mind when programming and program for your audience - which generally means simpler is better. Helps you out at 3am when figuring out a problem too.

Make sure you disable your Bootp now. You may have already set your IP up, but if you didn't disable your Bootp, then it reset everything when you powered the PLC off.

You also should take some time to determine if this is really how you want to do this. Maybe you have the hardware and need to use it so you deal with what you have. If you have any choice in the matter, I would find another operator interface that is not RIO. RIO is a difficult medium to deal with on operator interfaces with the PLC5 that handles RIO natively. Add in the complexity of a SLC and you have made it a worse option. I think what you will create is "that system." The one that only you can deal with because it is a pain for anyone else to come up to speed with. Sometimes we have to use the hardware handed to us, but I would not suggest RIO on any operator interface and even less so with the situation you have.

I have not used that particular module before, but I looked through the manual (briefly) and could not find anything mentioning the x10 scale up of values. I have used a flex block RTD module where it handles the range selection automatically due to the sensor selected similar to how your module works. The values did come in scaled x10 on that particular module. I just simply scaled the values and moved on. I suspect that is done to give you a decimal place.

Doh! I saw temperature and immediately thought input. Right with the OF4 we are talking output... Teach me to post quickly.

Looks like you have not loaded the firmware into the processor. The message is telling you that the processor has firmware version 1.4 and you do not have that version on your PC. Your must have the same version of firmware on your PC as the processor you are trying to connect to. I cant remember exactly what firmware rev a new processor defauts to, but it is a 1. something. Are you sure there is a program on the PLC or is this a new PLC? Are you trying to get the program off of the PLC (upload) or put a program on the PLC (download)? Those terms are backwards from what most people in the computing world expect so lets make sure we are talking about the same thing.

Mark you have the scaling backwards. You will need to plug it in this way: Input Min: 6241 Input Max: 31206 Scaled Min: 70 Scaled Max: 400

Nice List! We do go back and forth between red for off/closed and grey. People joke about the stoplight mentality, but it is something that is natural to just about anyone. If we use red for off/closed then we usually flash any alarm. I will say that some SCADA/HMIs do not flash well so grey for off is preferable. We also use yellow for intermediate or ramping for drives. I will add to number 7 on touch screen design that all motor/valve/sequence activations should be two touch. In other words to start a motor you would touch the motor on the screen to bring up a popup that will have start/stop buttons. In systems (mostly older) that do not allow for popups, touching the motor will take the operator to a special start stop screen. The big no no is to put the motor on the screen with start/stop pushbuttons next to it for control. Invariably someone comes through for show and tell day and points to the screen a little too emphatically and starts the motor. Usually more of a demonstration than they wanted. It also is usually the plant manager or someone from upper management showing a client around. Not a great sales tool. Having an overview screen with little or no controls is a plus. Generally the specification would allow touching specific individual processes on that screen to "zoom" into the actual control screen. The security levels listed are good. Their definition needs to tie into the PLC control definitions also. Generally operator control gives normal processing control of the system. Supervisor control gives override, mode change and approval capability. Maintenance gives the ability to change equipment and process modes. That ties into the PLC definitions of Automatic, Manual and Maintenance controls of the equipment. Automatic is fully sequenced according to the process description. Manual allows the control of individual equipment with all permissives, and Maintenance allows control of individual equipment with permissives overridden (except safety). But now I have rambled on to plc definitions... Hard to put a spec into a forum, but Digita's points were a good overview.

I agree. I tend to like to drop my I/O close to the equipment to minimize hard wiring. In fact on many projects, we can use a similar panel design for our remote drops lessening the design costs. The flex I/O and point I/O are a little more expensive than rack mounted I/O, but if the rack I/O is installed properly then they wire to interposing terminals and between the terminals, wire and install time the I/O drops are cheaper. You may need to check the PLC and see how much memory there is and CIP counts are important when dropping I/O so read up on that. If this is a new application that has not been installed, I would not just add a second PLC for no reason. If there is a logical divide between two systems or processes then it may make sense. In other words if you can bring a line down and the other line can run without it then a second PLC would make sense. If the two lines depend on each other such that one cannot run without the other, then I would try to put everything on one PLC. All that said (or written) we are trying to move away from rack mounted I/O for most of our I/O needs.

Agreed! Plus the more complicated you make the system via multiplexing or otherwise, the more difficult to startup and troubleshoot. However, if the primary purpose is to decrease hard wiring then the point I/O recommended by Tim or flex I/O can be dropped local to your transmitters and brought back via an Ethernet cable (or some other comm cable).

What gets me is how much I pay as an integrator. So lets get this right... You want me to pay you so that I can specify your equipment? Uh, shouldnt you be paying me commisions? I never have understood that.

Assuming that one of the gateway devices work, what you will need to say to operate the valve will be found in the valve documentation. Specifically, there may be a separate manual just for the ethernet I/P interface. It should have lots of wonderful gobledeegook in there about what it needs to do certain functions. You will also need to check out the gateway documentation to investigate exactly how it interfaces with the Ethernet I/P device. That should be relatively painless. I have to add that it seems odd that you are having to go to such extremes to communicate when the valve and the controller are made by the same company - at least I think thats what you were saying.

I am going from memory so bear with me if I am off, but I think if you have comm problems with the AENT, then you blocks will all indicate network problems similar to what you are seeing. Has something changed with your ethernet network? Possibly flooding the AENT. Have you got a managed switch on the network? I know the AB drives are sensitive to their ethernet ports being flooded with packets and they will just stop communicating. Am I understanding correctly that you can power down the remote I/O and it comes back and works ok? If that is so, I think I would concentrate on what has possibly changed on your ethernet network recently. OK looking back at your post, why did you eliminate your ethernet connection/network as a possibility of causing the problems?

ok I'll be the dissenting voice here. I think it would be worthwhile getting a basic understanding of your systems. You mentioned it's a family run operation so I would assume from that there is already a tendency to become jack of all trades just to keep things going. I would suggest that you start slow and see if it makes sense to put in the time and effort you would need to come up to speed. At the very least, I believe it would be worthwhile to have a basic understanding of the PLC system to better troubleshoot problems. With that in mind, I would suggest investing just in a copy of the PLC programming software to start. Possibly work with your electrician to learn some basic troubleshooting skills. I think most contractors would feel comfortable bringing you up to speed on the basics. Looking over the shoulder and asking questions is not a bad way to start your learning, but it sounds like you have already installed your system and its up and running. Startup is a great time to learn some skills. If they are still coming out and working on issues then take those chances to learn. I think your aim here should be to learn to support your systems not necessarily design a new one. If you get good at that then maybe move on to making small changes. Eventually if you enjoy it then maybe work with your electrician on a new system. That way they are there to assist you. I say if you enjoy it because, as the other guys have mentioned, it will not be more cost effective. It will be hard to catch up to the efficiencies of someone that works with the stuff every day and is able to spread the costs of equipment and software over multiple clients. In addition a solid electrical background is really necessary to design a system from scratch. Thats why I suggested just starting with learning to troubleshoot your systems and see where that takes you. Being able to use the PLC to determine why something wont run and get it back up quickly would be a skill that will pay off over time.

As Michael mentioned, the N100:254 is a pointer for indirect addressing. What that means is that if the value in N100:254 is 10, then you will be moving your values from N10:0. Whatever value you have in N100:254 will be substituted for the file number. This is a simple way (for the programmer) to quickly program the system to move values from several different locations to a single destination. In your case I would guess that there are recipes and the pointer allows the selection of those recipes. Unlike Michael, I do not like indirect addressing. It is simple during programming, but difficult to troubleshoot and throws most field technicians for a loop. My mantra is always program for your audience. In other words keep it simple. That said, there are times that it is very useful and necessary.

I was going to suggest the PIDE also. I must admit, the CLX PID instruction does have enough bits and words to make it a little confusing. A little like directing a client to which version of programming software they need. I agree that as an integrator you need to have all the programing languages at your disposal. There are times that I am limited due to the clients restrictions however. I have often thought that putting the PIDE in a AOI would be interesting, but have never had to do it. Those thoughts aside, there are several points that you mentioned that I can make an immediate response to: 1. Do not use timers to handle your PID timing. The CLX has wonderful abilities for periodic program files - use them. 2. I do not copy my I/O in and out of tags to get around the async. read/write of the CLX and have never had problems. I know many programmers that do and I guess it works for them. For me it seems an unnecessary additional step. I do use aliases for all my I/O to give them meaningful tags. 3. Use UDTs, use UDTs and use them some more. It will do wonders to simplify your programming. Just the load it takes off of putting descriptions in your program is enough to make them worthwhile. They do need to be well thought out. 4. If you are stuck with ladder, there is an AOI for scaling that is useful. You should grab it. 5. Be careful with AOI's. Something simple like the scaling example mentioned above is great. More complected AOI's such as what you look to be working towards are a pain. There are times that they are OK, but they better be well tested because you are not changing them on a running system. You will have to change them offline and dump the program back to your processor. You do not want that. I would be interested on hearing from anyone that has a strong opinion on AOI's versus a standard subroutine. I really dont see the advantage to the AOI when I should be able to call a subroutine from multiple routines as needed. I guess you would have to have a copy of the subroutine in each task if it is necessary across different tasks. I dont really see a huge advantage in the AOI's for most circumstances. 6. I dont use real world I/O in my UDT's by copying. Never have seen an advantage in that. I use the UDT for the bulk of the variables needed, and name my tags for the I/O similarly to the UDT tagname. So for a motor, I might have M100_out for the output and M100_aux for the aux and then M100 UDT for all timers, command bits, permissive bits, pushbuttons from the SCADA, etc. @Michael, I would also be interested in seeing how you handle your PID in the CLX. From what I have seen, there seem to be as many ways to handle PID's as there are programmers. High amount of flexibility I guess yields a high amount of variation.

Your best bet would be to power down the network and check resistance as Ken suggested. I am not familiar with the 700 - maybe it does have a dip switch or something for termination. It will be obvious if you check resistance and see 60ohms. You also mention the drive being moved. Is it possible that it was added on to a network and the terminating resistor needs to be moved? If you read 60 ohms, it may be worth pulling the DN plug on the 700 and measuring the rest of the link again. If you still get 60 ohms, you have two terminating resistors just placed incorrectly. Check the troubleshooting section in the SDN manual for the codes, but 78 means the device in the SDN does not exist on the network, 91 (as you mentioned) is DN going bleauh. Bus off and comm comm errors. Seems to me I used to get that when I disconnected bus power. Generally if you are getting all this on drive start then you have a noise problem. If its not the terminating resistors, check and make sure your drives are properly grounded. With all this, I am assuming that you have checked both drives command reference to insure you are really communicating successfully.

If this is the information that you have, you may just want to warn the client that this is going to go a little rough. Also, whatever you have quoted probably is not enough. If they cannot provide more information, I would suggest that you offer to put together a functional specification based on the operation you determine from the existing program as you resurrect the comments. The only way I know to properly complete the project with the information you have, is to slowly figure out what the program is doing and recreate the comments. That is slow going. From that you can put together a functional specification that explains how the system works. I suspect they dont even have a full understanding of how the system really works. The HMI interfaces necessary should become more evident as you work through the descriptions. After that it may be like any new program where you have to discuss with them what interface capabilities they will need for the system.

Do you have some sort of UPS? If not, you may want to power the PLC with a UPS and take your system power to an input to let you know when you have lost power. The UPS would not have to be large, just big enough to hold everything up until you get through with the manipulations you want to complete.

You have to be careful using the on board analogs. The resolution is crappy (10 bits) which may be ok for certain things. You could probably get away with the 250 ohm resistor, but that would only use the 1-5 v range of your 0-10 analog input cutting your resolution in half... and did I mention that the resolution is crappy? In my mind, if you need 2 more analog inputs then its worth adding the extra card. You always want to leave some spare capacity anyway. Your cabinet space problem is difficult. I dont really have any good ideas on that. Also keep in mind that the 1100 can only take 4 expansion modules. So you may be backed into a corner there depending on the number of modules you have in your system.