I'm relatively new to the LabView world, and I am working on a project automating an industrial process using a cRio as a PLC. Because we plan to only use LabView & the cRio for prototyping, I have chosen to go with sensors and actuators that are controllable via Modbus TCP. I began playing with the shared variable engine as a way to access my Modbus slaves, which seems to work fine, but I remembered from a discussion with a colleague that DCAF exists and started to look into it. I watched the into webinar today, and it seems like while it could be overkill for our system (3 actuators with simple PID control, and about 10 sensors), it would make the more tedious parts of developing such a system much easier for me.
Today I began a new project with the DCAF configurator, and I started configuring the Modbus module offered with the system. I realized that I can only use single variable types (no arrays) for my access values. This is an issue for me since one of my slaves requires data access to certain sets of registers in order, starting with a certain valid start address. In the shared variable engine, I just used the array access to get the data I need since it starts at the correct address.
Is there a way to configure DCAF to use similar access? I thought I might be able to combine each individual register tag into a new tag that has an array type of the same variable type (U16), but I am not seeing a way to do that. Am I stuck with the shared variable engine with the scan engine behind it? It feels like if I go that way, DCAF doesn't really provide me a whole lot of benefit.
Any help or guidance is appreciated!
You are correct that the module currently only supports scalar tags. It looks like there is an open issue to address this but it's been open for a while without any activity so we should probably look into this again.
If you wanted to to do this in DCAF you could either fork the module repository to add this functionality (if it was implemented well I can't think of why we wouldn't want to merge back) or you could potentially create a static module to pack the individual tags into an array.
On a side note, if you choose to move forward not using DCAF, I would highly recommend downloading the NI Modbus Library from VI Package Manager and using the API it installs under Data Communications > Modbus Library (NOT Data Communications > Modbus) instead of the Modbus I/O Servers. This might seem like more work at first but if anything happens to go wrong or not work, the I/O Servers tend to be much more difficult to troubleshoot where as the Modbus API is all LabVIEW code so you can troubleshoot normally. I would look for other people's opinions if you want to go down the Non-DCAF route but, personally, being able to more easily troubleshoot any Modbus issues that come up outweighs the additional upfront development cost.
Thanks for the prompt reply, and for confirming what I suspected. I think due to the schedule and relative simplicity of this project I will forego the DCAF framework. It's been a good experience looking into it however, and I may use it in the future when I have more time to dedicate to the development of a system.
I'll look into using the Modbus library you linked to - I think its the same one I used for a past project. I had a feeling the SVE would be trouble with the number of devices I need to access over the link, but it was nice to get some initial communication working with it to prove out my approach.
I have nearly finished my project without using DCAF, and I am once again investigating having array access support for the framework so I may use it in the future. I started digging into the code a bit and I realized that there may be implicit support for the kind of access I need. I wanted to share my findings and confirm with you all since you spend a lot more time around the framework than I do!
First, some background on my issue: I have some Modbus slave devices (IFM AL1342 IO-Link to Modbus TCP gateways) that require sets of registers to be accessed sequentially, starting from a specific address. For example, it packs all the data of a specific type for all ports on the device into a single array of a fixed number of words. If I wanted to access the data from port 3, I am required to read the full array and post-process to get the desired data rather than explicitly issuing a read for the subset of registers in the array pertaining to port 3. Given that, I was hoping I could create a tag of type U16 array and supply it to the Modbus configurator along with the start address and length I needed. As you have confirmed, this is not possible with the framework as-is.
After looking around the Modbus module downloaded from the Github repo, I found that the Modbus system appears to optimize register access by default by grouping adjacent addresses together into a single read or write operation (for reference I am looking at form clumps.vi, clump to runtime maps.vi, modbus input.vi, and modbus output.vi from Modbus Module Runtime.lvclass).
I don't see any reason why this process wouldn't be deterministic as long as the register map is configured correctly in the DACF editor, which is pretty much my only requirement. Am I missing anything in my understanding of the system? Thanks everyone!
Hi dkouba, you are correct the process it could be possible to add array support to the DCAF Modbus module, and as Matt mentioned it is an open issue, but we have not been able to work on it.
In this case the complexity of implementing it is not really on the run-time but on the editor, as we would if you are not careful when adding the array s you could overlap registries. and basically the complex part would be to make sure this is not happening.
Right now we are working on other parts of DCAF and this change is not in the priority of things that will be implemented soon, as there is also a workaround.
If you have the data in a module as an array, you can create a simple module that converts arrays to scalars and use this to write it to Modbus. Now with your specif device I don't know it this will work as expected.
Now the other option if you cant wait for us to work on this, and that is the great thing of open source is that you could make the changes directly to the module and submit it. https://forums.ni.com/t5/Distributed-Control-Automation/Collaborating-on-the-Development-of-DCAF/gpm...
I also added this threat to the issue (https://github.com/LabVIEW-DCAF/ModbusModules/issues/21) we know there are more people requesting it.
Thanks for the reply. It makes sense knowing now how the runtime operates on sequential Modbus addresses to make the changes in the editor.
Totally understand about it being low priority right now - I will be back to ask more questions if I decide to start implementing a solution!