PV+1000 Program conversion to Compact logix

ian.smith7

Member
Join Date
Aug 2002
Location
UK
Posts
145
Hi All
I have a project to replace an SLC5/05 with a CompactLogix (5069-L320ER. FW v30). The original system had a PV+1000 which is incompatible with the 5069 so this is being replaced with a PV+6 (FW v9). I have NOT Created a HMI object in the 5069 IO tree.
The HMI Register numbers for the data tables have been mapped in the 5069 PLC5/SLC mapping table. I have created .mer files in various runtime versions with FTVStudio V9 and installed them ok in the HMI but the original tags in the HMI are not connecting to the CLX.

I have this set up on a test network in the workshop with the compact logix having the same IP address as the existing SLC on the Plant But I have just thought that the PV+6 has a different IP Address to the original PV+.

A new object displaying a dint register and being modified from the HMI via a new shortcut works fine, so the HMI can connect to the 5069.

But the old SLC shortcut is not working. I have tried pointing the SLC shortcut to a new Compact logix object but that did not work either.

The CLX tables are all in Dints but the HMI is set up for INT does the Mapping table take care of this?

If i cant get the old SLC HMI tags to work is the a way to Map them to new CLX Tags in the HMI without manually altering each one?

Unfortunately i am not back at work till next week so i cant try anything out but this is really bugging me.

Advice and suggestions would be greatly appreciated
Ian
 
The CLX tables are all in Dints but the HMI is set up for INT does the Mapping table take care of this?

Ian

Mapping will NOT take care of the data-type mismatch....

Your best bet is to change the CLX tags to INT arrays.
 
Hi daba, once again thanks for your reply.

This could be a long post as I have a few questions around your answer.
Could you confirm that this applies to SLC mapping well. It seems stupidly obvious the answer is going to be the same (NOT taken care of in the mapping tables) but I just had to ask to be certain. I have not had a chance to test the mapping function since you replied to my SLC question about this project.
Would this data type mismatch cause data not be displayed on the HMI screen (even though the data may not have the correct value).
Please understand the solutions I am looking for are quick and 'dirty' not the ideal long term solution which is I guess rewrite everything to the modern compactlogix standard.

Given that the PLC program came from INTs and was converted to DINTS in for the CLX.
What is the best approach in the CLX, change every thing to INTs throughout the program (slower for the CLX to process and not the right data format for future updates) or create INT buffers for the mapping table then convert to Dints for the CLX to process?

Some of the messages coming to the CLX from other SLCs contain strings. How does the Mapping table and CLX manage these as I think there is a difference in the copy methods for strings between SLC and CLX (two copies, 1st to set the string size 2nd to transfer the string data).

Thanks for your replies daba I do appreciate you giving up your time to help.

Ian
 
Hi daba, once again thanks for your reply.

This could be a long post as I have a few questions around your answer.
Could you confirm that this applies to SLC mapping well. It seems stupidly obvious the answer is going to be the same (NOT taken care of in the mapping tables) but I just had to ask to be certain. I have not had a chance to test the mapping function since you replied to my SLC question about this project.
Would this data type mismatch cause data not be displayed on the HMI screen (even though the data may not have the correct value).
Please understand the solutions I am looking for are quick and 'dirty' not the ideal long term solution which is I guess rewrite everything to the modern compactlogix standard.

Given that the PLC program came from INTs and was converted to DINTS in for the CLX.
What is the best approach in the CLX, change every thing to INTs throughout the program (slower for the CLX to process and not the right data format for future updates) or create INT buffers for the mapping table then convert to Dints for the CLX to process?

Some of the messages coming to the CLX from other SLCs contain strings. How does the Mapping table and CLX manage these as I think there is a difference in the copy methods for strings between SLC and CLX (two copies, 1st to set the string size 2nd to transfer the string data).

Thanks for your replies daba I do appreciate you giving up your time to help.

Ian

