fbpx

FactoryTalk View SE ActiveX controls

An ActiveX control is a component program object that can be re-used by many application programs within a computer or among computers in a network. This is a Microsoft technology that works with Rockwell Automation’s FactoryTalk SE HMI application for graphics.


 

The Importance of Having the Correct ActiveX files

Let’s take the ieframe.dll ActiveX file for example and how to check to make sure that you have the correct ieframe.dll running on your Server that is housing your FactoryTalk SE HMI application if not then you could have un-answered issues happening on our HMI application or Server crashes.

To start off with, you need to know exactly what Windows Server Edition that you are running by right-clickingWindows Server 2008 R2 on the My computer and selecting properties. This should show exactly what Windows Server version that you are running.

 

A prompt should pop up and show you what Windows Edition that you have and you can write this information down as you will use it to make sure the ieframe.dll version is correct for the Windows Server Edition that is being used.

 

 


 

Checking the ieframe.dll version

To check the ieframe.dll version you must first get the version number which is easily done using the tool the FactoryTalk has already made for this process which gets installed on the original install of any FactoryTalk Studio software. This tool is called GetVers.exe which is located in the same location as your HMI projects except for in the Project folder there will be an ActiveX controls setup folder.

Location in Windows 7, Windows Server 2008 R2, Windows Server 2012 are:

C:Users\Public\Documents\RSView Enterprise\ActiveX Control Setup

This is where the GetVers.exe is, however, you cannot just run the file from here because it is made to run with the Windows CMD.exe

Open the CMD.exe from the start menu and when it opens then type in the following cd C:User\Public\Documents\RSView Enterprise\ActiveX Control Setup then press the Enter key.

This will direct the CMD.exe directly to the ActiveX Control Setup folder.

Now in the CMD.exe type in GetVers ieframe.dll and press enter, it will then give you the version of ieframe.dll that you are using so at this point you can write the information down and close the CMD.exe prompt.


 

Compare the ieframe.dll to the Windows Server Edition

Now that you have the version of Windows Server Edition that you are using and the version of ieframe.dll, you can now verify that the ieframe.dll matches to what it is supposed to be for the Windows Server Edition.

The ieframe.dll is the ActiveX file for Internet Explorer so just check Microsoft’s website for the correct version. When I check the Microsoft website it shows Windows Server 2008 R2 should be running ieframe.dll version 8.0.7600.20955 which is Internet Explorer 8.

Windows Server 2008 ieframe

Having checked that the files are matched or not then you can decide if it is currently running the correct version or if it is not and if not then you could possibly have strange un-answered issues happening on the HMI application.

You can do this with most of your ActiveX file on the Server that is housing our HMI application.


 

FactoryTalk View SE clients can automatically install the correct versions of ActiveX controls used in graphic displays.

To deploy ActiveX controls automatically, you need to create .cab files for the ActiveX controls, and then put the .cab files in the same folder where you installed FactoryTalk View SE.

To do this, run the program CABARC.exe, on the computer hosting the HMI server. CABARC.exe is located in:

  • (Windows 7 Professional, Windows Vista, Windows Server 2008)
    ..\Users\Public\Public Documents\ RSView Enterprise\SE\ActiveX Control Setup
  • (Windows XP, Windows Server 2003) ..\Documents and Settings\All Users\Shared
    Documents\RSView Enterprise\SE\ActiveX Control Setup

For information about creating .cab files, see the text file CreatingCabFiles.txt in the ActiveX Control Setup folder. The text file contains examples for creating .cab files, and information about the naming conventions that must be used.

If you open a graphic display containing ActiveX objects that are not installed, the graphic display runs, but a shaded rectangle appears in place of the ActiveX object.

Example of this file location that has already been developed.

C:\Users\Public\Documents\RSView Enterprise\ActiveX Control Setup

Creating Cab File for FactoryTalk SE Clients

Making a CAB file is done by using the CMD prompt in Windows. First, open the CMD command prompt then enter in CD file location, for example, in the case we showed above then it would be CD C:\Users\Public\Documents\RSView Enterprise\ActiveX Control Setup.

This way the CMD prompt now pointing to that file location so that you can use the CABARC exe.

Then to make a new CAB file then in the CMD prompt, enter in CABARC N then the file name.

Let’s say we wanted to make a Keypad.ocx then here is what the first CMD should look like.

CABARC N keypad.ocx

Then press enter to make the file, at this point, you have made the file but not the CAB so in order to do that you need to then enter CABARC N then the CAB file name & what is being contained in that CAB file.

Keypad ocx

 

If you wanted to make the keypadocx.CAB then it should look like this.

