FTV and Panelview Plus issue

Hi all

I modified an existing PVP program (added a new screen, some numeric entry and displays and buttons) and then saved the runtime to a version I know would work in the HMI (in this case, 8.0--even though the attributes of the panel say it's version 8.10, it came up with an error with version mismatch so only 8.0 and below will load) and upon the reboot it says there's an unsupported communication protocol, continue or cancel. I always continue and the program works fine. I don't understand the error because no protocols have been changed in the program modification. The HMI still functions correctly, it's just this message that concerns me.


Thanks

The following thread may help you out with an explanation.
http://www.plctalk.net/qanda/showthread.php?t=115201
'It's probably telling you that there's a CPU in the comms schema that's not supported by the firmware on the terminal.'

Regards,

gclshortt said:

The following thread may help you out with an explanation.
http://www.plctalk.net/qanda/showthread.php?t=115201
'It's probably telling you that there's a CPU in the comms schema that's not supported by the firmware on the terminal.'

Regards,

Click to expand...

thanks--this was the only info I found when I did a prior search before posting the question; the concern is that aside from the content of the program, nothing changed. Controller is the same, etc. Nothing added to the configuration. If I was to load and run the original program still stored in the HMI memory would the error return, I don't know because I haven't tried.

Any other thoughts on this issue? Google search doesn't offer many answers.

What function does the check obx replace terminals communications do if it's checked when you're downloading the same but modified program into the HMI. I don't check it currently.

toddp65 said:

Any other thoughts on this issue? Google search doesn't offer many answers.

What function does the check box replace terminals communications do if it's checked when you're downloading the same but modified program into the HMI. I don't check it currently.

Click to expand...

Hi,

First, the "checkbox"...

Within the terminal's Configuration Mode settings (on the terminal itself), you may configure the driver/device settings to communicate with the controller.

Within the software i.e. FactoryTalk View Studio, you may also configure the Communication Setup under the Runtime (Target) tab for the driver/device settings that the application will (optionally) use to communicate with the same controller.

When you download the application, the terminal will prompt you to select either the terminal's own communications settings (don't check the box/don't replace communications), or the application's Communication Setup (check the box/replace communications).

If you are not checking the box each time you download, then the terminal is using its own settings to communicate with the controller. If you were to check the box, and replace the terminal's communications settings with those of the application, then what will happen at runtime will depend on whether or not the Communication Setup for the application has been correctly configured under the Runtime (Target) tab for the controller in question. If it has not, then you will receive errors and the HMI will not communicate with the controller. You would have to download again and choose not to replace communications again. You would also have to configure the terminal settings again.

I have also come across setups where both the application and the terminal have been configured identically so that either/or could be used i.e. it does not matter whether you choose replace communications or not.

Whether a "modified" HMI application will matter with respect to this checkbox would depend on whether or not the modification was applied to the Communication Setup. Otherwise, a standard graphical modification, for instance, would have no effect on whether or not you check the replace communications option.

As for the error...

"There is an unsupported communication protocol. Do you want to continue?"

The following technote outlines the likely issue...

714540 - PanelView Plus unsupported communication protocol error
Access Level: Everyone

Just to make a small but important distinction here...

There could be an unsupported device, such as a controller (CPU), present, but that is not what is throwing this warning message. For example, you could remove an unsupported device, but its driver could still be present. If the driver itself is unsupported, the message will remain. It is the unsupported driver that the warning is prompting you of, and not the device(s) under the driver.

Moving on...

Within an application's Communication Setup>Runtime (Target) tab, it is possible that an unsupported communications driver may have been added to the topology, along with a supported and intended to be used driver. More than one driver may be present at the same time. For instance, a terminal could be going to communicate using Ethernet and this driver is present under the Runtime (Target) tab with the correct controller added as an Ethernet device. However, there could also have been, say, a DH485 driver added for some reason. Perhaps some other testing was carried out. But the driver was not removed before the application was compiled.

When the application is downloaded to the controller with the supported and unsupported drivers included, the terminal will detect this and, because it does not know whether or not the unsupported driver is intended to be used, it will warn you that it is present. As this is just a warning, you may choose to ignore it and proceed. If the intended driver is also present, and configured properly, then it should still be able to communicate successfully, regardless of the fact that another unsupported and unused driver is also configured.

That scenario, of both a supported and an unsupported driver being present in the application, would likely only apply if the communications settings are being configured in the software. If not using the Communication Setup within the application at all, and only using the terminal's settings, then there could be "who knows what" under the Runtime (Target) tab. There could potentially be more than one unsupported driver, for example.

As you are not checking the replace communications option at download, you are using the terminal's communications settings exclusively. Therefore, any or all drivers within the application's Communication Setup>Runtime (Target) tab are not being used. I would review these drivers and delete any that you believe to be unsupported by the terminal model you are using. Then recompile the application and download to the terminal again. This should get rid of the unsupported protocol warning messages you are receiving.

Just to be clear though, as long as the terminal's communications settings are correct and your HMI is communicating successfully with the controller, the warning message is harmless.

Still, it is annoying, I will agree, and I am also of the mind to try understand/resolve these niggly little issues.

!IMPORTANT!

If you are not using the Communication Setup in the application, and it is not configured correctly either way, and you choose to replace communications, even just once for the heck of it, then you will replace (overwrite) the terminal's communications settings with those of the application. The HMI will then most likely not communicate with the controller successfully. You would have to manually edit the terminal settings back to a known good configuration to resume controller communications. Another option would be to add the correct driver/device setup in the application and download again, choosing this time to replace communications. This will update the terminal settings to the correct ones and you would be good to go again.

Regards,
George

Thanks, Geo, for that response.

The only driver or comm protocol I see when I open the comm configuration in my rslinx classic besides ethernet/IP, is the virtual backplane. I never modified the program in regards to this I only modified/added screens, saved runtime and then used transfer wizard. Now I have deleted the virtual backplane from linx; however in the comm setup for FTV project under enterprise settings, the backplane is not on the trees that open up.

I don't know if it was there before I deleted it from linx class--however is that even relevant because they are two separate programs and i don't even use classic to up/download the FTV program so I'm at a loss.

Before I get into the below, I just wanted to correct something I was alluding to in my last post...

The warning message is detecting, specifically, a Shortcut which includes an unsupported driver, and not that it is detecting the driver directly within the Runtime (Target) tab. Of course, the Runtime (Target) information is only in the software and not included in the compiled application with respect to what will be used to communicate at Runtime. So it would be one or more Shortcuts which could be at fault. It's just that you could be reviewing/deleting certain drivers under the Runtime (Target) tab when it should be the Shortcut(s) that you need to review/delete/recreate.

OK, moving on...

toddp65 said:

...The only driver or comm protocol I see when I open the comm configuration in my rslinx classic besides ethernet/IP, is the virtual backplane. I never modified the program in regards to this I only modified/added screens, saved runtime and then used transfer wizard. Now I have deleted the virtual backplane from linx; however in the comm setup for FTV project under enterprise settings, the backplane is not on the trees that open up.

I don't know if it was there before I deleted it from linx class--however is that even relevant because they are two separate programs and i don't even use classic to up/download the FTV program so I'm at a loss.

Click to expand...

I was not referring to RSLinx Classic at all in my previous post, in case you mistakenly thought I was? What you have done here (deleting virtual backplane driver in RSLinx Classic) is a little misguided, I feel.

What you do in RSLinx Classic is irrelevant beyond the point of creating a driver to establish communications with either or both your controller and HMI terminal. You will undoubtedly need to do this to download/go online with your controller. But using RSLinx Classic can be optional for the HMI, depending on whether or not you want to establish communications with it to do things like flash firmware or download an application. But you do not need RSLinx Classic, or any of its drivers, to establish communications between your HMI and the target controller.

Think about it logically. The only places that can have any influence over what the HMI terminal will be able to do, communications-wise at Runtime, is either in the application (RSLinx Enterprise>Communication Setup) or in the terminal (Terminal Settings>Networks and Communications). These are the places I would be reviewing...

Shortcuts and drivers under Runtime (Target) tab
RSLinx Enterprise configuration under Terminal Settings>Networks and Communications

You can add the virtual backplane driver back into RSLinx Classic by navigating to Communications>Configure Drivers (or use the shortcut button with the cable on it) and then use the drop down field at the top to select the virtual backplane driver and proceed to add it back in.

Any further questions on what or where to look at possible unsupported drivers, feel free to ask.

Regards,
George

Geo-

I had deleted that virtual backplane driver while reading another snippet from an A/B search item on a similar topic. I did confuse rslinx with rslinx enterprise and realized my error. I realize that FTV runtime on the PVP isn't using either of those softwares and you verified that.

Those setting you mentioned are only located in the software in the configuration menu on the PVP itself, correct? I do remember looking through those but what would I be looking for that would create the error?

Hi,

It sounds like you are still not quite there yet on your understanding of what is what or where is where?...

toddp65 said:

...I realize that FTV runtime on the PVP isn't using either of those softwares and you verified that.

Click to expand...

No, I just pointed out that RSLinx Classic is not used here. RSLinx Enterprise, and its drivers, are specifically what the HMI is using to communicate, whether you configure the communications in the application or directly on the terminal.

toddp65 said:

...Those setting you mentioned are only located in the software in the configuration menu on the PVP itself, correct?

Click to expand...

Again, no. They are both in the software on your computer and also on the terminal itself.

On your computer...

Within FactoryTalk View Studio (FTVS) software you have the RSLinx Enterprise section in the navigation window on the left (down near bottom of list). This is now called "FactoryTalk Linx" in newer versions of FTVS, but we'll not get into that here unless you mention that is what your version shows. Under RSLinx Enterprise you should see the Communication Setup section. This is where you configure a communications "Shortcut" for the application so it can communicate with the controller. To do this you use the Runtime (Target) tab. Do you know or have you seen this section within FTVS software on your computer?

On the terminal...

The communication settings on the terminal are under Terminal Settings>Network and Communications. Can you access Configuration Mode on the terminal which gives you access to the terminal settings?

These are the two places you may configure the communications between the HMI terminal and the controller. These are the two options you are choosing between when the replace communications option is displayed.

Let me know if anything is still not clear?

Regards,
George

I understand what you're saying, I guess in my hastened response I didn't express that.

I have pointed to the tabs you have mentioned (runtime target tab on FTV Rslinx Enterprise. setup) and I can navigate to the communications setup on the terminal itself.

I get that if you select replace comms then what is in FTV will replace the terminals settings. The project on my laptop points to the controller IP address and the network, ethernet bridge and the terminal itself.

But how does that warning factor in? You're basically just informing me what happens when you replace communications. If the setup is the same on laptop and PVP, then there should be a difference if you replace them, correct, but since they're the same there's no need to.

toddp65 said:

...The project on my laptop points to the controller IP address and the network, ethernet bridge and the terminal itself...

Click to expand...

OK, first, now that we know you are viewing the Runtime (Target) tab...

On this tab you are seeing this topology, for example...

+EtherNet, Ethernet
_+[] <IP Address>, 1769-L16ER, etc.
___[ ] <IP Address>, PanelView Plus 7 1000, etc.

They are just examples to demonstrate what you are likely seeing. Can you confirm it is similar to that?

Two things - other than the default "1789-A17, Backplane" instance, is the "EtherNet..." driver the only driver in the list?

Also, the HMI terminal itself should not, or is not required to, be in the topology for the Runtime (Target) configuration. The terminal will not be communicating with itself at Runtime. This usually happens as a result of the terminal being present on the opposite Design (Local) tab and then having been copied over to the Runtime (Target) tab by using the "Copy from Design to Runtime" option which is available on the Design (Local) tab. I'm not saying that is what you did or how it got there, I'm just saying that is how it most often happens. You (someone) could also have manually added it to the Runtime (Target) topology.

On the left, do you see the "Device Shortcuts" window? Is there a Shortcut created in this window with a certain name? If there is, then down at the bottom right you can select "Verify". This will open the "Shortcut Verifier" window. Here you can see if any controller has been assigned to the Shortcut. This is usually vague like "[Logix Device]". This Shortcut path may be used at Runtime to point the terminal to the intended driver (protocol) and controller. To assign a controller you must manually add it to the correct driver on the Runtime (Target) tab (EtherNet in this case) and then add the controller to the driver by right-clicking and browsing to or typing in the correct model/revision of controller you will be using (yours is already there, right?). You then "Add" a Shortcut on the left, giving it a name of your choosing, and then highlight the new controller on the right. Once highlighted, you will see the "Apply" button become available on the "Device Shortcuts" windows. This will now apply the Shortcut name to the selected controller which means all tags in the project, intending to be used with this controller, will now have the Shortcut name prepended to the tag references.

Example:

Shortcut name = MyPLC (< applied using the example 1769-L16ER controller)

All tags referencing this controller will now be prepended as follows...

Example to address "MyTag"...

{::[MyPLC]Program:MainProgram.MyTag}

I'm just explaining the Shortcut setup in case you do have one in the FTVS application.

toddp65 said:

...But how does that warning factor in? You're basically just informing me what happens when you replace communications. If the setup is the same on laptop and PVP, then there should be a difference if you replace them, correct, but since they're the same there's no need to.

Click to expand...

Correct. Usually you would use this when you want to exclusively use the applications configuration (which is different to the terminal) or you want to update the terminal's configuration with what is in the application. Once you have chosen replace once, then both the application and the terminal should be the same.

It would then be the case that as both the application and the terminal settings are identical, it does not matter whether you choose replace communications or not in the future.

If you say or think they are identical then I am not sure what else could be throwing up this warning? The terminal is seeing something somewhere that it does not support.

Just be sure that no other drivers, besides Ethernet ones, are present either on the Runtime (Target) topology, assigned to any Shortcuts (if any created), or under the RSLinx Enterprise section on the terminal menu.

If you are describing what you see then please be specific.

Regards,
George

here's a screenshot of my FTV communication configuration.

The first is the configuration, the other is the info from the shortcut verifier.

That shortcut is what I begin all of the assigned tags to various objects in the HMI program {[filler]Db.1.Rinsetank}

Do you see anything out of sorts?

There are warning on the verifier. I have not changed any of this.

Thanks for all your concentrated help on this.

The 'Shortcut' needs to point to the CPU controller; yours points to 'anywhere' on the Ethernet network.

Expand the 10.255.189.120 bridge, find the CPU and then click on it (highlight it).

Only when the CPU is selected (highlighted in the right window pane) pick the 'Verify' button and then 'OK' it.

Before we sort the Shortcut, I am mindful that you said in the beginning that you are always choosing not to replace the terminal settings when you download the modified MER application file. I had assumed this to mean that this is and always was the correct option for this system setup i.e. using terminal settings and not the application?

The only reason I was interested in what is under the Runtime (Target) tab was to find out if there were any other drivers/devices there that should not be there. I was not interested as much so as to ensure you have a working Runtime (Target) configuration, if you are not using it.

But now that you mention that all your controller tag references are pointing to this "filler" Shortcut, it is very important that both this Shortcut is correctly configured, and that you DO choose replace communications when you next download the modified MER application.

As dmargineau is instructing you, your Shortcut for Runtime "appears" to be pointing towards the "EtherNet, Ethernet" driver directly and not towards your controller. A quick way we/you can see this is by mouse clicking on your Shortcut "filler" and then it should highlight (in Blue) whichever point in the topology the Shortcut was applied to. As the "EtherNet, Ethernet" driver appears in Blue in the screenshot, it "looks" like that is where the Shortcut is currently pointing to? Click the Shortcut and see what shows in Blue, just to double-check this.

We also know that something is applied to this Shortcut for Runtime because the Warnings say that the Runtime device path is not found and that Design and Runtime are assigned differently i.e. they are assigned but not the same. Design is assigned a [Logix Device] so that means Runtime must not be. But it should be. Also, if Runtime was assigned correctly, you would have a similar line stating "Path to Runtime device is assigned [Logix Device]".

As instructed, expand the Ethernet Bridge and you should see the Backplane for the CompactLogix system. This should also be expandable and under it you should find your 1769-L32E processor instance. With this processor highlighted, you should then see the "Apply" button is available (not "Verify" - this is for checking after Shortcut is created). Once you apply the processor to the Shortcut you can then select "Verify" and you should then see in the "Shortcut Verifier"...

Path to Runtime device is assigned [Logix Device]

If the IP address of the PanelView Plus shown in the screenshot is that of the terminal this application is going to run on, then Right-click on the "...PanelView Plus_6 1000..." instance on the Runtime (Target) tab and delete it. It is serving no purpose being there.

When finished, select "OK" at the bottom and close the Communication Setup window. Then save and compile the application. Download again and this time select replace communicatons. This should update the terminal settings for RSLinx Enterprise with the Shortcut configuration and the communications should hopefully work.

The original warning is likely being triggered by having the "EtherNet, Ethernet" driver incorrectly assigned as the Shortcut Runtime device.
Actually, no? You cannot assign the "EtherNet, Ethernet" driver to a Shortcut. Only valid devices like processors.
So that means the driver is only highlighted Blue because it had been mouse selected.

Reading the Warnings again, it appears as though the Runtime Shortcut was assigned to a different family other than a [Logix Device]. Say a [MicroLogix Device] or [SLC Device]?
I wonder was a device assigned and then removed from the Runtime (Target) topology?

Regards,
George

When I open the config and go to the runtime side, the right side already drills down to the actual L32E controller before I even click on the 'filler' shortcut so it appears if it's already points to the controller.

Keep in mind I don't believe i changed anything and never changed the communication configuration or checked that box.

I'll respond more when i can