How to Change PID Instruction from SLC to ML1200

[bigbadtimemachine]

Did you try PLC-5/SLC Interactive Migration Tool work to speed up your problem? Never used it on a 5/02 but it's nice on a PLC5-20 change over!

 

[Paulusgnome]

I am the electrical engineer who has been working with the OP on this problem.
I would like to offer all who have helped with this a HUGE thanks.
I believe that the original SLC5/20 was killed by a power spike that accompanied a power outage. We found that we could not get the old PLC to respond to anything, despite the earnest attentions of 3 fairly experienced engineers. It was decided to cut the losses and replace the whole (25year-old) plc and IO with new hardware. Cost worked out very reasonable by comparison with continuing to flog a dead horse.
We had been told that the PLC code should port reasonable easily, but as you have seen, it wasn't so. It was old, undocumented code written by a 'programmer' and it has nearly driven your OP right round the bend.
If any of you who helped are ever in New Zealand, we owe you several beers. Thanks very much for the help.

Mark aka Paulusgnome.

 

[dskplc]

I AM ALMOST THERE!

Since I assume the B24 was a placeholder for S24, what do I replace this with (if any)? Thank you for helping this come together since you are my lifeline.

 

[jstolaruk]

Welcome to the forum paulusgnome.
Glad to hear it's resolved.

 

[Ron Beaufort]

Since I assume the B24 was a placeholder for S24, what do I replace this with

don't replace it with anything - try that piece of the puzzle out just the way that I wrote it ... there's a better than 50-50 chance that it will work OK ...

what you SHOULD have said:

I assume the B24:0 was a placeholder for S:24, what do I replace this with

be very careful with your punctuation in these addresses ... they all tend to "run together" - especially when you're tired and in a hurry ... these types of errors can tie you up for days ...

I'll write more in a while to explain the B24:0 aspect - but try it out the way that I wrote it ...

note that if you want more detailed help then you need to follow the directions that I gave earlier ... basically, download the code - try it out - note any verification errors - note any faults - upload the code ... then post what you've seen ... we can't help you DEBUG the code unless we can see the BUGS ...

IMPORTANT QUESTION: does anyone there know (or at least have a pretty good idea) how to "tune" a PID control loop? ... once you get everything else running along - that's going to be a butt-kicker step ... as I said earlier, the old tuning numbers won't work - and they probably won't even be close to what you'll need with the new system ...

 

[Ron Beaufort]

oops! ...

I'm going to have to refigure that S:24 vs. B24:0 piece of the puzzle ...

that's not going to be as easy as I had hoped ...

here's the tricky part ...

the older SLC_5/02 used INDEXED addressing - based on the # sign and using S:24 to give an "offset" to an address ...

but ...

the newer MLX-1200 doesn't support INDEXED addressing ... the closest thing that it has is INDIRECT addressing - based on [square brackets] and using a randomly chosen address (like B24:0) as a "pointer" to an address ...

I'll try to work out an easy solution - but this is not likely to be just a plug-and-play situation ...

 

[Ron Beaufort]

I'm still working on a fix for this INDEXED vs. INDIRECT issue ...

in the meantime, here is an example taken from the SLC-5/02 program that you posted showing how the original INDEXED addressing scheme was working ...

basic idea: if the address is marked by a # sign, then you can't just read the VALUES shown on the ladder screen ... you have to apply the "offset" contained in S:24 to the "given" address - and then use the value stored at that new "offset" location ... (in simplest terms: the # sign means "start here" - but then go one - two - three - four - hops over --- and get the value from there) ...

.

 

[Ron Beaufort]

I hate to be the one to tell you this - but you're probably (99% sure) that you're going to have to do a MAJOR rewrite of your program code ...

the MicroLogix 1200 system that you're trying to use does NOT support the same INDEXED addressing that the older SLC-5/02 supported ...