CABARC N keypadocx.CAB keypad.ocx

Then press enter, it will make the new CAB file & also load in the ocx file you made as well.

If you open the new CAB file then it should now contain the ocx file.

Inside the CAB File

 

 

 

Please note that this process only makes the new files if they are not there, it doesn’t match the files between client & server, the client computers need to match the server ActiveX files so that all graphics & other elements work correctly.

There are often times where you can just copy the files made then paste them in the same file location on the client computer but this is situation dependant so please be advised to make backups of the old files if you plan on trying this so that you can put the files back if no change happens.

I hope that this was helpful and if there are any comments or questions please leave me a comment below or in the contact section of this website. We look forward to hearing from you.

Thanks,

Shane

What are FactoryTalk View SE ActiveX controls?

An ActiveX control is a component program object that can be re-used by many application programs within a computer or among computers in a network. This is a Microsoft technology that works with Rockwell Automation’s FactoryTalk SE HMI application for graphics.


 

The Importance of Having the Correct ActiveX files

Let’s take the ieframe.dll ActiveX file for example and how to check to make sure that you have the correct ieframe.dll running on your Server that is housing your FactoryTalk SE HMI application if not then you could have un-answered issues happening on our HMI application or Server crashes.

To start off with, you need to know exactly what Windows Server Edition that you are running by right-clickingWindows Server 2008 R2 on the My computer and selecting properties. This should show exactly what Windows Server version that you are running.

 

A prompt should pop up and show you what Windows Edition that you have and you can write this information down as you will use it to make sure the ieframe.dll version is correct for the Windows Server Edition that is being used.

 

 


 

Checking the ieframe.dll version

To check the ieframe.dll version you must first get the version number which is easily done using the tool the FactoryTalk has already made for this process which gets installed on the original install of any FactoryTalk Studio software. This tool is called GetVers.exe which is located in the same location as your HMI projects except for in the Project folder there will be an ActiveX controls setup folder.

Location in Windows 7, Windows Server 2008 R2, Windows Server 2012 are:

C:Users\Public\Documents\RSView Enterprise\ActiveX Control Setup

This is where the GetVers.exe is, however, you cannot just run the file from here because it is made to run with the Windows CMD.exe

Open the CMD.exe from the start menu and when it opens then type in the following cd C:User\Public\Documents\RSView Enterprise\ActiveX Control Setup then press the Enter key.

This will direct the CMD.exe directly to the ActiveX Control Setup folder.

Now in the CMD.exe type in GetVers ieframe.dll and press enter, it will then give you the version of ieframe.dll that you are using so at this point you can write the information down and close the CMD.exe prompt.


 

Compare the ieframe.dll to the Windows Server Edition

Now that you have the version of Windows Server Edition that you are using and the version of ieframe.dll, you can now verify that the ieframe.dll matches to what it is supposed to be for the Windows Server Edition.

The ieframe.dll is the ActiveX file for Internet Explorer so just check Microsoft’s website for the correct version. When I check the Microsoft website it shows Windows Server 2008 R2 should be running ieframe.dll version 8.0.7600.20955 which is Internet Explorer 8.

Windows Server 2008 ieframe

Having checked that the files are matched or not then you can decide if it is currently running the correct version or if it is not and if not then you could possibly have strange un-answered issues happening on the HMI application.

You can do this with most of your ActiveX file on the Server that is housing our HMI application.


 

FactoryTalk View SE clients can automatically install the correct versions of ActiveX controls used in graphic displays.

To deploy ActiveX controls automatically, you need to create .cab files for the ActiveX controls, and then put the .cab files in the same folder where you installed FactoryTalk View SE.

To do this, run the program CABARC.exe, on the computer hosting the HMI server. CABARC.exe is located in:

  • (Windows 7 Professional, Windows Vista, Windows Server 2008)
    ..\Users\Public\Public Documents\ RSView Enterprise\SE\ActiveX Control Setup
  • (Windows XP, Windows Server 2003) ..\Documents and Settings\All Users\Shared
    Documents\RSView Enterprise\SE\ActiveX Control Setup

For information about creating .cab files, see the text file CreatingCabFiles.txt in the ActiveX Control Setup folder. The text file contains examples for creating .cab files, and information about the naming conventions that must be used.

If you open a graphic display containing ActiveX objects that are not installed, the graphic display runs, but a shaded rectangle appears in place of the ActiveX object.

Example of this file location that has already been developed.

C:\Users\Public\Documents\RSView Enterprise\ActiveX Control Setup

Creating Cab File for FactoryTalk SE Clients