I had not even considered that mapping an incoming INT data message (and it must be INT data from an SLC) into a DINT array tag would do the necessary conversion from INT to DINT.

I genuinely don't believe it converts, but could be proved wrong. Sadly I don't have the hardware to set this up to test it, my SLC training rig is out on loan, and I only have ControlLogix here.

My other thought is that the HMI, which was originally written to communicate with the SLC, would be expecting INT data as well.

Yes, using INTs in the CLX will slow it down, but it's not a huge burden just for the mapped tags, and tags that the HMI accesses. The only reason why Logix5000 has SINT and INT data-types is purely to handle these "legacy" scenarios.

The ST (String) mapping just works, because the structures are the same.... a .LEN element, and an array of (up to) 82 ASCII characters (bytes). Now the INT .LEN from the SLC maps into the DINT .LEN in the CLX, so it appears my previous comment about conversion could be wrong.
 
Last edited:
Hi daba
Looks like i will just have to connect everything up on the plant and try it as this project is going in starting on tuesday.
I am now a little concerned about the comms, I have done things the other way round (CLX to SLC) before but never (SLC to CLX). The SLC being replaced had no MSG instructions at all in the program but is Written To and Read From by two seperate SLcs. Another CLX also reads data from as well.
Its going to be an interesting week for me.

Cheers
Ian
 
Hi daba
Looks like i will just have to connect everything up on the plant and try it as this project is going in starting on tuesday.
I am now a little concerned about the comms, I have done things the other way round (CLX to SLC) before but never (SLC to CLX). The SLC being replaced had no MSG instructions at all in the program but is Written To and Read From by two seperate SLcs. Another CLX also reads data from as well.
Its going to be an interesting week for me.

Cheers
Ian

This might be a time to consolidate Comms, and standardise on Read messages throughout.

When a PLC is Written to, and you are sitting there watching the data changing, you will have no idea where the data is coming from. But with Read messages, you can always look at the message configurations to see where the data is being read from. I think it just makes everything clearer.

When a CLX class controller Reads from (or Writes to) an SLC, there is no need for mapping, the SLC Typed Read and SLC
X Typed Write message configurations let you specify the SLC target data-tables directly.

Mapping will only be required for data-table to tagname conversion when the message is initiated from the SLC, because it has no knowledge of CLX tag-based data.
 
I agree whenever I am setting up comms I always read data rather than write it but in this case I dont think I have enough time to change everything.
Thanks for your help
Ian
 
The HMI Register numbers for the data tables have been mapped in the 5069 PLC5/SLC mapping table. I have created .mer files in various runtime versions with FTVStudio V9 and installed them ok in the HMI but the original tags in the HMI are not connecting to the CLX.

Although you CAN try to use the mapped tables, it's much, much better to avoid them.
Change all of your HMI tag addresses over to native CLX addresses.
That also lets you use the CLX comms driver in RSLinx Enterprise.

A high level set of steps:
(1) Create a new shortcut to the CLX, create 1 new HMI tag and browse to one of the imported SLC DINT tags. Test that it works on a display.
(2) Using HMI tags? Export them all to CSV and edit in Excel.
(3) Use the example address from (1) to edit all of your tag addresses into the new CLX format.



The PV+1000 is not compatible with a 5069 Compact? Seriously?
I didn't believe it either, but there it is on their website
Maybe that is wrong, or there are some other tricks.

https://compatibility.rockwellautomation.com/Pages/MultiProductCompareSelections.aspx?crumb=113&toggleState=&versions=56484,55828
 
Although you CAN try to use the mapped tables, it's much, much better to avoid them.
Change all of your HMI tag addresses over to native CLX addresses.
That also lets you use the CLX comms driver in RSLinx Enterprise.

A high level set of steps:
(1) Create a new shortcut to the CLX, create 1 new HMI tag and browse to one of the imported SLC DINT tags. Test that it works on a display.
(2) Using HMI tags? Export them all to CSV and edit in Excel.
(3) Use the example address from (1) to edit all of your tag addresses into the new CLX format.




