Factory Talk Se Runtime Display Indicator

PLC_Newbie_18 · Nov 15, 2014

Hey guys, I am working with Factory talk version 6.0.

What I am doing is using 3 separate macros to write to a tag for on start up to make the screens unique.

Screen_Memory_Tag=1
Screen_Memory_Tag=2
Screen_Memory_Tag=3

Those are my 3 macros. All Separate macros. HMI 1 calls macro 1, HMI 2 calls macro 2, and HMI 3 calls macro 3.

The issue i am having is that when the last HMI loads it over writes the Screen_Memory_Tag. I thought that in the runtime file it made it specific to that client.

Could anybody help me out with this one.

Basically trying to make each HMI client unique.

Operaghost · Nov 15, 2014

The clients are essentially just three windows into the same application. They all use the same tags.

Can you explain what you are trying to accomplish?

OG

ASF · Nov 16, 2014

I've done the same thing just recently. Your problem, as you seem to understand, is that the clients all run their own application, but the Screen_Memory_Tag is a single tag stored on the server, not a tag with a copy on each of the clients.

The way I solved it was to use VBA to look at the computer name on startup, and make certain elements visible/invisible based on which computer has loaded the application.

rdrast · Nov 17, 2014

Another (and easier to maintain) way to selectively customize clients in the dung heap that is FTView SE is to use the "File_Exists(SomeFileName)" function for visibility or access.

Create a text file on the root of the boot drive for easy typing, maybe you want to use "C1.TXT", "C2.TXT" etc... then under an object's "Animation | Visibility" property, use File_Exists("C:\C1.TXT").

ASF · Nov 17, 2014

I have to admit, that's easier than my idea.

Although just to play devil's advocate, you could run into trouble with that method if 5 year's down the track your client computer dies. If the person replacing it isn't aware of this trick, they won't know to put the file back - they may just install FTView Client software, load up the application and put it back into service. Could take a while to figure out what's missing. Whereas with the Visual Basic method it's fully self contained, just as long as you set up the computer name correctly.

rdrast · Nov 18, 2014

ASF said:
I have to admit, that's easier than my idea.

Although just to play devil's advocate, you could run into trouble with that method if 5 year's down the track your client computer dies. If the person replacing it isn't aware of this trick, they won't know to put the file back - they may just install FTView Client software, load up the application and put it back into service. Could take a while to figure out what's missing. Whereas with the Visual Basic method it's fully self contained, just as long as you set up the computer name correctly.

Well, sort of, but our domain disallows EVER duplicating a name*, so if the computer dies, we have to assign a new name, which means editing the VBA or other code. The FileExists method means you don't have to go and edit the application.

---
* Well, it is possible, but that would be getting IT involved, writing up proposals and justifications, dealing with back and forth emails and phone calls, and would take more than a week, so we just don't do it.

PLC_Newbie_18 · Nov 18, 2014

Guys thanks very much for the help. All of you seem to understand exactly what im doing.

As far as the VBA goes for writing a script would you be able to give me an example of how you did that please? Still a little fuzzy on all the capabilities of VBA

Thanks much!

rdrast · Nov 18, 2014

Honestly, checking for a text file is much easier, but here is the VBA to get the computer name, and an example of how to use it on DisplayLoad():

Code:

Option Explicit


'*******************************************************************
' Function Declarations:
' GetComputerName is imported from kernel32, and used to determine
'                 exactly what computer this routine is running on.
'                 
'*******************************************************************
Private Declare Function GetComputerName Lib "kernel32" _

--------------------------------------------------------------------

'*******************************************************************
'  Function: ComputerName()
'   Returns the network name of this computer as a string.
'*******************************************************************
Public Function ComputerName() As String
  Dim sBuffer As String
  Dim CName As String
  Dim UpperCase As String
  
  Dim lAns As Long
 
  sBuffer = Space$(255)
  lAns = GetComputerName(sBuffer, 255)
  If lAns <> 0 Then
        'read from beginning of string to null-terminator
        CName = Left$(sBuffer, InStr(sBuffer, Chr(0)) - 1)
        UpperCase = UCase(CName)
        ComputerName = UpperCase
   Else
        Err.Raise Err.LastDllError, , _
          "A system call returned an error code of " _
           & Err.LastDllError
   End If

End Function



Usage:

Private Sub DisplayLoad()

     If ComputerName() = "WhatEverName" Then
        SomeGlobalFlag = True
     Else
        SomeGlobalFlag = False
     End If
End Sub

PLC_Newbie_18 · Nov 18, 2014

Yeah i ended up going the route of the txt file and that seemed to work easier!

Thanks guys

ASF · Nov 18, 2014

rdrast said:
Well, sort of, but our domain disallows EVER duplicating a name*, so if the computer dies, we have to assign a new name, which means editing the VBA or other code. The FileExists method means you don't have to go and edit the application.

---
* Well, it is possible, but that would be getting IT involved, writing up proposals and justifications, dealing with back and forth emails and phone calls, and would take more than a week, so we just don't do it.

Wow, really? What possible reason could they have for that? Are they preparing for the zombie apocalypse of the PC world perhaps?

Oh well, as long as the OP got it working. I would still suggest documenting the existence, location and name of that file somewhere prominent though. Just because I've all too many times been the poor b@stard trying to work out why my display isn't working at 2am

rdrast · Nov 19, 2014

ASF said:
Wow, really? What possible reason could they have for that? Are they preparing for the zombie apocalypse of the PC world perhaps?

Oh well, as long as the OP got it working. I would still suggest documenting the existence, location and name of that file somewhere prominent though. Just because I've all too many times been the poor b@stard trying to work out why my display isn't working at 2am

Yes, more than possible. Computer accounts in a domain are not just a name, they are also a hardware ID, whatever it might be. New hardware, same name means rejected by the domain. Deleting a computer from the domain is also impossible for us folk on the floor.

Once corporate IT gets their grubby hands on your industrial PC's, you lose all control of everything and all bets are off.

ASF · Nov 19, 2014

Hmm, that's interesting...is that all Window's domains, or only if IT have it set up that way? I've not had to change a failed SCADA machine on a Domain before, so that could be a could trap to know about!

rdrast · Nov 20, 2014

ASF said:
Hmm, that's interesting...is that all Window's domains, or only if IT have it set up that way? I've not had to change a failed SCADA machine on a Domain before, so that could be a could trap to know about!

We only run Windows domains here, but I'm sure that at this date, any can be set up for hardware detection when a computer is added to the domain.

Factory Talk Se Runtime Display Indicator

PLC_Newbie_18

Member

Operaghost

Member

ASF

Lifetime Supporting Member

rdrast

Lifetime Supporting Member

ASF

Lifetime Supporting Member

rdrast

Lifetime Supporting Member

PLC_Newbie_18

Member

rdrast

Lifetime Supporting Member

PLC_Newbie_18

Member

ASF

Lifetime Supporting Member

rdrast

Lifetime Supporting Member

ASF

Lifetime Supporting Member

rdrast

Lifetime Supporting Member

Similar Topics