K_Lich10hr

Block Transfer Read/Write & Messages, PLC5 to ControlLogix Conversion

11 posts in this topic

Hello, I am currently converting a project from PLC5 to ControlLogix. I have migrated the program from Logix5 to Logix5000 and any Block Transfer Read, Block Transfer Write, or Message instructions were converted to a MSG in Logix5000. We are using the  AB PLC5 to ControlLogix 1756 Conversion Kit. All old racks and cards will be upgraded to ControlLogix racks and cards.

I have a few questions:

1. In the old system there was only 1 rack with a PLC5, the other 4 simply had I/O and communicated that back to the PLC5 over DH. These BTR and BTW instructions were only used for the analog data somehow, correct? If yes, can you elaborate on this a bit please.

2. As I said earlier, there were also message instructions. My understanding is that message instructions are only needed when communicating between multiple PLCs. So if there was only one PLC5, why were message instructions being used?

3. The upgraded system will only have 1 rack with a PLC (1756-L73) and will be communicating with the other 4 racks over ethernet. Since ethernet is being used, are these message instructions (BTR, BTW & message from the old program) even necessary anymore? Do they need to be replaced with a MOV or COP instruction?

If more information is needed please let me know. I'm new to the industry and this is the first project I was put on so I'm definitely a noob here.

Share this post


Link to post
Share on other sites

The PLC5 uses block transfer instructions to read/write and configure analog modules (among other things). You won't need them or the MSG instructions. The I/O will be read/written directly through the I/O tree via Ethernet.

I've never used the migration tool, but I've heard horror stories about it and the code it gives you. I did a migration not too long ago that had a PLC5 in its home chassis along with 6 other racks of I/O modules communicating back over an RIO network, along with 2 HMIs using DH+ to talk to the PLC over its other channel. There was a second PLC (a CompactLogix) with a Flex I/O chassis and HMI that handled an inline gauge. It was an old system with a lot of obsolete code, so I ended up doing the transcription manually, which went pretty smoothly but took a few days. We ended up with a single ControlLogix -L71 in the home chassis with 3 remote ControlLogix racks, 3 Flex I/O racks, 4 drives, and 4 HMIs, all on Ethernet. Transcribing the code ended up being very straightforward and gave me the chance to re-organize it some to make it easier to follow.

I would not want this to be one of my first projects, though. The discrete I/O is no big deal, but you have to be able to interpret the block transfers and I/O configuration of the PLC5 to figure out which addresses in the PLC5 program correspond to the analog signals so you can substitute in the right tags in the new system.

1 person likes this

Share this post


Link to post
Share on other sites

I am absolutely not a fan of the migration tool. Logix is such an outstanding platform and migration just squanders the flexibility of the platform away. You end up with all kinds of "useless trash" in what could otherwise be a clean and easy to troubleshoot program. 

I work in oil and gas so we have it a little simpler than other industries. DI, SO, AI, AO and some communication (Modbus) every now and then. I've used Message blocks to transfer bits from PLC to PLC of over the WAN (think 100's of square miles or more not building). With that said, I'd rather develop the program based on the needs of the process. That way I know what's "in the box". I start with an IO list, followed by a transmitter list, then alarm and shutdown list, then the cause and effect (all in one Excel sheet). Again, what we do in the industry that I work in is not hard (if you know the process).

Quote

I would not want this to be one of my first projects, though.

 DITTO!

1 person likes this

Share this post


Link to post
Share on other sites
33 minutes ago, Joe E. said:

I would not want this to be one of my first projects, though. The discrete I/O is no big deal, but you have to be able to interpret the block transfers and I/O configuration of the PLC5 to figure out which addresses in the PLC5 program correspond to the analog signals so you can substitute in the right tags in the new system.

Yeah this has been my problem. So am I correct in thinking that I can't just simply delete them and move on? They should be replaced with a MOV or a COP instruction? Because it seems to me that the BTR and BTW are taking data from one tag and storing it to another, so I would need to do a MOV or a COP from the source tag to the destination tag. 

33 minutes ago, Joe E. said:

I've never used the migration tool, but I've heard horror stories about it and the code it gives you.

It's not very pretty, thats for sure.

33 minutes ago, Joe E. said:

Transcribing the code ended up being very straightforward and gave me the chance to re-organize it some to make it easier to follow.

This would have been a good idea, but at the same time I'm not experienced enough to really know how to make it easier to follow and I would run into these BTR, BTW, and MSG instructions and still not know how to handle them. Not to mention, even the guys I work with were laughing about how disorganized this program is. It's definitely been a tough first assignment. Good thing shutdown isn't until Christmas.

Edited by K_Lich10hr

Share this post


Link to post
Share on other sites

At least you have some time to figure it out.

The Logix 5000 platform handles analog signals in a much cleaner way than previous systems. If you're using all 1756-xxxx I/O, you're good. Double-click on the analog module in the I/O tree of the project to open its properties dialog box and go to the "Configuration" tab. There you can set up each channel for whether it's voltage or current and the high/low signal and engineering ranges. As an example, we have a system where +/10V corresponds to +/-0.010". We would set the "signal" fields to 10V and -10V and the engineering units fields to 0.010 and -0.010.

Then, in the tag database, find the analog module and look for something like "Local:5:I.Ch2Data" (example from the project I have open that has an analog input module in slot 5 of the local chassis). The value of that tag will be the scaled-to-engineering-units signal from the analog input. No need to use a COP or MOV at all, unless you want to buffer it or use internal tags to make re-wiring I/O easier.

Are there any MSG instructions in the original PLC5 project?

Edited by Joe E.
2 people like this

Share this post


Link to post
Share on other sites
1 hour ago, Joe E. said:

Are there any MSG instructions in the original PLC5 project?

Joe, yes there is. 11 of them to be exact. I attached a picture of one of them if it'll help.

Thank you for the info on the analog signals as well. I figured it would be something like that.

MSG_PLC5.PNG

Edited by K_Lich10hr

Share this post


Link to post
Share on other sites

Update: I was initially wrong in my thinking that everything was communicating over data highway. Turns the old system communicates to the HMIs, barcode readers, etc. over DeviceNet. Because of this and the fact that all DeviceNet communication is being replaced by Ethernet, I believe I can delete all the associated BTR and BTW instructions and simply read those tags over Ethernet. 

Thanks Joe and Michael for all of your help.

Share this post


Link to post
Share on other sites

Do you know what devices are on the other ends of the MSG instructions?

Share this post


Link to post
Share on other sites

Not at the moment. I'm currently looking into it. If it's another PLC then it should be as simple as sticking the appropriate PLC into the Path of the MSG instruction, and picking the appropriate Source Element and Destination Element, correct?

Share this post


Link to post
Share on other sites

I would think so. Your destination element will likely end up being identical to what's in the existing MSG while the source address would be your new tag name.

Share this post


Link to post
Share on other sites

The conversion tool has always been a "ball park" tool. Typically, a programmer has to determine the difference in time that it would take to rewrite the code from scratch vs. using the tools and then mopping up dozens...hundreds..perhaps thousands of PCE errors and dealing with the new "aliased I/O" and incomplete (due to controller differences) MSG, BTR/BTW, ans unsupported instructions ie., . the PLC-5/SLC500 have an SCL instruction that is not part of the native Logix5000 language set.
 

And has been previously mentioned, the conversion tool lacks the ability to leverage improved methods of doing things in the Logix5000 platform.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now