I didn't believe it either, but there it is on their website
Maybe that is wrong, or there are some other tricks.

https://compatibility.rockwellautomation.com/Pages/MultiProductCompareSelections.aspx?crumb=113&toggleState=&versions=56484,55828

So, it doesn't work before v.. 8.2 of the panelview firmware iirc. So you need a Pvp6 w/ 8.2 or higher.
(And I believe v9 is required for FW 30 and up.)
 
I started composing this earlier and got waylaid, as usual, so forgive me as I cannot keep editing this to death just to cover certain other points made in the meantime.

I will just add this though...

The cut-off point for compatibility between the older PanelView Plus terminals and newer Logix 5000 controllers is tied to the latest OS version on the terminals not being fully compatible with controller firmware revisions above 24. Once you flash a PanelView Plus to 5.10.16, revision 24 is the highest "supported" controller firmware they will apparently work with. Whether that means that they will not work, at all, or it's more a case of suck it and see, I do not know as I've never tried?

Ian,

If I may first attempt to assist you on the communications side of things here...

Compatibility...

Just to provide some clarification on what versions of software and revisions of firmware are, or are not compatible here between old and new PanelView Plus terminals and either 5370 or 5380 CompactLogix controllers...

473017 - CompactLogix 5370 & 5380 Controller compatibility with PanelView Plus
Access Level: Everyone

You have:

5069-L320ER FW: 30
PanelView Plus 6 FW: 9

PanelView Plus 6 or 7 must be at firmware revision 9, minimum, to be compatible with a 5370 or 5380 controllers at firmware revision 30. So that confirms that they are compatible for communications here. However, you have stated that you have tried different versions of compiled MER runtime using FactoryTalk View Studio v9. From the above "minimum" compatible firmware revision 9, required for the PanelView Plus 6 or 7 to work with a firmware revision 30 controller, I would take that to mean that the MER runtime application version that must be used here is 9, minimum. I would not advise continuing to attempt 8 or 7, etc., as these, I believe, would not be compatible here.

Also, for further clarification, see the last two paragraphs in this technote - It states that you must have 8.20 minimum application and firmware in the terminal to communicate with the 5580 or 5380 controllers. But, if using a firmware revision 30 controller, then you must use 9, minimum, in the terminal...

769046 - FactoryTalk View ME: Unsupported device detected when creating runtime file
Access Level: TechConnect

Shortcuts...

You have stated that you have gotten a new Shortcut to successfully communicate with the controller as a test to a DINT data type. Out of curiosity, what configuration did you use for that Shortcut, and using which version of MER runtime?

You have stated that the original SLC Shortcut is not communicating since the MER application was converted to a newer version - let's say 9, as this is what I believe you should be using. The older SLC Shortcut would, of course, have been configured to communicate with an SLC 5/05 device, selected from the "Ethernet SLC devices" list on the Runtime (Target) tab. You have stated that you attempted to edit this Shortcut device to "a new Compact logix object" and that it did not work. Have you been using "Apply" and "Verify" after the changes you are making in the Communications Setup to update the Shortcut and verify the changes have taken effect? Also, it is often the case that an imported, upconverted, or simply edited Shortcut in RSLinx Enterprise will become corrupted.

Either way, I would advise you to delete the old SLC shortcut, taking note of its exact name, and recreate a new Shortcut of the exact same name, configuring it for a 5069-L320ER r30 controller device under the Ethernet driver on the Runtime tab, which FactoryTalk View Studio v9 does support.

Whether it works right away or not, these are the basic steps I would take to be in a better position to move forward -

1. Use a version 9 MER runtime file.
2. Delete and recreate the Shortcut with the same name and pointing to the correct type controller and firmware revision.

Your physical interfacing between the two devices is most likely OK as you have successfully established communications using the new Shortcut.

Once that is all OK, let's have a look at the uncertainties regarding the data type you have mapped to in the CompactLogix controller?

