Factory Talk 7.0 sticky buttons

[Jcooli09]

I've got a Factory Talk 7.0 project running on Windows 7.

We are a bulk product distribution facility with 2 scales. Each scale runs on a seperate display which are identicle except that one scale loads from 3 silos and one screen loads from 2.

On one of the displays I have a problem with sticky buttons. It's only a couple of them and it isn't every time.

These buttons 'set tag to 1 on press and to 0 on release'.

I changed the action on one of them to run command,set the tag at 1 on press and set the tag at 0 on release. It doesn't happen as often but it still happens.

Has anyone else seen this problem, and if so what did you do about it? I'm going to put some bandaids in the ladder, unlatch the bit if weight comes off the scale or something. It's not very elegant, though, and offends my sensibilities.

 

[Bob O]

I have seen this more then I would have liked in RSView32 and even in a PV+ and I have started to put an unconditional OTU rung after the offending bits or the other ones that could be a problem.

Hope this helps

 

[Ken Roach]

I never use "momentary" buttons in FactoryTalk View for exactly this reason.

Usually there is some network loading or messaging priority issues involved, but I'm not convinced that FactoryTalk is capable of reliably sequencing these commands.

So I just use "set to 1" as my Release command. In the controller logic, I use an OTE to reset the bit to False once I'm done using it as a pushbutton command.

In my experience, that method has been completely reliable.

 

[Kev77]

I think there is something going on in version 7.0. I run a SE project with several clients and when I upgraded I started seeing the same issue. We use some VBA within some groups and they were set up as command buttons. It was set to 1 on press, 0 on release and 1 on repeat. We saw the issue right away and it was crashing the clients. What I found was that when I shut down just the client application and restarted it, it would lock up on the loading screen at "starting command server".

I was able to create the condition and what seems to cause it is when you click the button serveral times fast, it would lock up the client. It would also leave the tag at the last state which would cause motors not to shut off or valves to stay open.

I tried several things but what seems to have corrected it was going into the button properties and removed the repeat action. I also told the operator that they dont need to click the button 10 times to get something to work! I contacted Rockwell and they were not much help. It seems to have corrected the issue and have not seen it in a month now.

I know very little about what the command server does but with it hanging the restart of the client and the name of the button, they seem to be connected. Restarting the client PC always seemed to fix the issue.


One other interesting thing is that in version 7.0, they have the "current program updater" that connects to check for updates. I run a server that doesn't have a connection to the internet and I have been called in several times because of slow clients and the last one was the HMI tags stopped working. I was able to track the problem back in the event logs and at the exact same time as the problems started, it logged an error that it could not connect to windows update. It was trying once a day but after about two weeks it caused issues.

I called Rockwell and they said that the error was that the "current program updater" could ot connect. They were not aware of any issues and I thought I might be crazy, but after three calls at three different times a day I am sure that this was my issue.

Good Luck,

Kevin

 

[Jcooli09]

I think there is something going on in version 7.0. I run a SE project with several clients and when I upgraded I started seeing the same issue. We use some VBA within some groups and they were set up as command buttons. It was set to 1 on press, 0 on release and 1 on repeat. We saw the issue right away and it was crashing the clients. What I found was that when I shut down just the client application and restarted it, it would lock up on the loading screen at "starting command server".

I was able to create the condition and what seems to cause it is when you click the button serveral times fast, it would lock up the client. It would also leave the tag at the last state which would cause motors not to shut off or valves to stay open.

I tried several things but what seems to have corrected it was going into the button properties and removed the repeat action. I also told the operator that they dont need to click the button 10 times to get something to work! I contacted Rockwell and they were not much help. It seems to have corrected the issue and have not seen it in a month now.

I know very little about what the command server does but with it hanging the restart of the client and the name of the button, they seem to be connected. Restarting the client PC always seemed to fix the issue.


One other interesting thing is that in version 7.0, they have the "current program updater" that connects to check for updates. I run a server that doesn't have a connection to the internet and I have been called in several times because of slow clients and the last one was the HMI tags stopped working. I was able to track the problem back in the event logs and at the exact same time as the problems started, it logged an error that it could not connect to windows update. It was trying once a day but after about two weeks it caused issues.

I called Rockwell and they said that the error was that the "current program updater" could ot connect. They were not aware of any issues and I thought I might be crazy, but after three calls at three different times a day I am sure that this was my issue.

Good Luck,

Kevin

Thanks for the reply. I'm not using repeat action at all. Using command on press and command on release seems to reduce the frequency of the problem but not make it go away completely. One of the most maddening things about it is that it only happens on one screen, and only on a couple of buttons.

I looked at the display properties and found that the one I had problems with had 'show last aquired value' unchecked. It doesn't seem to me that this should make a difference, we never had any issues with outlined indicators rather than actual data displayed. I did check it anyway, though.

