Which driver family are you most interested in?
[poll]
Automation Direct
GE Fanuc
Siemens
Omron
Opto-22
Mitsubishi
BACnet
SIXNET
Wago
[/poll]
We’ve been getting a tremendous amount of feedback on Ignition and our OPC-UA server, and everyone wants to know when driver X will be available. So, we thought we’d put up a poll and see in a (kind of) scientific manner what people are interested in.
Vote for your highest priority driver family, and feel free to post with write-ins and specific models/etc.
Note: MODBUS is not in the poll because it’s already been decided that it will be the next available driver. It should be out in about a month.
David, we are finishing the AB suite. Please understand - we’re getting requests left and right asking when we’ll implement this driver or that driver, so we’re just trying to get an idea of what our roadmap will be.
Just voicing my opinion. I am always going to be demanding and persistent. That’s the thing I like about IA though.You actually listen to the people that use your product. This is a rarity in this day and age.
I guess I wonder what you mean by “Wago”. The Wago Ethernet units (750-841 & 750-842) support Modbus TCP, so do you mean you are going to support the export file you can create that will list the tag names and any user defined datatypes created in the CoDeSys IDE and communicate over the same port that the IDE uses?
Hello there!
I also vote for Siemens. I think, at first, the best will be to implement the RFC1006 over TCP/IP protocol!
There are a lot of converters available to connect then to all other Siemens CPUs (including Profibus, MPI and old S5 stuff with TTY Port).
there is one important player currently missing in the list, and that is Schneider. (www.modicon.com)
Secondly, should it be possible to use a custom protocol for data-transfer between two, of more software components without use of OPC. Simple of the fact that OPC takes a lot of money. This is the idea:
[Rs232/485-apparatus A] <- Communication via Apparatus dependent protocol-> [VB/C#/C++ selfmade OPC server] (let’s say that the manufacturer has given a activeX or the like to communicate with A.) <- OPC -> [Ignition]. The problem here is the cost to use/made a OPC-server.
Better solution could be: [A] <- Apparatus dependent protocol -> [VB/C#/C++ or Java] <- Direct communication -> [ignition]
With Rsview for example. A VB-program can communicate with RSview via COM(+)
Well, Lifetec, I guess the question comes down to what exactly the "cost" of OPC is. You mean that you have to pay for the server? Or join the foundation to get access to sample code? Either way, I would say that the cost of custom developing all of your own connectors will be much more in the long run.
OPC is just an abstraction layer that allows driver people to focus on writing drivers, and people who use data to focus on using it, without getting mired down with device details. Sure we could make an API directly in Ignition, but that API would be serving the exact same purpose as OPC (an abstraction layer), but with some serious drawback: would only work with Ignition, wouldn't have industry support, etc.
And RSView gets it's data from RSLinx, which a VB-program can communicate to with OPC, which is nothing else that a set of interfaces in COM.
Under Siemens it would be interesting to now how many people are using the TI505 line and how many are using the S5/S7 line. I believe the driver is different for the two lines.
And just to nitpick but GE has now divorced from Fanuc and the correct labeling now appears to be GE-IP in big letters and (GE-Fanuc) in little tiny letters to let people know what GE-IP is/was.
After struggling a bit to get it installed (it helps if you download the correct module), I got thing to work okay. One more driver to go, I can start porting over my project in earnest.
I also vote for SNMP (versions v1, v2c and v3). This driver would allow to monitor any network device (switch, computer, printer …) from Ignition. To my knowledge there is currently no Linux SCADA allowing SNMP monitoring. Ignition could be the first one
