PV600 to Controlgx Tag Referencing

Guys, I have an existing app that I am attempting to diagnose some issues with....and I have come across something that I have not seen before with regards to TAGS in the PV.
In the PV600 (PanelBuilder) app, the tags referenced are integers, eg N604:0...etc. In the Controlgxs app, there is NO refererence to these integer tags anywhere. No moves, copy's etc.
I can see where they are using the data, but it is a different tag than above. For example...XIC(PV600_bit_data5.1). This is in no way associated to the N604:0.
What is going on here?
BTW, this is the first time that I have been working with PV600-LGX5K platforms. I normally use the SLC-PV or LGX5K-PV+ apps.
Is there something that I am missing somewhere?
Cheers and thanks for all of the upcoming help.

In the Logic dropdown menu, there is a Map PLC/SLC messages menu item. Mapping the Clogix tags to PV tags is done there. Check out the existing mapping, and it'll probably become very clear as to what the original programmer did.

In Logix5000, under the menu structure (Communications menu I believe but I cannot remember off the top of my head right now) there is a sub menu choice called SLC/PLC Mapping. In there there is a list of files that are referenced to SLC/PLC Data types. I will look and post later an exact menu, but you can find it or someone else can post any corrections for me.

David

Thanks Guys.

Wow, is that ever a pain in the ***.
Why would Rockell do such a thing. They should be able to address directly using the Tag Name in PV as the same tag in LGx5K.
I can see if you are using 2 different manufacturer's....but they are the same!

Thanks again.

The newer HMIs (VersaViews, in my case) do use the same tag name as Logix5K, and it's a breeze to work with while programming PLC and HMI simultaneously. In fact, we don't use older versions of PV, partly due to the hassle.

Originally posted by kcarlen:

Why would Rockell do such a thing. They should be able to address directly using the Tag Name in PV as the same tag in LGx5K.

Click to expand...

Why can't I connect my Win95 computer to my Win2K server domain? They are both from the same company? The answer is that one is a legacy product and the other is based on newer technology. Microsoft decided they didn't want to drag that anchor behind their new product.

The standard PV was developed in the time of the SLC/PLC5 family of products and uses the attendent addressing and protocol structures. The standard PV also has a fixed internal communication protocol. So you get what you get for addressing. When Rockwell developed the CLX family they planned for CLX configurations to replace existing SLC/PLC5 installations. To allow the CLX to directly connect to the existing HMIs they added the address mapping function referred to above. So at least you didn't have to do anything to your HMI to switch to CLX.

Now you are in a new installation. As bone said, Rockwell DOES provide a product that seemlessly (more or less) reads and writes directly to tags in the CLX. So if you want that functionality you have a migration path. If you don't want that functionality mapping still allows use of the PV.

Why hasn't Rockwell developed CLX direct communication drivers for the PV? At some point you have to freeze development of a product and let it be what it is and put you eggs in the new product basket. The standard PV is what it is, just like the PLC5 and the PLC2 before it. At some point you just need to stop developing on a family and move forward.

Keith

OK, this may seem like a stupid question, but why can't (or couldn't) the developer of the PLC code just use the integers (N504:1) as the tag name then? Is it easier to use the mapping function?

The programmer has gone through the trouble of creating the PV600 tags in the controller tags listing.....

It's not particularly unusual for an HMI to abstract the internal tags from the communication tags. Wonderware does this also. It allows easy modification as you cross communication methods or change target processor memory structure. For example, you could move from a DH+ or serial (DF1) interface to a DeviceNet or Remote I/O interface simply by exporting the tags, doctoring the PLC tag field and importing them back into the PV application. No modification to any screens required. So the internal tag has nothing to do with communication. It has everything to do with PV development.

Granted, instead of the SLC/PLC mapping function that Rockwell included in the CLX they could have stuck in a backdoor translator that forced the PLC developer to use a strictly formatted array to communicate with the PV. You would need something like this because the tagname restrictions in the CLX family don't allow for the punctuation in SLC/PLC tags. You can't have a CLX tag like 'N504:1' becaue a colon is not allowed in a tag. So Rockwell could have said 'Anything coming in as N504 goes into a 1-dimensional array with forced tagname of 'N504'. N504:1 would appear in the PLC as N504[1]. But for every developer such as yourself who would like the force format method you would get another who would want their array to be 'PV_In_Int_N504' so they know what they are dealing with. So Rockwell is in a lose-lose situation, unless they want to modify the firmware of an aging product to talk to a new one directly.

