Triconex anyone?

Wow... I leave the thread for the night and come back to find a full-fledged haymaker!

Seriously, as far as what I have working vs. where I would like to go:

I actually have Tricons talking to two different HMI system; GE Cimplicity and Citect. Both HMIs have their good and less than good points, and overall the decision to use one over the other is a toss-up. These were originally integrated in by two different groups at their respective locations before I took responsibility. Both systems are working well, with the common thread beeing that both must use OPC (we use Matrikon) to poll data from the Tricon hardware. That said, we have spent a lot of time honing the DCOM needed to achieve communications across a network between the OPC servers and the HMIs. It is working, and working well; but that did not make it any less of a pain to configure. There are also the licensing costs, not a huge factor, but a factor none the less. As we add, replace or upgrade HMI workstations, updated OS requires a change in configuration of the OPC and DCOM as well as the HMI; just more stuff to do!

Our ultimate goal from a configuration standpoint is to standardize on one package or set of packages. If I can do that by incorporating an HMI that does not require OPC, while still giving me connection reliability in a mission-critical application, I am all for it.

There have been a lot of good discussion points brought out here in the past 12 hours; believe me, I am weighing them all. Thanks to all who have expressed their views!
 
Wow... I leave the thread for the night and come back to find a full-fledged haymaker!

Seriously, as far as what I have working vs. where I would like to go:

I actually have Tricons talking to two different HMI system; GE Cimplicity and Citect. Both HMIs have their good and less than good points, and overall the decision to use one over the other is a toss-up. These were originally integrated in by two different groups at their respective locations before I took responsibility. Both systems are working well, with the common thread beeing that both must use OPC (we use Matrikon) to poll data from the Tricon hardware. That said, we have spent a lot of time honing the DCOM needed to achieve communications across a network between the OPC servers and the HMIs. It is working, and working well; but that did not make it any less of a pain to configure. There are also the licensing costs, not a huge factor, but a factor none the less. As we add, replace or upgrade HMI workstations, updated OS requires a change in configuration of the OPC and DCOM as well as the HMI; just more stuff to do!

Our ultimate goal from a configuration standpoint is to standardize on one package or set of packages. If I can do that by incorporating an HMI that does not require OPC, while still giving me connection reliability in a mission-critical application, I am all for it.

There have been a lot of good discussion points brought out here in the past 12 hours; believe me, I am weighing them all. Thanks to all who have expressed their views!

I'm not sure why replacing or upgrading the HMI Workstations requires changes to the OPC and/or DCOM settings. I realize DCOM can sometimes be a bear to setup, but once it is set, isn't it set?

Back to my real question. I have worked with SCADA type HMIs with both OPC and built-in drivers and I have found OPC to be easier to work with. This is especially true when there are different device types that I am connecting to. I guess I don't understand why you find OPC to be less desirable than a built-in driver.

Also, have you considered setting up a singe OPC Server machine pointing to both Triconex systems and (once you get DCOM set up of course) connecting the two SCADAs to the single OPC Server?
 
I would really like to have answered what Mark is using DCOM for, and if the functionality is still needed.

I am not sure you know what DCOM really is and does, I could be wrong.
Essentially, DCOM in connection with OPC allows OPC clients to access OPC servers that are not on the local machine.
An what can that be used for ? Here are a few reasons I can imagine.
1. To separate a machine/plant network from an office network (which can be achieved in many other ways, but this is one way).
2. To split into a few critical "data gatherers" and many non-critical "data users".
3. To preserve bandwidth on the machine/plant network.

I think the rest of your post are all points where you want to disagree with me. I dont agree with your arguments, but the discussion isnt productive. So I will limit myself to the question at the beginning of this post.
 
If Triconix can use ModbusTCP then why not just uses that to directly communicate with the existing Citect system, or am I missing something?
 
If Triconix can use ModbusTCP then why not just uses that to directly communicate with the existing Citect system, or am I missing something?

Good question... both Cimplicity and Citect can use Modbus TCP, if I am not mistaken. I just never considered communicating directly from an HMI to a PLC with Modbus TCP.
 
I would really like to have answered what Mark is using DCOM for, and if the functionality is still needed.

I am using DCOM strictly to allow the client machines to access OPC data across the network. If I am able to use Modbus TCP, as stated above, both OPC and DCOM go away, as would be the case if I was to use an HMI with a Triconex driver.

Thanks to all for the many ideas presented here. I still have a lot of information to wade through.
 
I am using DCOM strictly to allow the client machines to access OPC data across the network. If I am able to use Modbus TCP, as stated above, both OPC and DCOM go away, as would be the case if I was to use an HMI with a Triconex driver.
How many clients is it ?

If you can make a direct Modbus TCP connection, you could also have made an OPC server conenction at each local client.
I still dont see the reason to use DCOM. If there is a reason, then you must be sure that you can get the same functionality by changing over to a direct Modbus TCP connection.
 
I know this is an older post but I dont see too many regarding Triconex Tricon or Trident. I prefer the Tr1dde driver using modbus TCP. Have used DAServer and MBENet also but Tr1dde works much easier. TR1DDE will "talk" to PLC even if the Comm module is not configured to allow the IP address of the HMI to connect. All HMIs are running Wonderware.
 
Dear,
Please do you have experience on matrikon opc server for triconex I am stuck with this software in the configuration,can you help please
 

Similar Topics

Good Morning Folks, I'm having an issue with a triconex tri-gp. After 24-48 hours of runtime, I lose my SCADA connection to it, which I correct...
Replies
0
Views
1,516
Hello, Does anyone have the Triconex Tristation serial cable pinout? The cable part number is 1600080-0xx.
Replies
0
Views
1,144
I often make modifications on tristation, automatically it will generate new versions sequence of events SOE format and I have to copy and paste...
Replies
6
Views
3,471
Hi All, I am working on a Triconex project (Trident controller) which has a project specific function blocks library. I need to make some changes...
Replies
3
Views
1,844
Hi Friends Please I needs help with Triconex work station -Tristation 1131 , I read manual thy didn't mention for uploading project from Triconex...
Replies
6
Views
2,655
Back
Top Bottom