The latest 1.0.4 installer that is there now will install everything you need for LabVIEW 2009 as well. You should not need to do anything special.
The testing of the Ethernet/IP driver worked out real well for our applications (Both for LabVIEW 2009 Windows and LabVIEW 2009 RT). We'd like to deploy our applications using this driver in the future. What risk is there of this driver being dropped and no longer supported by NI?
I am happy to hear about your success so far with the EtherNet/IP driver. Please be sure to leave any kind of comments you may have regarding features, performance, and usability so that we can try to incorporate your suggestions.
I apologize, but I honestly cannot say what will happen in terms of future support. As you can tell, we have actively supported, updated, and improved upon this NI Labs project for quite some time, so it should be fairly evident as to NI's level of commitment to supporting EtherNet/IP within the LabVIEW platform. I do not expect that we would drop EtherNet/IP support anytime in the future. However, it is certainly possible in the future that this component might be rolled into some future module or toolkit, or that its API might change. Keeping in mind though that we have had many customers downloading and using this driver for real-world applications, I would certainly hope that whatever changes might happen we would certainly try to take ease of customer migration into account and ensure that it either maintains direct compatibility or is easy enough to replace with.
Hope this helps,
My only comment for now, is how the Ethernet/IP software is listed in MAX. I like the way the Ethernet/IP software is listed in MAX, under the Realtime Labview PXI software listing. This helps in seeing that the software has been added successfully on the remote target and aids in showing the revision installed. However the Ethernet/IP software is not listed in the same way under the LabVIEW Windows software listing. The only indication that the driver has been added successfully is when you right click change/remove software. And even then it doesn't show the revision that has been installed.
From my understanding of the EtherNetIP VIs that are being discussed here in this thread, this will enable LabView to communicate directly to an EtherNetIP enabled PLC. Is there a set of VIs out there that would allow LabView to access the I/O of EtherNetIP enabled devices? Such as EtherNetIP remote I/O blocks, or EtherNetIP SMC valve banks... This would mean that LabView would be the consumer on the EtherNetIP network, not the producer.
Currently we have an 'adapter' implementation available. The driver can initiate explicit message requests and also be the target of implicit I/O communication. Note that we can still be either a producer or consumer for these I/O assemblies, it is just that the PLC (or any other device which can take on a 'scanner' role) is the one that initiates the I/O connection to the data assemblies.
So one possibility for communicating with remote I/O devices today would be to find out if they support explicit messages. It is very possible you can initiate explicit messages to the Assembly object(s) on the device and read/write to them directly, or they might expose other CIP objects that you can use the Get/Set Attribute VIs to talk to.
If the device is only a simple adapter as well and can't be used via explicit messages, then you'd have to have a system like a RSLogix 5000 that can take on the role of a 'scanner', as currently our driver does not have this capability. However, we are constantly evaluating whether this feature and others would be useful to our customers and so we might add such a capability in the future.
Hope this helps,
That does help, I will have to follow up with the supplier of the I/O device that i am working with to see if the explicit message solution will work. If it makes any difference, I would say that being able to be a 'Scanner' on an EtherNetIP network would be very beneficial in an industrial environment. This would give LabView the ability to communicate to a wide variety of assembly equipment for data gathering.
I would also like to commend the developers and register my hope that NI will continue to support this driver. At LBNL, we've found substantial value in being able to develop LabVIEW applications (both real-time and PC-based) that communicate directly with our PLCs. This driver enables a flexible front-end architecture which can wrap around an existing PLC structure to enrich the HMI. In my opinion it does an excellent job of filling in what has long been a missing link between PLCs and user-friendly top-level interfaces.
I'm using the EthernetIP tools to communicate with a Compact Allen Bradlley PLC.
After some days working everything, the ethernet board from the PLC comes locked. It happens random, so I can't find any rules.
Do you know the EthernetIP can be the reason?
Thank you for supporting these EtherNet/IP drivers. I've spent quite a bit of time reviewing the huge number of posts on this thread from the many users of these drivers.
I've recently started a project that will require our LabVIEW RT code running on a cFP-2020 to talk directly to an AB MicroLogix 1400 Series PLC. Specifically, we'll need to read Binary File (B) values. Unfortunately, the latest version of these drivers don't support this. I also noted a few people have requested this feature on this list (Pg 9, Msgs 83-86), (Pg 14, Msgs 133-134, 137), & (Pg 16, 155-157). I'm in the same boat as Richard Jennings was on Page 9 where it is simply not an option to modify the ladder logic of the PLC to translate Binary File data to Integer File data. The PLC we're communicating with is part of a packaged solution from another industrial vendor. I don't believe modification of their PLC logic is an option.
What is the latest status for getting Binary (B) support for the MicroLogix line of PLCs into this driver set? If this requested feature is slow in coming, I will have to break the bad news to the customer that they'll have to pony-up more $$$ to expand their LabVIEW license to be upgraded to a Dev Suite, add the DSC module, and quite possibly also procure a license of OPC Server.
Hope to hear good news soon. Thanks.