I understand that the Binary (B) support is very important to you and others as well. While I cannot give any guarantee about when we might have this support, I'll see what we may be able to add in the coming weeks...
If you are only wanting to look at the bools perhaps you could investigate the micrologix web server and use html to pull the values out (this is all purely conjecture, i dont have a micrologix to play with and i am not sure how its web server is implimented) a brief look on ab's micrologix site kinda gives a bit of an indication this migt be possible...also i think the micrologix also has modbus serial, so if your PC, or RT system is close enough perhaps you could just use ugly old modbus (fairly straigtforward,well supported, but painful)...this things could tide you over until the ethernet i/p bools are up and running.
Great job. Compelling technology.
Ethernet/IP driver general question:
How can I use this protocol to raise an event on a change of value instead of looping or polling?
It would be possible to do this (and we might make it available in a future version) but there are a few limitations.
Firstly, I believe the "Generic Ethernet Module" in RSLogix5000 does not support exchanging data on change-of-state rather than a strict timed cycle for exchanging I/O data. So behind the scenes you'd still have data being passed and the CPU has to compare it against the previous to detect the change.
Secondly, I don't really believe LabVIEW events work all that great for typical control applications. They have no way to prioritize execution with respect to other code or events and have no control over queuing of backlog and how to deal with it. It is one thing to use them for UI events or to use for controlling state changes within your application, but as soon as you start trying to use them to process control data is where many people run into problems. If anything, I'd rather have an interface that lets you block waiting for a change up to a maximum timeout rather than rely on events. These allow much better control by the user how things will be prioritized.
Polling into the EtherNet/IP stack was designed to be a very low-cost operation in terms of CPU time. I'd simply poll the assemblies you setup for changes and then if you really want to, fire a user event that another piece of code is waiting on.
Hope this helps,
Logix 5000 connects and goes online.
Ping to IP address works fine.
IP connection string format?
Your path string is likely incorrect. Your screenshot shows 10.84.68.55,0,1. Here's our documentation for that parameter:
The syntax for a simple system is <PLC address>,<backplane port number>,<Logix slot number>. For example, 10.0.0.1,1,0 is the routing path for a ControlLogix 5561 with IP address 10.0.0.1 and with the processor in slot 0 of an AB-1756 4-slot backplane.
Based on your screenshot, I'd guess your path would be 10.84.68.55,1,1 since I think the backplane always starts at 1 rather than 0 and your CPU appears to be in slot 1.
1,1 does work. However .....
I had tried 1,1 before but I think I found the culprit.
The issue appears to be related to program tags and controller tags.
I changed the tag to a controller tag and can now access the tag.
Why is there a difference?
You mentioned documentation.
Is the a tutorial that describes the EIP driver objects, best practices, and common applications?
How to use assembly instances? Advantages and disadvantages.
Is there a performance advantage to assembly instatnces over messaging discrete tags?
My goal is to react to a Boolean tag and then read a UDT.
The UDT is a data type that contains an array of strings and numeric values.
I would need to read the UDT and write new values to it.
Is the UDT accessible with this technique?
You have lots of questions I see... 🙂
Program tags are limited in scope to a single program on the PLC and cannot be accessed from outside of the controller. Controller tags have a global scope on the controller and can be accessed remotely. As to any other differences, you'd have to ask Allen Bradley...
There is unfortunately no tutorial document that covers all you ask for regarding "best practices", etc, but hopefully you can learn a lot from the help file included, the NI Labs page, and the past discussions in this thread. There are other resources online and from AB that describe to some degree the different types of communications.
As for using assemblies, this makes use of the ability of your ControlLogix to do remote I/O using other devices. Essentially you add your LabVIEW system as a module into ControlLogix and then any data in the input and output assemblies is replicated automatically in the background at cycle times down to 1ms. This has many advantages in that your program only interacts with local data in memory so accesses are very fast instead of having to initiate a request to the remote target for every read/write. Each messaging request can take 2-10 milliseconds (or more) to make the round trip from LabVIEW to the PLC and back while with the Class 1 communication of data assemblies the data is always sent every 1ms. The controller also can see the target's online status and can trigger an I/O fault if the device is not there.
The downsides are mainly that you must add the module into your RSLogix configuration and potentially modify your ladder logic to read from the new assembly. Additionally, since we don't have a specific profile besides a generic Ethernet module, your assembly will show up as pretty much just arrays of bytes on both sides and you have to take care to extract the data properly on both ends (though on the LabVIEW side this can be easy with the primitives to flatten/unflatten clusters).
I have an example showing this along with the relevant RSLogix configuration here:
As for reading and writing UDTs, you can use the RAW tag type to access these. However, the formatting of the data can be tricky as AB uses some "interesting" packing rules. You can also potentially just read/write to the different sub-elements within a UDT if you can deal with the performance of doing multiple requests. See my example here that shows how you can use both mechanisms:
The program tags I am interested in use the structure of the UDT.
There are many stations that track data specific to the station.
Each station uses a program tag called current_data that has the structure of the UDT.
Not having access to the program tags is a significant obstacle to the usefulness of the technology.
You mentioned the ability of reading the UDT.
How is this possible?
The UDT is just a structure.
The actual data exists at the program level at each station in the program tag.
Is there a way to create an alias at the controller level that points to the each specific program tag?
This would be a rather indirect way to address the data.