I would, before proceeding, best advise you to consider converting the HMI Device or Direct reference tags in the application to Logix 5000 addressing. This would make things a lot cleaner and simpler now and in the future. However, you sound like you cannot or do not want to go that route at the moment or are pressed for time here?

Moving on in that case...

If the HMI tags were originally created as Integer data type (most likely if communicating with a 16-bit SLC processor), and the CompactLogix tags used in the PLC/SLC Mapping have been created as DINT data type then the following should be the case...

Since the PanelView Plus is 16-bit based and the CompactLogix is 32-bit, the PanelView cannot read or write the upper 16 bits of the DINT data type tags (16-31). What it does do is only read or write its 16 bits to the lower 16 bits of the DINT data type (0-15).

What does this mean for the actual 16-bit data value that has been exchanged? The 16-bit Integer in the PanelView is treated as an Unsigned Integer in the lower 16 bits of the 32-bit DINT. So that gives the possible value range of 0 to 65535.

Example:

HMI Device Tag:
MyINT = Integer: N7:0

Logix 5000 Mapping:
File number: 7
Tag: m7_DINT (map file 7 to DINT)

Logix 5000 Tag Data Type:
m7_DINT = DINT[5] (DINT Array)

Exchange:
MyINT (N7:0) writes to DINT[0]

Result:
16 bits from HMI Device Tag MyINT writes to bits 0-15 in DINT[0]
Data is valid

If you require a Signed Integer data type in the HMI then you must map to INT data type in the Logix 5000 controller to exchange valid data.

Bool addressing in the 16-bit based terminal will similarly interact with only the lower 16 bits of a mapped DINT.

However, if you are using the Alarm Trigger Type for an Alarm Banner, which utilizes a Bit Array in the controller, then this special feature will interact with all 32 bits in a DINT tag, or Array of tags. Let's say we want to trigger up to 96 Alarms. By assigning a Direct Reference tag to the starting Trigger Bit in the controller, let's say DINT[0] of a DINT[10] Array (Up to 320 Alarms), you can assign a Length in 16-bit words for the depth of the Alarm Bit Array to read from the controller.

Say we set a Length of 6 - that is 6 x 16 bits (96) deep into the DINT Array, contiguously.
Or, that is 3 x 32-bit DINTs, or DINT[0] - DINT[2] that will be utilized here...

DINT[0].0 = Alarm Trigger 1 for the Alarm Banner
DINT[0].1 = Alarm Trigger 2
...
DINT[0].31 = Alarm Trigger 32
...
DINT[1].0 = Alarm Trigger 33
...
DINT[1].31 = Alarm Trigger 64
...
DINT[2].0 = Alarm Trigger 65
...
DINT[2].31 = Alarm Trigger 96

I'll leave it there.

Basically, this can work, but I have not considered all data types that your HMI application may have been interacting with in the SLC. Some are compatible, some are not, or at least not directly.

Again, converting the tags, at least at some point in the future, should be worth serious consideration in these cases.

I need to go home now. I have to work tomorrow and Sunday installing a new Auto Labeller machine and I have some C code, XML, VB, and serial SLC interfacing to sort out. Printing the labels is the easy part! It's all the interfacing that provides the "fun".

Regards,
George
 
Last edited:
I am not at work at the moment so these my replies are all based on memory as I cant check my programs etc.

PV+1000--- after i failed to get it talking in any way to the 5069 PLC i checked the Device compatibility page and it was greyed out - meaning it might or might not work. Then I found a technote saying it was not compatible above CLX FW v24 and the 5069 only goes down to v28 firmware. I rang Rockwell UK and they could not tell me either and 'escalated' it to Rockwell USA.

PVP6----- I patched the firmware up to v9xxxx. But I found that compiling the run time in a .mer at v9xxxx created a runtime error (version incompatibility?). A .mer at v8.1(or2?) worked Ok. I did try v5 and even v3.2 without success.

