Triconex anyone?

I follow this forum a lot, as I am constantly finding answers to things that have wondered about over the years. A lot of the hardware that is laid out in these posts is the stuff that I have grown up with (or old over!) from GE and AB. What I don't recall seeing is the stuff that is my mauistay now, the Triconex TMR hardware from Invensys.

How about it; anyone out there using this equipment? It is the greatest thing since sliced bread, IMHO. I have a few posts that I have been hesitant to drop here since I haven't seen anyone else posting about it.

Thanks,

Hi,

I was around Tricon for years. The old huge cards/racks/etc. I never did anything with it after I think about V9/10. The new hardware is much smaller.

It was good stuff. Just very expensive. If you did not need TMR, a Tricon is overkill. Triconex were/and are a niche supplier. A good sized niche but, still a niche.

I created one of the first OPC servers for Triconex, using TSAA not MODBUS. It was the first OPC server for TSAA that allowed for redundant connections.

I will add, Triconex support was also top notch. They really knew their hardware/software.

We use it for the mission-critcal drop-dead redundancy/reliability. And yes, their support is second to about none. We do most of our control with UDFB containing structured text. It is really nice to be able to write complex mathematical equations and tuck them into a FB. Try that with ladder logic!

Our biggest challenge is the fact that no HMI out there (we currently use Citect and Cimplicity) has native drivers for the Tricon. We currently are using Matrikon OPC server for Triconex to get get our data into the HMI. Always looking for a better way, but it's just a pain to have to use another software application to connect the two. Does Peak do what I could be looking for? The down side is scapping all our existing HMI to develop another... time and cost.

Thanks,

Hello,

>Does Peak do what I could be looking for?

PeakHMI could support it very easily.

Several years ago we wanted to add TSAA support and discovered that Trident and maybe Tricon (NCM) was not supporting TSAA via TCP only UDP, beyond some version which was already several years old.

We contacted Triconex to get a loaner for testing and they could not/would not come up with one.

At the time we might have been able to get a loaner for V9/10 from another company but that would have been adding TSAA TCP and thought it would not be used so we scrapped the idea.

If we could get a loaner we would add support for TSAA. We do not need the physical hardware. Just an IP address and the ability to read/write data to verify the driver works is all that is required.

We have a driver for it in our OPC Server. Supports the redundant connectivity as well. We do not sell a lot of it because, yes lets face it, for most of our customers it is over kill. We do see it used though and I will say that we rarely if ever get calls on it for communications failures etc.

You have to love it when hardware just works the way it is supposed to.

Still interested in finding out if I could make Peak HMI work as my final solution. We have four large (relatively) sites using the Triconex for control, and tied to a mix of GE Cimplicity or Citect HMI. The only common thread here is that both of these HMIs need the extra layer of an OPC server to talk to the Tricon hardware and translate it to OPC for the HMI to access. Kind of standard, but also kind of a pain, configuration-wise; we took a long time to get the DCOM permissions issues cleaned up, but they are rock-solid now. Also in troubleshooting when you have a system down and you have to look multiple places to see if the communication problem is with the OPC server or the HMI server. An HMI server package with the native drivers for the Tricon would make my life less stressful.

Hello,

Yes you can use PeakHMI if PeakHMI can use MODBUS TCP or serial to access the Tricon.

Contact me at support email if you want to discuss more. I will PM my telephone number.

mbartoli said:

Our biggest challenge is the fact that no HMI out there (we currently use Citect and Cimplicity) has native drivers for the Tricon. We currently are using Matrikon OPC server for Triconex to get get our data into the HMI. Always looking for a better way, but it's just a pain to have to use another software application to connect the two.

Click to expand...

"biggest challenge" and "pain to use" just because of OPC ?
Seriously, it is a huge advantage to base the communication on OPC.
The setup of the OPC Server wont be more difficult than the setup of a native driver in the SCADA application.
You have 3rd party tools for testing the OPC server.
It is the only real standard.
etc. etc.
Going Modbus TCP will be seriously more cumbersome than going over OPC.
With OPC you can address the entire address space of the controller. With Modbus TCP you have to have an intermediary address space.
There must be some other reasons for wanting to change.

mbartoli said:

Also in troubleshooting when you have a system down and you have to look multiple places to see if the communication problem is with the OPC server or the HMI server

Click to expand...

Just have an OPC test client at the ready all the time.

mbartoli said:

we took a long time to get the DCOM permissions issues cleaned up, but they are rock-solid now.

Click to expand...

Does PeakHMI even have such a functionality as DCOM ?
If you want DCOM functionality, it may explain the difficulty issues you are experiencing.
There are alternatives to DCOM for OPC that makes it much easier to handle. edit: Search for "OPC Tunnel".

Oh, I dislike OPC and would rather use a direct driver if available.
Citect has OMFINS for Omron and then FINS but that requires Omron Fins Gateway or Sysmac Gateway which costs a bit. However, FINS Gateway enables me to use Ethernet,Controller Link, serial (slows everything down of course), and the Omron Sysmac Link comms. I can use a mixture of these too - anything I want.
OPC seems (from my experience) to me an unnecessary slow interface in the middle.
Modbus TCP works quite well and is quite quick.
Perhaps I bought the wrong OPC server but it was a leading brand and highly recommended by anyone who uses it - just found it slow. I often have to trend frequency every 10ms or so and the OPC server would not work that fast - Omron Controller Link interface does (fibre optic).
Jesper, a fiend of mine uses Siemens at a hospital - Citect now has 140,000 odd tags. He tells me the driver from South Africa is the best. Have you tried it rather than OPC at all?

