FactoryTalk View RSLinx Classic or Enterprise?
Let's be clear here guys...
Firstly...
Because you are only starting out here, terminology is important to get right, especially when looking for help here on the Forum...
Padraic said:
...I also have been advised to check that my controller can communicate with factory talk over my serial connection. is there a simple way to test this before I proceed any further?...
The term "FactoryTalk" relates to a whole host of Rockwell software products and tools, either as prerequisites to other Rockwell Software, or as stand-alone applications. The prefix "FactoryTalk" or "FT" is to Rockwell as the prefix "Windows" or "Win" is to Microsoft.
A little introduction to the FactoryTalk world...
FactoryTalk Services Platform (FTSP) is a suite of applications which provide the basic platform for the FactoryTalk environment. FTSP provides a shared or common platform for other applications within other suites to utilize the same software components and services among the many other available software products. (I sound like I'm selling something?).
It can include some or all of the following:
FactoryTalk Services Platform:
_FT Administration Console (FTAC)
_FT Activation Manager (FTAM)
_FT Directory (FTD)
_FT Security (FTS)
_FT Diagnostics (FTD)
_FT Audit (FTA)
_FT Live Data (FTLD)
_FT Alarms and Events (FTAE)
Then there are FactoryTalk application suites for various functions. Each of these will utilize some or all of the above FTSP components:
Asset Management:
_FT AssetCentre (FTAC)
Production Management:
_FT Production Centre (FTPC)
_FT Batch (FTB)
_FT Scheduler (FTS)
Data Management:
_FT Historian SE (FTHSE)
_FT Historian Classic (FTHC)
_FT Transaction Manager (FTTM)
_FT Gateway (FTG)
Performance & Visibility:
_FT Metrics (FTM)
_FT EnergyMetrix (FTEM)
_FT VantagePoint (FTVP)
_FT ViewPoint (FTVP)
_FT View Site Edition (FTVSE)
_FT View Machine Edition (FTME)
_FT Portal (FTP)
Design & Configuration:
_RSLogix 5
_RSLogix 500
_RSLogix 5000
_Studio 5000
_RSLinx Classic
_RSNetWorx for DeviceNet, ControlNet & EtherNet/IP
_Connected Components Workbench
_DriveExecutive
_DriveExplorer
...and so on.
That is not an exhaustive list, but as much as I can recall from memory. They are most of, if not all of, the key software products that Rockwell offers at present. (Yes, definitely sound like a salesman now!)
That leads us on to this...
Secondly...
Padraic said:
...Yes I have to have an operator interface too...
OK, so you intend adding a HMI. If we are to assume this will be an AB HMI, such as a PanelView Plus, then the "Factory Talk" you/they are most likely referring to is FactoryTalk View Studio (FTVS).
FTVS is the application development software for the PanelView Plus family of HMI. FTVS for Machine Edition (ME) is the most commonly used for stand-alone setups between a HMI, referred to as a terminal, and a controller. The OS that is run on standard terminals is called Machine Edition Runtime (MER). FTVS software creates the MER application file that is transferred to and run on the terminal.
While you are developing your application in FTVS, you must set up the communication configuration that will be used between the MER application and the controller, when the MER file is running on the terminal. In FTVS, this will be the working, or "Runtime (Target)" Communication Setup.
Also, while developing your application in FTVS, you can setup a temporary, or development communication setup between your PC that's running FTVS and the controller. In FTVS, this is known as the Design-time, or "Design (Local)" Communication Setup. You can then use this Design-time communications setup to browse for tags or addresses in the controller to assign to your application's objects on display screens, such as buttons and indicators, readouts, etc.
You can then also use this Design-time communications setup to test your application from FTVS i.e. your PC to the controller. You do this by using Test Application in FTVS. The application then loads and runs in a window as if it is running on the terminal itself. This allows you to test and debug your application, all before transferring to the terminal for proper use.
Thirdly...
Just to clear this up...
Lancie1 said:
I think that Factory Talk View requires the RSLinx Gateway version...
Padraic said:
It says RS Linx classic gateway, sounds good.
I'm sorry Lancie, but this is a bit wide of the mark...
FTVS
does not use RSLinx Classic (RSLC) for standard driver based communications between either the PC and the controller, or the terminal and controller. FTVS uses RSLinx Enterprise (RSLE). This is a completely separate communications configuration software to RSLC. On a system which has both RSLC and RSLE installed, there may be some issues with sharing drivers and physical ports, etc., but once configured for sharing they should operate independently.
RSLinx Classic (RSLC) is used to communicate with certain devices, such as your controller, so as to upload/download programs, view device status and configure certain device properties. A more advanced feature set of RSLC is the use of OPC Topics for data exchange between AB and third party devices. Heavy usage of OPC is where RSLC Gateway version would be required. OPC Topics are often used for data aquisition for SCADA systems, or the like. But it's not RSLC we are concerned with here.
RSLinx Enterprise (RSLE) falls under the FT Services Platform (FTSP) suite, namely the FT Live Data (FTLD) and FT Alarms and Events (FTAE) applications. It provides both a Live Data Server and also an Alarms and Events Server. RSLE handles the communication configuration to devices that the Data Server, or Alarms and Events Server poll for information. These devices can include controllers, or distributed I/O. (I'm on a sales commission here, quick, how many do you want?)
RSLE Data Servers also support the use of OPC Topics to these devices. However, RSLinx Classic Gateway is not what is used here. To use OPC Topics with RSLE, you must additionally use FT Gateway.
To be clear...
Other than resources they may indirectly share on a system:
RSLinx Classic is not used with RSLinx Enterprise in any way, shape or form.
They both provide similar functionality, but you would use either/or depending on your application requirements.
Also, RSLinx Classic would only be used with FactoryTalk View Studio when certain features are not available in RSLinx Enterprise such as:
Alias Topic Support
DDE Support
When Complex paths are needed to talk to a controller.
Ethernet to Data Highway Plus
Ethernet to DeviceNet
Specific driver support
RSLinx Classic is the preferred data server for PLC/SLC/MicroLogix platforms.
RSLinx Enterprise is the preferred data server for Logix5000 platforms.
This would suggest that RSLinx Classic should preferrably be used for setting up communications with a MicroLogix, but not when it is to communicate with a PanelView Plus, which will handle all of the communications setup using RSLE.
So...
When you are developing your terminal's application in FTVS, and configuring the Communications Setup for either Design (Local) or Runtime (Target), you are using RSLE, and not RSLC. RSLE is also what is running on the terminal at Runtime to communicate to the controller, albeit in a stripped down version of what you use on your PC. When running on the terminal, it acts as a Data Server, using the communication configuration loaded with the MER application, or set on the terminal menu itself. The Server exchanges data with configured devices, such as your controller.
Lastly,
Padraic said:
...is there a simple way to test this before I proceed any further?...
You have already established a serial communication link between RSLinx Classic and your MicroLogix 1500 controller, which is good. This proves that your PC serial port, your cable, and your controller are all configured and working correctly for the chosen protocol driver, such as DF1 Full Duplex. However, this does not prove that RSLE will successfully communicate with your controller, but you are 75% of the way there.
If currently you do not have FTVS installed, then you most likely do not have RSLE installed, and so cannot test communications between RSLE and your controller. But to be honest, I would not be too concerned at this stage with testing communications between FTVS, RSLE and your controller. Advising you to do this is not a valid prerequisite to aquiring FTVS. In fact, it's contradictory. You cannot test a setup for some "thing" in advance of having said "thing". If you do go down the FTVS path, I have no doubts, you will be just fine with your communications!
Regards,
George