OPC-UA Drivers

Is there a time-table to implement OPC-UA drivers?

I only use Koyo/Automation Direct PLC’s currently.

When will the development program be open? I would love to help out.

We will be publishing a driver road map soon. There will also be a poll on the forums here where we will try to figure out what drivers everybody wants and prioritize our development, so stay tuned.

Thanks, I will wait to see what happens. I will need some more drivers to be available before I will be able to purchase.

I know there’s an AD Productivity 3000 coming up soon. When the poll goes up please let us know which AD/Koyo PLCs you are using.

Will do. Thanks.

Currently DL06 & DL205. Also I have devices that are polled for data via HTTP.

In the future, we also would like to help beta test an AD PLC driver. We use 05,06,250 and 450 and will be moving to the PAC 3000 shortly.

Nice job on the new product.

I just want to remind viewers that they can also use any other OPC server that has drivers for these devices with Ignition. Kepware, Matrikon, etc. are all good choices. Their OPC-UA offerings should be coming out soon (I encourage you to call them and inquire about the timeline), but their current offerings should work well through the OPC-COM module.

You may have already been aware of this and made your decision accordingly, but I just don’t want people to think that our drivers are the only way to communicate with devices.

Regards,

Thanks for the info. I am trying with Kepware. I just can’t wait until I can do everything in your software and on linux, not Win!

Haha, Hey IA guys does he sounds like someone else??^^

Haha, yeah. With so many requests coming in, I sometimes forget the pure linux people… and how we basically really are the only choice. I guess that was kinda the plan, but it sure puts a lot of pressure on us to write drivers!

At any rate, we’ve enjoyed seeing what people are asking for in terms of drivers. Getting a lot of modbus, which will be the next one done and out in under a month or so, but beyond that it’s kind of across the board.

Is there any news regarding modbus server release?

The modbus-tcp driver is currently being beta-tested by a few customers. If you’d like to help us test it out, send an email to support@inductiveautomation.com.

we expect modbus rtu! :smiley:

We don’t have any active plans to write serial drivers in the near term. You can use a 3rd party OPC server like Kepware if you need serial connectivity.

I think the modbus driver will route through a ethernet to serial bridge, as modbus tcp is just modbus rtu encapsulated in a tcp header… I believe.

Yeah, I’m not sure off the top of my head if it will work through a serial-to-ethernet converter. If not, that is something we’ll likely be able to address in the near future.

Kyle Chase:

Modbus RTU and TCP use different frames and error handling mechanism. I am not sure, but as i know the simple RS/TCP converter will not work.

Carl.Gould:

It would be very nice to develop the Modbus RTU, because many industrial controllers have (in more cases) RS port… some models also have TCP port, but doesn’t support the modbus tcp (((

Im pretty sure the modbus driver will be able to use something like a Digi IAP, which does the protocol conversion. The client side driver still needs to support routing though

Hello,

The functionality you are talking is much needed.

Could you implement it as enable/disable feature that will add the modbus MBAP header and error check in the payload of the modbus/tcp driver.

This will turn it to “Modbus over TCP” (Modbus RTU over TCP) and will enable pure serial to ethernet converters to serv a lot of modbus rtu devices easily.

This will extend the standard modbus/tcp driver you have developed to “Modbus over TCP”

It will be much painless to include option for this in the current driver against developing another driver or using a lot of pricey modbus/tcp gateways - especially for simple devices without requirement for multiple modbus master access.