Hello,

> The setup of the OPC Server wont be more difficult than the setup of a native driver in the SCADA application.

Hyperbole.

>It is the only real standard.

Hyperbole. DNP, BACNET, TSAA, etc..

>Going Modbus TCP will be seriously more cumbersome than going over OPC.

Hyperbole.

>With OPC you can address the entire address space of the controller. With Modbus TCP you have to have an intermediary address space.

That is not true for Triconex. It uses MODBUS addressing internally.
That is also true for other PLCs.

>Does PeakHMI even have such a functionality as DCOM ?

Of course.

JesperMP, after reading your post again I could not determine if you were using sarcasm or not.

Mark- said:

>It is the only real standard.
Hyperbole. DNP, BACNET, TSAA, etc..

Click to expand...

DNP and BACNET seems to have to do with data transfer between devices. TSAA I have never heard about and I couldnt find anything.
Do any of these have anything to do with datatransfer between applications ?

Mark- said:

>Going Modbus TCP will be seriously more cumbersome than going over OPC.

Hyperbole.

>With OPC you can address the entire address space of the controller. With Modbus TCP you have to have an intermediary address space.

That is not true for Triconex. It uses MODBUS addressing internally.
That is also true for other PLCs.

Click to expand...

I didnt know that. I stand corrected.

Mark- said:

>Does PeakHMI even have such a functionality as DCOM ?

Of course.

Click to expand...

That is good, but where does it say on your own website ?

BobB said:

Jesper, a fiend of mine uses Siemens at a hospital - Citect now has 140,000 odd tags. He tells me the driver from South Africa is the best. Have you tried it rather than OPC at all?

Click to expand...

Since he is a fiend of you, maybe he is not telling the truth

We dont have the need for 100000+ tags, more like 1000-200 tags max. And we do need to be able to integrate with many diverse systems. That is why OPC is the answer for us.

I recognise that there are different situations and needs, and that blanket statements should be avoided.

Hello,

>Do any of these have anything to do with datatransfer between applications ?

What? A Tricon is a “device”. What is this about applications?

>That is good, but where does it say on your own website ?

What? DCOM (Distributed Component Object Model) is a part of the MS Windows OS. PeakHMI can access any DA OPC server via the built in OPC DA client. And PeakHMI has a built in OPC DA server.

You have strayed far from the point of the OP and somehow decided this is you against PeakHMI/MODBUS/other protocols (because really OPC is only and just a protocol)/anyone not liking OPC (the OP)/etc.

The OP wants to interface to a Tricon without OPC because he does not like it. You like OPC. I have not expressed an opinion on OPC.

Mark- said:

Hello,

>Do any of these have anything to do with datatransfer between applications ?

What? A Tricon is a “device”. What is this about applications?

Click to expand...

I may have expressed myself unclearly.
There are standards for data transfer between devices (Profibus, Modbus, etc.. The hardware side so to speak), but that does not have anything to do with how data is transferred to/from and between applications (the software side so to speak).
For the software side OPC DA is the most widespread standard (*).

*: That OPC UA shall enable devices to talk together directly is a different topic, but I mention it here for completeness.

Mark- said:

>That is good, but where does it say on your own website ?

What? DCOM (Distributed Component Object Model) is a part of the MS Windows OS. PeakHMI can access any DA OPC server via the built in OPC DA client. And PeakHMI has a built in OPC DA server.

Click to expand...

The OP wanted to drop OPC and DCOM altogether. And if I am not wrong, the OP considers to use the Peakhmi with a native driver. Then the question is, does he still need a functionality like DCOM, but without DCOM, and can Peakhmi provide that ?

Mark- said:

You have strayed far from the point of the OP and somehow decided this is you against PeakHMI/MODBUS/other protocols (because really OPC is only and just a protocol)/anyone not liking OPC (the OP)/etc.

The OP wants to interface to a Tricon without OPC because he does not like it. You like OPC. I have not expressed an opinion on OPC.

Click to expand...

I dont think I have strayed far from the OPs original post.
He has a working system based on OPC.
DCOM has cost him a lot of pain, and I ask him if that is enough to want to switch from a standardised solution (OPC) to a proprietary solution (Peakhmi native driver). Especially since there are solutions to the problem (OPC Tunnelling instead of DCOM).

It is all just open hearted exchange of experiences, know-how and subjective opinions. No need to get your knickers in a twist.

Hello,

>For the software side OPC DA is the standard (*).

In your opinion. I do not find that to be true. I find more people using a database (Access, MS SQL, MySQL, Oracle, pick one) and SQL to share information between PC/MAC/LINUX/etc. applications than OPC by orders of magnitude.

>Then the question is, does he still need a functionality like DCOM, but without DCOM, and can Peakhmi provide that ?

I am not sure you know what DCOM really is and does, I could be wrong. The OP has stated several times what he wants. An HMI connected to a Tricon without any marshaling of data, i.e. OPC or any program between the two.

PeakHMI or any HMI that is accessing a device via MODBUS TCP will not be using DCOM.

>to a proprietary solution (Peakhmi native driver).

You are so silly. MODBUS TCP is not a “proprietary solution”. You are mixing the HMI(any HMI) and the protocol.

> He has a working system based on OPC.

No, that is inaccurate. He has a working system that uses OPC as an intermediate protocol.

Tricon/TSAA to TSAA/OPC to OPC/HMI

He wants to remove OPC, the intermediate protocol.

Tricon/TSAA/MODBUS to TSAA/MODBUS/HMI.

> No need to get your knickers in a twist.

Because you bring up twisted knickers, I assume you need an untwisting tool.