I'd suggest that you print out the program code - at least the pages that make use of the S:24 (or now B24:0) addresses - and then figure out (yuk!) how the original programmer was making use of that "start-here-but-hop-X-number-of-spaces-over" approach to make the machinery work ... the figure I posted above should help you understand that piece of the puzzle ...

the good news is - that WHATEVER he was doing with INDEXED addressing CAN be done without it ... it's just (probably) going to take more rungs and more programming code to make the magic happen ...

JUST TO GET YOU GOING ... (and I know that you do not want to hear this) ... but you might consider replacing the defective SLC-5/02 processor - or whatever else got fried - and getting your plant back into operation again ... then work through this conversion as a "back burner" sort of project ... if an SLC-5/02 is not available, then an SLC-5/03, SLC-5/04, or SLC-5/05 would probably work just fine ...

sorry about the INDEXED vs. INDIRECT problem ... I've been doing this sort of work for about 25 years - and this is the FIRST time that I've run into this particular "conversion" problem ... as far as I know (I'd love to be proven wrong) there is no quick-and-easy "workaround" to make your new-improved processor do what the old-tried-and-true processor used to do ...

maybe another forum member has something - but a pretty serious search of the AB Knowledgebase came up with nothing useful ...

 

[Ron Beaufort]

something else just popped into my mind ...

I'm working on other projects of my own – so I don't have time to dig all the way through this ...

but ...

in many (most?) cases where INDIRECT addressing is used, it's done for the purpose of having multiple "recipes" of stored values which can be moved – on command - into the "working area" of your processor's program ...

think: let's make some product A ... now let's shift over to making product B for a while ... etc. ...

IF (big IF) that's what your original program was set up to do – then MAYBE you could just figure out what particular recipe that you really need to use RIGHT NOW – and then manually store those specific values in the appropriate locations – and try to get your plant back in operation ...

 

[Paulusgnome]

Hi All, and especially Ron B who has taken such an interest in this.

I am pleased to advise that the problem has now been resolved to the point where it has had the urgency taken out of it.

When we first looked at this, it seemed that the best way to resolve the problem was to replace the PLC system with a micrologix. We had been told that the transition between SLC500 and micrologix would be seamless - 'the instruction sets are practically the same' we were told by our AB expert. Not so, the indexed addressing in a recipe-based system introduced problems that could only be resolved with time that we didn't really have.
At the same time, the hardware fault that had doomed the original SLC5/02 turned out to be a software/comms problem. While finding this out, the old Panelview 300 HMI quietly expired in a definitely terminal way on the workbench, victim to the same power spike that scrambled the SLC processor. Cue the sourcing of a new Panelview Plus 6-400, and the transfer/rewrite of the hmi code for the new panel.
New HMI written, assured by AB that the DH-485 protocol that the SLC uses was supported by the new panel, I attempted to establish comms between the SLC and the PV6+ using a 1761-NET-AIC. Not, it emerged, a trivial task, even with the help of an expert with 30+ years of AB PLC experience. After much messing around, we finally got comms established.
It was then seen that about 1/2 of the variables displayed on the hmi panel would not display, appearing only as a row of asterisks. After quite a lot more experimentation, it appears that data items on the same hmi screen need to be in the same DH-485 packet or they will not display.
The get-out-of-jail card was supplied in the form of a loan of a SLC5/05 which supports ethernet comms. 10 minutes after arriving on site with this, I had the system working correctly. The HMI not only worked OK, but much faster than the old DH485-based system.
I have made the customer well aware that this return to operational status is strictly temporary. They will commit to a full ground-up redesign which will include a complete new hardware set and full redesign of the PLC code to more current standards.
All said, a very challenging wee project, and one which has taught a few important lessons. I never want to have to mess with old legacy serial-comms again.

 

[Ron Beaufort]

thank you for the update ...

just for completeness, I have developed a workaround which I "think" will be helpful for anyone in the future who might be forced to deal with the INDEXED vs. INDIRECT addressing dilemma ... I'm tied up this week – but as soon as I get a chance, I'll do some final testing – and then post a follow-up ...

again – thank you for letting us know how this turned out ...