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