OPC Server data and Epicor - Care to share your experience?

Hey everyone, I’m in the exploratory phase here but have been asked if I would be able to take PLC data from our OPC server, specifically FactoryTalk Linx (Rockwell Automation) and get it into Epicor.

We’re still working out the kinks on what PLC data we want, where we want this data to go [in Epicor], and how we want it to be used once it’s there.

But in the meantime, I’m wondering if anyone’s had general experience with getting OPC server data from PLC’s into Epicor. If you’ve done this, or have looked into it, would you care to share:

  • Did the work require a consultant?
  • Did you need to purchase any modules to enable this ability?
  • Anything else you’d like to share on the experience?

FWIW we are on Epicor 10.2.200.23.

Many thanks!
-ben

@jgiese.wci

@EarlGrei @jgiese.wci tag

We don’t use OPC we are using MODBUS but we have a service we wrote that monitors registers on the PLCs and performs REST calls sending a variety of info to Epicor. All custom logic is handled through updatable BAQ patches. We send machine states, running or not, equipment meter reads to the maintenance module, and start and stop timestamps. We also send cycle speeds every 15 second to an ElasticSearch server. We also use that same service to have Epicor interact with the PLCs. If you’re going to insights check out our REST presentation this will all be in there.

3 Likes

I much preferred MODBUS over OPC. OPC was not super intuitive, but then again, maybe it was me :stuck_out_tongue:

1 Like

I haven’t touched OPC but it looks pretty horrible, we interface directly to the HMI databases and retrieve data from there. (e.g. factory talk).

In most HMI’s you can write data to a database and just interface between that and epicor.

I did have a task using a C# library which talked directly to the PLC’s but i threw that in the bin and my preference is to do as much as possible in the HMI as it’s trivial to trend and read data from my HMI as i have a great .NET connector.

The problem i see that you have is that factory talk is pretty ordinary (i highly dislike it, but that might due to the way it’s been setup on one of my systems).

1 Like

Wow, thanks everyone for your responses! I’ll look into MODBUS Chris and Joshua, thanks for pointing me in that direction. Good to know that REST will work as the method (I was quietly hoping this would be the case).

Pat—I’m in full agreement that FactoryTalk is ordinary. I’ve personally had miserable experiences supporting all of the Allen Bradley software in our environment, but our electrical engineers like it so…

Good thought about interfacing directly to an HMI database. I’ll explore that a bit as well. If others have thoughts, keep them coming!

Thanks again everyone!
-ben

We use this library for ModBus now and for talking to the Allen Bradleys direct on past projects. It works fabulously. PLC driver for Allen-Bradley, Siemens, Modbus & GE

Our situation is a bit different in that we are trying to do this at as low a cost as possible (out of necessity, and fun). Right now for about 3K in per physical machine (multiple sensors, a few lasers, light tower, selonoids, 4" HMI and the PLC). Our intent is to build web based HMI devices from tablets at multiple points on a machine using a mobile app similar to the one we built for maintenance that uses all REST (http://tiny.cc/6cf33y). That is why I built a web service to handle all of the In and Out of the PLC to basically make the PLC RESTful and work with anything instead of the HMI route $$'s.

If any interest we use this brand of sensors mostly http://tiny.cc/bef33y

2 Likes

Awesome, thanks for sharing Joshua! I’ll look into that.
-ben

LOL. I think I’ve been rick-rolled.

2 Likes

1 Like

Too bad you’re so awkward there bud. @jgiese.wci

1 Like