Making a CAB file is done by using the CMD prompt in Windows. First, open the CMD command prompt then enter in CD file location, for example, in the case we showed above then it would be CD C:\Users\Public\Documents\RSView Enterprise\ActiveX Control Setup.

This way the CMD prompt now pointing to that file location so that you can use the CABARC exe.

Then to make a new CAB file then in the CMD prompt, enter in CABARC N then the file name.

Let’s say we wanted to make a Keypad.ocx then here is what the first CMD should look like.

CABARC N keypad.ocx

Then press enter to make the file, at this point, you have made the file but not the CAB so in order to do that you need to then enter CABARC N then the CAB file name & what is being contained in that CAB file.

Keypad ocx

 

If you wanted to make the keypadocx.CAB then it should look like this.

CABARC N keypadocx.CAB keypad.ocx

Then press enter, it will make the new CAB file & also load in the ocx file you made as well.

If you open the new CAB file then it should now contain the ocx file.

Inside the CAB File

 

 

 

Please note that this process only makes the new files if they are not there, it doesn’t match the files between client & server, the client computers need to match the server ActiveX files so that all graphics & other elements work correctly.

There are often times where you can just copy the files made then paste them in the same file location on the client computer but this is situation dependant so please be advised to make backups of the old files if you plan on trying this so that you can put the files back if no change happens.

I hope that this was helpful and if there is any comments or questions please leave me a comment below or in the contact section of this website. We look forward to hearing from you.

Thanks,

Shane

Is Your FactoryTalk SE HMI Server healthy?

My guess I that you may not know the health of your HMI server, that is not your fault so no worries. This is a common problem because the general break down is between the IT/OT meaning between information technology and operational technology.

Most manufacturing facilities have an IT department that is completely separate from operations support and then the maintenance technical staff that maintains the equipment running.


 

IT/OT convergence

IT/OT convergence is a step that Rockwell Automation is leading to stop this breakdown between technical services and to have a base platform for IT/OT to work better side by side. Their idea of Integrated platforms that their connected enterprise offers that can boost productivity along with product quality, especially for manufacturing and industrial OEM application. The connected enterprise and the internet of things is the coming future so the time to get a base understanding is now rather than later.

Well, the truth to the matter is that most industries can’t afford to simply shut down their equipment and upgrade that equipment especially if it has been running well for many years. Most industries are waiting to do this type of move when they get newer equipment installed.

This is still a great time to get ready or get an understanding of this approach so that in the coming years as it gets implemented, we are not put in a position of culture shock.


 

Are there options to check proper HMI server health?

Actually, there are several best-practice methods that most people do not use or do not even know about which again I say that it not their fault because the problem is derived from the breakdown between IT/OT.  These practices have been around for years and are proven methods to check for errors and give you a point of reference to fix the errors that are found.

One of these practices is to check the diagnostic viewer on the bottom of an RSView Studio application. This will show you all activity that the server is doing whether it is an error, a caution, or a good transition.

Example of errors are:

Server Diagnostic Errors

 

 

 

 

 

 

 

Examples of a good transition are:

Diagnostic good transition

I did not show the whole screen because I am only trying to highlight the red X and the blue information icons to show a bad and good situation. The notifications in the diagnostic section will let you know if there is an error in your HMI application and to give you an idea of where that error is.

What I like to do is to have the diagnostic section open go through the application by pressing the screen to screen or operation buttons and make a list of any errors that occur then set priorities to the errors based upon their importance of the HMI application running. You can also leave the diagnostic section open while the system runs normally if there is a lot of operator interface on the application to give you the same effect.

Note: that all of this work can be done on a running HMI application and will not affect the HMI application, at this phase of the process you are just trying to get an understanding of the errors and to make a scope of work based of the importance of being fixed.


 

Run FactoryTalk SE Application Documenter

You can go through the whole HMI application at once using the application documenter tool however it will stop where there are any ActiveX issues on any of the pages.

If it stops then it waits on you to press ok, which just acknowledges that you are aware that there is an error, no worries of any HMI application changes being done from the application documenter. The application documenter tool is just a data collection tool and does not change anything.

After it runs then it will give you the whole HMI application in an internet explorer file to be a view but only view on the computer that the documenter is run on, this is the one downside that I see with the documenter tool.

Meaning once the documenter is run and the results page is developed then you are unable to share the documenter results file from computer to computer because it will not run. The documenter file is made just for the computer that it is made on.


 

Which method is better?

I feel that both using the diagnostic viewer on the RSView Studio software and also the application documenter are most helpful being used in a combination of both. One looks mainly for ActiveX issues and the other is a lot more itemized to give detailed errors.


 

