PLC5 Registers to ControlLogix

dadara

Member
Join Date
Aug 2008
Location
Regina
Posts
9
Hi, I am wondering is it possible to convert or create PLC5 registers in ControlLogix. The reason for this is that I have third party program that is already reading my PLC5 "N" addresses, and I would like to create the same ones in my ControlLogix program once I recreate it. This would save lot of time since I wouldn't have to change third party software to read new tags in ControlLogix. Thanks.

 
dadara said:
Hi, I am wondering is it possible to convert or create PLC5 registers in ControlLogix. The reason for this is that I have third party program that is already reading my PLC5 "N" addresses, and I would like to create the same ones in my ControlLogix program once I recreate it. This would save lot of time since I wouldn't have to change third party software to read new tags in ControlLogix. Thanks.


use the SLC/PLC5 mapping any message received looking for a file # is mapped to the Clgx tagname

create a INT array called N7


mapping_1.jpg


map file #7 to this INT


mapping_2.jpg
 
Last edited:
I'm not sure will it work because I'm taking old PLC5 processor out and converting all program to L63. I will keep the same I.P. address. So if it is possible to create N7 array and store numbers in it at the same addressees as in PLC5 you think it should work?

 
I'm not 100% sure, but I think the mapping will only work with PLC5/SLC500 message read and writes. You mention a "third party application" reading from your PLC5, this mapping may not work with that. Options would seem to be first give it a try with the mapping table (it may work), second message the "N" data to another PLC and third change the tags in your third party program.

Tim.
 
Almost certainly it is not going to work 'out of the box' with your 3rd party app as the comm protocols are entirely different between PLC5 and CLX (doesn't matter that they are both ethernet). More than likely, your 3rd party software is using a driver of some sort, specifically written to communicate to a PLC5. Pointing it to a CLX, regardless of whether you have an N7 tag in it, is probably not going to work.

Give us some more information about this 3rd party application and its communication means.
 
Omport/Export

If you are going to use the import/export utility in the Logix5000 software, it will automatically create the necessary arrays to take the place of your existing data files and size them according to what they were in the PLC-5 and retain their last saved values before export out of RSLogix5.
 
Craig Spinharney said:
If you are going to use the import/export utility in the Logix5000 software, it will automatically create the necessary arrays to take the place of your existing data files and size them according to what they were in the PLC-5 and retain their last saved values before export out of RSLogix5.

And generate a nearly unmaintainable mess of uncommented code.

Just do a manual rung-by-rung translation. Less heartache in the long run (usually faster too)
 
Works for me

I've never had a large problem even with a 3,500 rung conversion I recently helped a customer with. With the generated log, we were able to bang out the errors in 1/4 of the time had he manually done it.
 
Craig Spinharney said:
I've never had a large problem even with a 3,500 rung conversion I recently helped a customer with. With the generated log, we were able to bang out the errors in 1/4 of the time had he manually done it.

That's fine, but I will not accept an auto-converted program.

Tagnames are inefficient, data structures are "legacy", and not thought out to the task, errors in the original program are propagated to the new one (and don't even try to tell me there are no errors, there most certainly are).

IMHO though, the worst problem with conversions, is forcing the legacy "Data-Table-Centric" design to continue.

The entire paradigm of "Logic" programming is changing with the ability to split things into multiple tasks, with more speed and capability then was ever possible just a decade ago.

If you trade in a Yugo, for a Ferrari, you don't use your old tires.

My opinion only, and your mileage may vary.
 
I second rdrast.

That conversion program spits out a horrible product that does not leverage any of the best features of CLX systems.

If I were an end user(I am not anymore) I would not let you back in my plant if you gave me a CLX full of "Legacy" style arrays. As a programmer for hire I would be embarrassed to deliver something that looked like that too.

It is just my opinion, and everyone has one.

RSL
 
I read all your negative comments about "conversion" and have to add mine.

Conversion does as it saye :- "convert" the code to make it work. With the various tools around, it's cheap, and yes it's "nasty", because (as you've said) it doesn't reap the benefits of the CLX platform.

Now if you want to do that, you have to "re-engineer" the whole program, and that ain't cheap, not by a long mile.

Please don't put "conversion" in the bin - in the right situation, where funds are limited, it is the only path possible.
 
daba said:
I read all your negative comments about "conversion" and have to add mine.

Conversion does as it saye :- "convert" the code to make it work. With the various tools around, it's cheap, and yes it's "nasty", because (as you've said) it doesn't reap the benefits of the CLX platform.

Now if you want to do that, you have to "re-engineer" the whole program, and that ain't cheap, not by a long mile.

Please don't put "conversion" in the bin - in the right situation, where funds are limited, it is the only path possible.


Well, I firstly (and I've done many such platform switches from SLC/PLC/Modicon/Others to Logix) don't usually have to "Re-Engineer". The basic engineering is done. I do design new data structures, and try to give everything a sensible name.

I also do break programs down into logical units, and create tasks and/or routines to fit those units.

I do that, because, well, guess who usually has to start up one of these projects? ME. Using any "Conversion" utility is much cheaper on the front end, but MUCH LONGER on the startup end, and hell on the Maintenance end.

If you want to go cheap, well, stick with your existing platforms to begin with; If what you have works, there is no need to really upgrade it to a completely different platform.

If you are an OEM, and you are "Auto-Converting" from platform or brand X, to platform or brand Y, you are doing both yourself, your startup engineers, and your end users a disservice.

If you require a platform change, to add in extra capabilities, then basing such a change on platforms which did not provide those capabilites in the first place is just silly.

------------------------

This is a debate that can go on forever, and I'm not inclined to continue it, though I'm sure others will.

Be well
 

Similar Topics

I am using the following formula and I am getting error, Invalid Expression - too many closing parenthesis. when i copy the formula to notepad or...
Replies
4
Views
151
Preface: Kinda long, so I made section titles Intro: I just want to see if anyone here has seen anything similar. A PLC5-40 series C enhanced...
Replies
3
Views
365
Hi, can anyone help me get a pdf file for this RSP files. They are from a PLC5. Thanks
Replies
5
Views
515
Hello all, I am seeing this behaviour where an integer file (N46:33), has an integer in binary (11110) which is 30 in decimal. I did a...
Replies
7
Views
514
Back
Top Bottom