Converting Panelview Tags from SLC to PLC

notredamon

Member
Join Date
Feb 2015
Location
baltimore
Posts
9
Currently I have a panelview talking to a SLC processor but I am upgrading it to a compactlogix.

Unfortunately there was never a tag database setup so I can't easily export and do everything in excel.

By doing a ctrl+F and searching {::[PLC] I come up with around 1000 tags.

I can do find/replace for many of them but there are many that I can't.

ie {::[PLC]N24:0/1} I find "{::[PLC]N24:0/" and replace with "{::[New_PLC]N24[0]." but for {::[PLC]N24:50} it's a little more tricky.

I've tried to use the "Map PLC/SLC Messages" function but I don't know if I'm doing it correctly. In the above case I have File Number: 24 and Name: N24 where N24[0] is an array of DINTs.

In FactoryTalk when I try to reference {::[New_PLC]N24:50} it won't read the value.

Is there any easier way that I might be missing?
 
Currently I have a panelview talking to a SLC processor but I am upgrading it to a compactlogix.

I'm assuming by 'panelview' you mean some flavor of 'panelview plus', given your mention of FactoryTalk etc. If you were actually using a non-plus panelview, then "Map PLC/SLC Messages" would be what you want.

I've tried to use the "Map PLC/SLC Messages" function but I don't know if I'm doing it correctly. In the above case I have File Number: 24 and Name: N24 where N24[0] is an array of DINTs.

The "Map PLC/SLC Messages" feature is intended for connecting from legacy devices; I'm not sure how a Panelview Plus that can already natively interact with 5000-style tags will interface with it. It may work fine, but I wouldn't be surprised if it's not an option in this scenario.

If you can get it to work, it is indeed likely the simplest solution.

In FactoryTalk when I try to reference {::[New_PLC]N24:50} it won't read the value.

Just to make sure, you get a complete failure to read a tag (i.e. error message or indicator showing ???? or the like)?
 
Last edited:
I'm assuming by 'panelview' you mean some flavor of 'panelview plus', given your mention of FactoryTalk etc. If you were actually using a non-plus panelview, then "Map PLC/SLC Messages" would be what you want.

Correct - it's a panelview plus. Maybe that's the issue.


Just to make sure, you get a complete failure to read a tag (i.e. error message or indicator showing ???? or the like)?

Correct - it just shows up as "****" and in the diagnostic display it says "Item '[New_PLC]N26:50' is unresolved in the processor on route ControlLogix in slot 0 of the chassis"
 
Correct - it's a panelview plus. Maybe that's the issue.
If you were actually using an original panelview, then you'd be on the right track with the mapping.

Correct - it just shows up as "****" and in the diagnostic display it says "Item '[New_PLC]N26:50' is unresolved in the processor on route ControlLogix in slot 0 of the chassis"

Assuming your addressing is accurate (which it appears to be from your earlier description) and your arrays are big enough, it sounds like you have things set up correctly in regards to the mapping. This leads me to suspect the (newer) panelview pluses ignore the (legacy) mapping and just go straight to the tag database, which is inconvenient in this one situation.

but for {::[PLC]N24:50} it's a little more tricky.
Can you not replace it with {::[New_PLC]N24[50]}? Or is the issue that N24 is now a DINT array where it was an INT file before (so N24:50 is now half of N24[25])? It's been almost a decade since the one time I did such a conversion, so I don't recall the specifics of how the data files were converted.
 
First, take a step back and redefine that emulated data table as an array tag of data type INT (16-bit), not DINT (32-bit).

Check the SLC data table size (up to 255 elements) and make the emulated data table array tag at least as large.

That will make your Data Table Element numbers line up with the Tag Array Index numbers, so that SLC-style N24:50 is represented by CompactLogix-style N24[50].

When you're doing this type of conversion, naming an Array Tag with a similar name to the old SLC/PLC style integer data table is common.

I prefer to be a little more explicit: Data Table File 24 in the PLC/SLC Mapping feature is called "PanelView_FileN24[x]", not just "N24[x]".
 
If you have the PLC/SLC mapping set up in the new PLC exactly right, you should not have to change anything at all in the Panelview. Make sure that the data types you have mapped are correct.

Logix5000 CPUs default and prefer 32 bit integers, while the SLC will always use 16 bit integers so you would need to ensure that the conversion converted the old addressing to INTs and not DINTs.
 
Can you not replace it with {::[New_PLC]N24[50]}? Or is the issue that N24 is now a DINT array where it was an INT file before (so N24:50 is now half of N24[25])? It's been almost a decade since the one time I did such a conversion, so I don't recall the specifics of how the data files were converted.

I could, but I'd have to do that for each individual INT. It takes about 30 seconds per find/replace to complete.


If you have the PLC/SLC mapping set up in the new PLC exactly right, you should not have to change anything at all in the Panelview. Make sure that the data types you have mapped are correct.

Logix5000 CPUs default and prefer 32 bit integers, while the SLC will always use 16 bit integers so you would need to ensure that the conversion converted the old addressing to INTs and not DINTs.

That makes sense. I tried changing it to an INT array of the same size as the original data table and I still get the same error message. I can provide pictures if that would help.
 
First, take a step back and redefine that emulated data table as an array tag of data type INT (16-bit), not DINT (32-bit).

Check the SLC data table size (up to 255 elements) and make the emulated data table array tag at least as large.

That will make your Data Table Element numbers line up with the Tag Array Index numbers, so that SLC-style N24:50 is represented by CompactLogix-style N24[50].

Logix5000 CPUs default and prefer 32 bit integers, while the SLC will always use 16 bit integers so you would need to ensure that the conversion converted the old addressing to INTs and not DINTs.

While this is highly desirable for obvious reasons, it is not, strictly speaking, 'necessary' and as such should not be the cause of the issue here. The Rockwell technote (ID: QA56408 | Access Levels: Everyone) covering setting up the mapping gives a specific example of mapping a DINT[20] array to be read as N42:0 through N42:39 (40 INTs).

While I'd absolutely agree that in the end you should be using INT arrays for the integer files, changing that doesn't address the actual apparent inability to read the mapping.

I could, but I'd have to do that for each individual INT. It takes about 30 seconds per find/replace to complete.
Your reluctance is quite understandable.

Can you post screenshots of your mapping and setup so we can make sure there isn't something obvious wrong?

Just to verify, you can read other tags from [New_PLC] correctly, just not through the mapping?
 
Bit Writes of Integer data

If you have any bit writes of N: integer file data with the original SLC they may give you problems with the mapped thing with CompactLogix. I don't think that CompactLogix responds to AND/OR masked writes. The Panelview may then have to go to RMW - Read, Modify, Write operation. I don't know if it has options for that as I do not use Panelviews.

Not an issue if there are no bit writes.
 
Thank you very much for posting those screenshots ! I have annotated and embedded one of them for forum purposes.

I think the problem is related to a very old and basic FactoryTalk addressing syntax issue that has been a PITA for many years. I will summarize as best I can.

FactoryTalk View SE has a whole data server "area" syntax where you're supposed to enclose the data server name in colons, like this:

:AreaName:[ShortcutName]Tag_Name


Whoops, said the FactoryTalk developers in 2002. Colons appear in virtually all PLC/SLC data table addresses. And we already wrote the parser to look for colons in the whole string instead of only before the first square bracket that holds the shortcut name.

The solution was to use "Area name escaping", where adding two colons with nothing between them before the Shortcut name indicated to the data server that the upcoming data table address was a PLC/SLC data table.

::[ShortcutName]N7:0

I think that at some point in the intervening years, the software developers instead decided that if the Shortcut was pointing to a PLC/SLC device, they would just assume that they would use the Data Table Read/Write services, and interpret the address like a PLC/SLC Data Table, so the preceding double-colon was not necessary.

{[New_PLC]N40:0} should work without the double-colon, but only if the target device is a PLC/SLC in the RSLinx Enterprise driver configuration.

{[New_PLC]N40[0]} should work with or without the double-colon because there's no need to designate an Area or "escape" a subsequent colon in the address string.

Mapping_Addresses.png
 
Last edited:
Ken,
Thanks for the response! Very good information. I tried removing the double colon but unfortunately still ended up with the same error in the diagnostics list above.
 
I've got some history with why things are this way that aren't very helpful to anyone, so I'll... let them go and apologize for not refreshing my memory before commenting. Suffice it to say that if you are frustrated with this feature / issue, you can get in line behind literal human generations of users.

As far as I can tell/recall/test, you cannot use PLC/SLC addressing in FactoryTalk View ME on a PanelView Plus to read data from a ControlLogix or CompactLogix over Ethernet.

You can do it over DF1. You could do it over DH+, or ControlNet, if you had the hardware.

You could do it with FactoryTalk View SE, because you could use Kepware or RSLinx Classic.


But not with FactoryTalk View ME and RSLinx Enterprise / FactoryTalk Linx. The software identifies the ControlLogix as a ControlLogix when you're connected over Ethernet, and disables "PCCC" addressing regardless of the syntax or configuration.


I think your only option is to buckle down and do conversion from "N24:x" to "N24[x]".
 
Also: is your username a reference to Notre Dame of Maryland ?

I've also got history with some of those alumnae.
 
Last edited:

Similar Topics

Good Evening , We have an obsolete Panelview 300 Micro that is "toast" . Our electrician ordered a Panelview 800. Apparently it sounds like...
Replies
1
Views
3,635
Hello, I am inquiring if anyone else has had this issue, I have talked with rockwell tech connect and even they have been unable to resolve yet...
Replies
3
Views
2,007
Hi Guys, I'm currently in the middle of a conversion from a PanelView 1400E touch screen to a Panelview Plus 1250. The existing panelview works...
Replies
3
Views
7,161
Hi, We've got a customer who need to convert 3 running PV 1200 application into a RSView32 program. Is there any direct conversion software to...
Replies
2
Views
3,941
Hi everyone, I have a customer who wants to replace an existing standard Panelview 1000 with a Panelview Plus. Converting the file is no issue...
Replies
2
Views
3,479
Back
Top Bottom