Keith

kcarlen said:

OK, this may seem like a stupid question, but why can't (or couldn't) the developer of the PLC code just use the integers (N504:1) as the tag name then? Is it easier to use the mapping function?

The programmer has gone through the trouble of creating the PV600 tags in the controller tags listing.....

Click to expand...

Because there are generally hundreds, if not thousands, of tags in the PLC that the Panelview doesn't need to know about. A Panelview is a low end dirty window into a limited data-set of the PLC.

PLC logic, on the other hand, should be constructed (and tags named) in a logical fashion which ideally can make the PLC logic self-documenting. Why would one want to multiply the complexity of programming and testing the PLC 10 fold to make a simple display easier to program?

And, for the record, even legacy PV products can indeed directly use the Logix platform tagnames, at least if you put them on ethernet or controlnet.

The CLX tags are communicated using CIP protocol, whereas the older PLC/SLC's use PCCC protocol. The older PanelView Standard HMI's use the PCCC protocol which simply cannot directly attach to any of the native CLX tags...no matter what you name them.

In order to let the older HMI's, (and lots of legacy third party devices that use PCCC style drivers eg DF1 ) attach to the CLX processor, Rockwell provided the Map PLC/SLC messages feature. Usually this function is normally used to map (or alias) a CLX array tag as a PLC style datatable. The key point is that the mapping tool allows the processor communications to access a tag array using the PCCC protocol as well as CIP.

If the PV is writing an address such as N7:1/1 then this appears in the CLX array tag as the second bit in the second word. Now what you NAME this CLX array tag is entirely up to you. You can call it <Elephant_Butt> if you want, but in practice it makes sense to give the array the same name as the datatable the HMI is using...eg call the CLX array < N7 >. If you do this the HMI write N7:1/1 will appear in the CLX as N7[1].1 .

The other point to note is that when creating the CLX array tag N7 it is important to define the CLX type the same as datatable type in the HMI tag database. ie the HMI tag N7:1/1 is an Integer, so the CLX array N7 should also be INT.

kcarlen said:

OK, this may seem like a stupid question, but why can't (or couldn't) the developer of the PLC code just use the integers (N504:1) as the tag name then? Is it easier to use the mapping function?

The programmer has gone through the trouble of creating the PV600 tags in the controller tags listing.....

Click to expand...

First off, the mapping function is required for the Panelview to access *ANY* memory in the ControlLogix. But, it could be done better...

edit: As rdrast points out, some models can access ControlLogix tags directly. If your's doesn't the following still applies.

People solve this problem in different ways (as evidenced by the replies in this thread). Here is how I handle this situation, I think it works pretty well.

In the ControlLogix create tags to exchange data with the Panelview. I usually use one INT array for data from the Panelview and a second INT array for data to the Panelview. These tags are something like N100 and N101.

Next, you assign them to files 100 and 101 in the SLC/PLC Mapping.

Then, you create aliases for the appropriate elements in N100 and N101 for each tag in the Panelview. The aliases should be identical to the Panelview tags with a prefix like FromPV_tagname or ToPV_tagname.

You use the aliases ONLY in the ControlLogix program. Now when you see one of these tags in the ControlLogix program, they are instantly recognizable since they have the prefix and N100 or N101 address shown as the base tag i.e. <N100[1].3>.

Since the alias matches the Panelview tag, once you get past initial checkout you don't need to refer to the PLC5 style addresses any more for troubleshooting. But when you need to check one, they are right there.

Using an arbitrary and uninformative tagname like PV600_bit_data5.1 in the ControlLogix is taking an ugly situation and making it worse. But it could be worse, you could be dealing with a Panelview over RIO with block transfers. <eg>

Thanks for the information people,

I have learned enough to get me started in interpereting the code that was originally confusing the &*)** out of me.

Thanks again,