I suspect it may have something to do with the button being pressed and released too quickly. The operators can sometimes be under a lot of pressure to move quickly because the drivers get paid by the ton and will express their displeasure if things move too slowly for them. Both of the buttons I have issues with are used at the end of the load. Rockwell didn't have anything to say about this possibility, or really about the entire issue.

When the button sticks the tag stays on, and clicking it a second time always seems to release it. I've temprarily set them to be green when the tag is on so the operator knows to click it a second time.

A couple of people have replied that they always put some coding in the ladder to unlatch the bit, and I'll do that but it's going to take some time and seems like a lousy way to handle the situation, and it will be difficult in some cases to pick an event to trigger the unlatch.

Regarding the current program updater, I disabled it. We have installations all around the great lakes, and I'm the only person who works on them. Version 7.0.0 works, and I'm concerned about some future update that causes a problem forcing me to travel a couple of thoudsand mailes as quickly as possible to correct some stupid clitch at 12 terminals and on 4 marine vessels.

 

[Kev77]

What type of install are you using? Mine is a network distributed on a Dell server running Windows Server 2003 sp2 with Windows XP sp3 clients. The project was originally developed in version 4 and I have had to upgrade several times due to issues. What pushed me to upgrade this time was the old watcom database would not let me browse for new tags if the sever had been running for a month or so. I would add tags and in I would see the message in the diagnostic viewer that they were added but I would be unable to browse for them. I would need to delete two tag files and reboot. It looks like the new tag database has corrected that issue but I now have another.

 

[Jcooli09]

What type of install are you using? Mine is a network distributed on a Dell server running Windows Server 2003 sp2 with Windows XP sp3 clients. The project was originally developed in version 4 and I have had to upgrade several times due to issues. What pushed me to upgrade this time was the old watcom database would not let me browse for new tags if the sever had been running for a month or so. I would add tags and in I would see the message in the diagnostic viewer that they were added but I would be unable to browse for them. I would need to delete two tag files and reboot. It looks like the new tag database has corrected that issue but I now have another.

We're runing SE on each individual PC. We had network traffic delay issues when we ran on a distributed network running 5.2 which we couldn't resolve.

We're in the process of converting all our installs to FT7 running on Windows 7 64 bit. We're making the change because of the lack of readily available new PCs with XP. We're also taking the opportunity to use the same computer and software on all of our installations. We have them spread out all over, and always used whatever computer was available. We had several versions of the software, including a couple of them in RSView32.

 

[Lancie1]

The old RSView would let you accidently copy-and-paste several copies of the same pushbutton on top of each other. That really caused problems, because these buttons would interfere with each other. The only way I ever figured out how to find duplicate copies at the same location was to delete the button and see if another was lurking below. If not, then Undo to restore the one button. If there was two or more, keep deleting until you remove all but one.

 

[Jcooli09]

The old RSView would let you accidently copy-and-paste several copies of the same pushbutton on top of each other. That really caused problems, because these buttons would interfere with each other. The only way I ever figured out how to find duplicate copies at the same location was to delete the button and see if another was lurking below. If not, then Undo to restore the one button. If there was two or more, keep deleting until you remove all but one.

That never happened to me, but I got a chuckle out of it nonetheless.

I inherited these from a couple of others who created/modified them before. One of them created several copies of buttons that reacted slightly different and were visible under different conditions. He then grouped them, presumable so he could move them around easily. This was to allow the user to select whether or not to use confirmation of specific silos.

I had a hell of a time trying to figure out what he did! The whole thing was a mess, and I ended up deleting the entire morass and starting over.

 

[Kev77]

Before I learned what the object explorer did I would do the same thing. I would also break apart groups to go through all the objects and regroup them. I ran into a problem once when I broke the group apart and regrouped it, the buttons stopped responding. This was before I realized that the buttons were controlled by VBA. When I broke the button apart and regrouped it, the name of the group was different and after about 4 hours I found it and changed the group name back. From then on I use the object explorer to get to buttons.

 

[baldone]

Sadly I have seen it several times....Now I

program any critical momentary bits to clear after a few seconds in the Logix program.

 

[rdrast]

I have seen this more then I would have liked in RSView32 and even in a PV+ and I have started to put an unconditional OTU rung after the offending bits or the other ones that could be a problem.

Hope this helps

/agree.
I have had this occur in all versions of RSView and FTView SE and ME from version 4 on up. My solution is the same as Bob O's above, I unconditionally unlatch every bool written to the PLC by the (above) HMI's immediately after it is used.

This is unfortunate, as it pretty much prevents being able to use buttons for MOP functions where you might want it to repeat, without a great deal of special programming in the HMI.

For the record, I have NEVER experienced this on any other platform, from classic panelviews, to Red Lion G3's, to Intellusion, to Wonderware... well, you get the picture.