alfman96
Member
I second the guys who have posted that you ought to start afresh with the program if you know the basic functionality of the system. From my own experience,we just took our company from micrologix 1400 to a compactlogix L24ER, and it was a lot better to just start over. For one, the original programmer didn't program things very well in the original code, so just bringing it over may not be the best idea, especially if you ever have to add functionality.
One important example I ran into that would concern me about going to compactlogix from something older, is that compactlogix and contrologix don't work the same way in terms of updating inputs and outputs as other controllers do. For example, many controllers update the inputs, cycle the code, then update the outputs. You aren't going to have any issues with input states changing during the program scan times. As the GOTC programmer from Rockwell pointed out to me when I was trying to copy over a piece of code line by line from the micrologix 1400 to the compactlogix, and it didn't work right, the compactlogix and controllogix don't operate that way. The inputs are updated regularly (all the ones that are listed as local) whether in the middle of scan or not. The logix controllers are meant to be programmed around state programming. You only leave a particular state if certain conditions have been met,so it doesn't matter if the inputs change in the middle of the scan. But if you don't know that, and you don't plan for it, you can find that your inputs change state in the middle of the scan. If you have code that executes based on the input state at different points in the scan, you can end up with some pretty strange results because the input may have gone from being at 0 volts to 24 in the middle of the scan, and you end up having half of the things happen you meant to have happen when the input was 0, and some from when it was 24 happen as it goes through the scan, with very unexpected results. You can get by that by taking in all your inputs at the begining of the scan and freezing their values into tags, operating on all of that, and then updating the outputs from other tags you changed in the scan, essentially forcing the newer controller to act like the older controllers, or you could do the aforementioned state programming, but if you don't know about thing about it, the program you try to bring over line by line won't necessarily work the way you think it will.
Also, things like PID loops, if you have them, do not come over and work exactly the same way. The faster scan times of the newer controllers might play havoc with a very poorly set up PID that happens to work in the older controller. Or even abetter set up one.
And besides, in my case, as I went through and learned the new tag based system, as opposed to file based system of the micrologix and rslogix 500 setup, I figured out there are a lot better ways to do things in RsLogix 5000 just in general than in the older system.I don't know much about plc 2, but I bet there is a lot to be said to starting at the beginning and getting things right.
One important example I ran into that would concern me about going to compactlogix from something older, is that compactlogix and contrologix don't work the same way in terms of updating inputs and outputs as other controllers do. For example, many controllers update the inputs, cycle the code, then update the outputs. You aren't going to have any issues with input states changing during the program scan times. As the GOTC programmer from Rockwell pointed out to me when I was trying to copy over a piece of code line by line from the micrologix 1400 to the compactlogix, and it didn't work right, the compactlogix and controllogix don't operate that way. The inputs are updated regularly (all the ones that are listed as local) whether in the middle of scan or not. The logix controllers are meant to be programmed around state programming. You only leave a particular state if certain conditions have been met,so it doesn't matter if the inputs change in the middle of the scan. But if you don't know that, and you don't plan for it, you can find that your inputs change state in the middle of the scan. If you have code that executes based on the input state at different points in the scan, you can end up with some pretty strange results because the input may have gone from being at 0 volts to 24 in the middle of the scan, and you end up having half of the things happen you meant to have happen when the input was 0, and some from when it was 24 happen as it goes through the scan, with very unexpected results. You can get by that by taking in all your inputs at the begining of the scan and freezing their values into tags, operating on all of that, and then updating the outputs from other tags you changed in the scan, essentially forcing the newer controller to act like the older controllers, or you could do the aforementioned state programming, but if you don't know about thing about it, the program you try to bring over line by line won't necessarily work the way you think it will.
Also, things like PID loops, if you have them, do not come over and work exactly the same way. The faster scan times of the newer controllers might play havoc with a very poorly set up PID that happens to work in the older controller. Or even abetter set up one.
And besides, in my case, as I went through and learned the new tag based system, as opposed to file based system of the micrologix and rslogix 500 setup, I figured out there are a lot better ways to do things in RsLogix 5000 just in general than in the older system.I don't know much about plc 2, but I bet there is a lot to be said to starting at the beginning and getting things right.
