FactoryTalk ME locking up

[Ordinaryuser]

Hello,

Looking for anyone to help with a problem. We had a Panelview die with a power outage. Went to download the saved program onto a new PanelView Plus 1000 and had the following issues.

While opening the project in FactoryTalk View Studio (11) I tried to create a runtime application. It was going through the process and eventually it froze on a certain display. I had to force close Studio out. Upon re-opening it with this program I noticed the display it locked up on was blank. I tried to create another runtime and had it stall on the next listed display (on the explorer pane). Same thing, had to force close the program and upon opening it again I had now two displays that were blank. Luckily I could just restore the application and had everything back to normal.

Except I still can't create a runtime and transfer the application to the panelview.

The strange thing this is only happening when I'm pointing it to one certain processor which unfortunately has all of the programming associated with this HMI. Opening up the tag browser has the same similar issue with locking up studio where I need to force close through Task Manager. It seems like anytime the application looks to the processor it locks up.

I point this HMI to any other processor on our network and I can create runtimes and view tags through Studio with this application that seems faulty.

The issue processor is a L83E and there is other HMI's using it. But same thing when I open the tag browsers in the other applications associated with this processor, they lock up as well.

Any help?

 

[A_G]

Except I still can't create a runtime and transfer the application to the panelview.

The strange thing this is only happening when I'm pointing it to one certain processor which unfortunately has all of the programming associated with this HMI. Opening up the tag browser has the same similar issue with locking up studio where I need to force close through Task Manager. It seems like anytime the application looks to the processor it locks up.

Welcome to the forum!

i'm not sure I understand. The first part of your issue is that you can't create a runtime FTView application. The second part involves communications with a PLC processor. These sound like two different issues


When you create a runtime FTView application, you don't have to be connected to a PLC. You just create a .mer file on your laptop/PC that doesn't have to be connected to anything

If I'm misunderstanding then please correct me

 

[plvlce]

The first part of your issue is that you can't create a runtime FTView application. The second part involves communications with a PLC processor. These sound like two different issues

Agreed

For the first issue, I assume he means that when creating the .mer, the progress bar showed [display name] as what it was doing when Studio locked up.

However the statement 'The strange thing this is only happening when I'm pointing it to one certain processor' is erroneous in that case -- you do not point to a processor when creating a runtime. (You do usually set the path in the comm setup, but afaik nothing actually uses that path in the .mer creation process)

Hanging when opening tag browser does sound like a communication issue.

Occam's razor suggests the two may be related, but it's quite possible they're not and it's just a coincidence it's the same project having issues.

I would start by verifying the Design comm setup is correct, as that is what will be used when using the tag browser.

 

[Ordinaryuser]

Thanks for the replies and I apologize for the miscommunication.

Agreed

For the first issue, I assume he means that when creating the .mer, the progress bar showed [display name] as what it was doing when Studio locked up.

Exactly. First attempt at creating the runtime it locked up on the first created display in the explorer pane. Which at this point I didn't think too much and had to hard reboot with task manager. The next attempt made it passed the first display which is completely blank and locked up on the next display.

However the statement 'The strange thing this is only happening when I'm pointing it to one certain processor' is erroneous in that case -- you do not point to a processor when creating a runtime. (You do usually set the path in the comm setup, but afaik nothing actually uses that path in the .mer creation process)

I made an assumption that during the creation of the runtime maybe it was scanning/looking at tags associated with the displays from the processor or something. The only common thing to all these freeze ups is this one L83E.

Hanging when opening tag browser does sound like a communication issue.

Occam's razor suggests the two may be related, but it's quite possible they're not and it's just a coincidence it's the same project having issues.

I would start by verifying the Design comm setup is correct, as that is what will be used when using the tag browser.

So I have taken this whole program and moved all the logic to another processor and have had no problems. But once I point it back to the L83E is when it will lock up on either compiling a run time or trying to look through the tags in that processor. The comms are/were set correctly.

Its as if Studio doesn't like something with that processor. Another HMI in the area uses it as well. Nothing has changed with the FT program or comms yet when I open it in Studio it will fault when I try to browse the tags. In this specific program it's pointing at two processors and the other tags scan fine. This HMI out in the field is acting absolutely normal even when interacting with data from the "trouble" processor.

 

[Ordinaryuser]

Hello again world,

After pointing this to the other processor everything worked fine, until it didn't.

After about 2 months now i'm having the same issues again. Now with this other processor. If I set the comms path to look at either of these "troubled" processor once I reach out to it via tag browser or creating a runtime FTV locks up.

I set a random processor to this from around our site and there is no issue. No locking up at all but of course my tags aren't there so I have ?????? all over.

One common thing between these two troubled processors is that they both plug into the same smart switch enroute to our network. Has anyone experienced issues communicating through a specific switch to a processor? Something FTV doesn't like or vice versa?

Its a 8 port HP J9565A Switch

 

[Ordinaryuser]

Both of these processors are operational and in use. I can ping, connect through Logix etc. But for some reason cannot communicate through FTV. Once it tries, it locks up the program.

 

[JeremyM]

If FTView ME compiles ever freeze, the minimum required solution is a reboot.

 

[jholm90]

If comms issues exist and can't be explained, write down your shortcuts and delete the communications tab in the tree. Start a new communications with default settings. On the local tab choose the shortcut and plc as desired. On runtime tab, don't copy from the local, manually add the processor on the correct route so only the processor exists in the runtime tab. Apply the shortcut to this processor as well.

 

[Ordinaryuser]

If comms issues exist and can't be explained, write down your shortcuts and delete the communications tab in the tree. Start a new communications with default settings. On the local tab choose the shortcut and plc as desired. On runtime tab, don't copy from the local, manually add the processor on the correct route so only the processor exists in the runtime tab. Apply the shortcut to this processor as well.

Thank you jholm, I believe this remedied it. I've already moved the logic to another processor but this is good to know for the future.

Oddly enough, as this happened when looking at two separate processors at two separate times, both were preceeded by a power outage on our site.

I'll have to wait and see if this happens again on the next outage.

 

[Robb B]

Have you tried rebooting the PLC itself? We ran into a similar situation with 1 PLC (compactlogix) communicating with 2 identical HMI (panelview). One of the HMI could not establish communications after a power failure, but the other kept communicating. Turns out there were unfinished edits in the PLC and something had gotten stuck in the communications tree. Rebooting all 3 devices (and closing the unfinished edits) fixed it.