How often should FactoryTalk View HMI system checks be done?

In my opinion, it relies on how often the HMI application is being edited or as a general standpoint every 6 months. If no errors are found then it only takes a few hours to do this work if that.

If problems are found then document them and create a list of what needs to be looked at first and fix one item at a time, I recommend documenting the fixes that you do so you can reference them at a later date and save yourself time.

Fixing HMI application errors is somewhat of a drawn-out topic so if you have any questions then leave me a comment and also visit our Online PLC Support Training Center.

Thank you for reading and if I can help out then please let me know. Leave a comment below if you like this post or if there are any further items that you would like to hear about.

Again thanks,

Shane

Is Your FactoryTalk SE HMI server healthy?

My guess I that you may not know the health of your HMI server, that is not your fault so no worries. This is a common problem because the general break down is between the IT/OT meaning between information technology and operational technology.

Most manufacturing facilities have an IT department that is completely separate from operations support and then the maintenance technical staff that maintains the equipment running.


 

IT/OT convergence

IT/OT convergence is a step that Rockwell Automation is leading to stop this breakdown between technical services and to have a base platform for IT/OT to work better side by side.

Their idea of Integrated platforms that their connected enterprise offers that can boost productivity along with product quality, especially for manufacturing and industrial OEM application. The connected enterprise and the internet of things are the coming future so the time to get a base understanding is now rather than later.

Well, the truth to the matter is that most industries can’t afford to simply shut down their equipment and upgrade that equipment especially if it has been running well for many years. Most industries are waiting to do this type of move when they get newer equipment installed.

This is still a great time to get ready or get an understanding of this approach so that in the coming years as it gets implemented, we are not put in a position of culture shock.


 

Are there options to check proper HMI server health?

Actually, there are several best-practice methods that most people do not use or do not even know about which again I say that it not their fault because the problem is derived from the breakdown between IT/OT.  These practices have been around for years and are proven methods to check for errors and give you a point of reference to fix the errors that are found.

One of these practices is to check the diagnostic viewer on the bottom of an RSView Studio application. This will show you all activities that the server is doing whether it is an error, a caution, or a good transition.

Example of errors are:

Server Diagnostic Errors

 

 

 

 

 

 

 

Examples of a good transition are:

Diagnostic good transition

I did not show the whole screen because I am only trying to highlight the red X and the blue information icons to show a bad and good situation. The notifications in the diagnostic section will let you know if there is an error in your HMI application and to give you an idea of where that error is.

What I like to do is to have the diagnostic section open go through the application by pressing the screen to screen or operation buttons and make a list of any errors that occur then set priorities to the errors based upon their importance of the HMI application running.

You can also leave the diagnostic section open while the system runs normally if there is a lot of operator interface on the application to give you the same effect.

Note: that all of this work can be done on a running HMI application and will not affect the HMI application, at this phase of the process you are just trying to get an understanding of the errors and to make a scope of work based of the importance of being fixed.


 

Run FactoryTalk SE Application Documenter

You can go through the whole HMI application at once using the application documenter tool however it will stop where there are any ActiveX issues on any of the pages. If it stops then it waits on you to press ok, which just acknowledges that you are aware that there is an error, no worries of any HMI application changes being done from the application documenter. The application documenter tool is just a data collection tool and does not change anything.

After it runs then it will give you the whole HMI application in an internet explorer file to be a view but only view on the computer that the documenter is run on, this is the one downside that I see with the documenter tool.

Meaning once the documenter is run and the results page is developed then you are unable to share the documenter results file from computer to the computer because it will not run. The documenter file is made just for the computer that it is made on.


 

Which method is better?

I feel that both using the diagnostic viewer on the RSView Studio software and also the application documenter are most helpful being used in a combination of both. One looks mainly for ActiveX issues and the other is a lot more itemized to give detailed errors.


 

How often should FactoryTalk View HMI system checks be done?

In my opinion, it relies on how often the HMI application is being edited or as a general standpoint every 6 months. If no errors are found then it only takes a few hours to do this work if that.

If problems are found then document them and create a list of what needs to be looked at first and fix one item at a time, I recommend documenting the fixes that you do so you can reference them at a later date and save yourself time.

Fixing HMI application errors is somewhat of a drawn-out topic so if you have any questions then leave me a comment and also visit our Online PLC Support Training Center.

Thank you for reading and if I can help out then please let me know. Leave a comment below if you like this post or if there is any further items that you would like to hear about.

Again thanks,

Shane

FactoryTalk SE ActiveX Files

Let OnlinePLCSupport.com

be Your Secret Weapon to Keeping up with Technology