George thank you for comprehensive reply which is going to take me some time to digest. It looks like I will have to rewrite all the HMI tags after all

ian
 
GeoSpark wrote
You have stated that you have gotten a new Shortcut to successfully communicate with the controller as a test to a DINT data type. Out of curiosity, what configuration did you use for that Shortcut, and using which version of MER runtime?

from memory i am sure my test program was compiled at v8.2 and the new test shortcut (called 'CLX') was configured as a Compact logix? device (I think 5069-L320 was chosen from a list).

Yes i did alter the old SLC shortcut (actually called 'SLC') then verify and confirm, I am sure my next try was to delete the SLC shortcut and replace it with another SLC shortcut pointed at the 5069. Neither of these attempts succeeded in getting the SLC tags in the HMI to work.

There is only one Process value i can think of that needs a sign (Vacuum air pressure) but that is not a problem as i dont think the operators will even notice the missing '-'. But there are some encoder values which at times during the set up of target positions may cause an issue to the engineers.

The alarms are something I have not looked at yet.

The mapping explanation you have given looks exactly the same as what is set up in the processor. So the lack of data is probably down to a communications failure.

once again thanks to everyone for taking the time to reply.
ian
 
Last edited:
ian, I managed to run a test on the CLX mapping, albeit not using an SLC to write data to the CLX, but another CLX in my chassis.

Here's the set-up....

Receiving CLX has mapping to receive the incoming message write from the pseudo-SLC - File 8 to SLC_Data (INT[30])

Transmitting CLX has a cyclic MSG, "SLC Typed Write" to send an INT[30] array (also called SLC_Data), to the CLX, destination N8:0

The mapping should see the file number 8, and map the incoming data into the tag SLC_Data.

Well that all worked fine, as I expected, all 30 INTs were messaged across from the pseudo-SLC to the CLX.

Then I changed the receiving CLX SLC_Data tag to DINT[30], and lo and behold, I got a MSG Error on the pseudo-SLC.

The error was 16#011 "Datatype requested does not match data available".

Now I'm thinking that the receiving mapping is rejecting the data, because it is not the correct data-type for the mapped tag, so no conversion is attempted.

Of course, my set-up, CLX to CLX, may have more error-checking built-in, as they are the same class machine, but I believe the receiving CLX can have no knowledge of the class of the transmitting CLX, it is just receiving a properly structured SLC type message. Nor can the transmitting CLX have any knowledge of the receiving CLX, it is just transmitting a properly structured SLC type message.

Looking into the Message Configuration Help, it does specifically say to use INT tags in the CLX to receive N data from the SLC.

Hopefully I can get my SLC rig back in a few days, and try this for real, on real hardware.
 
Thanks for that test daba.
Now i know for certain that i have few things to change.
I think it will be quicker for me to change all the DINTs to INTs just leaving some of the new IO tree to buffer DINT - INT.
Back to work tomorrow.
Cheers
Ian
 

Similar Topics

I have a mer or apa file for Pv1000 (2711p-rdt10c) and i need convert this files for Pv5000 (2715P-T15CD-K). Are exist a conversion tool for this...
Replies
1
Views
856
Hi, im looking to migrate a 2711-K10C10 to a 2711P-T12W21 Panelview Plus 7 Standard. I migrate the PV1000 application .pba file in FactoryTalk...
Replies
13
Views
1,932
Hi there everyone! Long time lurker, first time poster. I am doing an SLC-5/03 to CompactLogix migration and am having an issue with a barcode...
Replies
1
Views
1,037
Hi, I'm investigating the feasibility of communication between a old PV standard display and a logix L5X controller via the controller serial...
Replies
3
Views
1,435
Hi all, Anyone manage to get this smorgasbord of hardware to cooperate with each other? PLC - Micrologix 1500 1764-28BXBAA CH1 config - DF1 Full...
Replies
2
Views
1,469
Back
Top Bottom