I read a forum post talking about reading an IO unit to a number table, and then referencing the number table in the strategy to speed up the process. I’m struggling to understand how to practically implement this idea however, and I’m looking for someone to point me in the direction of helpful resources.
Typically, I would assign IO points to varying pointer tables and would reference those pointers in the strategy. We use a lot of FOR loops, and this has proven to be quite efficient. The issue I’m trying to solve is reducing the amount of times the strategy has to poll the IO unit when it comes to cyclical monitoring of input points.
I used the command to read the IO unit into a number table, and tried to assign the individual number table indexes to the different pointer table indexes, but that doesn’t seem to work.
(Ex: ptdiGateOpen[25]=&ntIOStates[156] I need to find some way to accomplish this, as the indexes in the pointer tables have nothing to do with the IO points’ location on the rack.
Does anyone have any recommendations on where I’m going wrong, or where to find information on how to work with IO as table values? Should I be creating a variable for each IO point and assigning those to pointer tables?
There is a bit of indirection involved, spreadsheets are useful to keep it all straight.
//Setup index positions for your points
ntIOIndexPosition[25] = 156;
In your for loops:
value = ntIOStates[ntIOIndexPosition[iterator]];
You probably won’t need pointers for the values that you have in tables. You can do a pointer to a table, but you will still need to keep track of the table index too, since as you found you can’t have a pointer to a specific index.
OK, I think I follow. Basically, instead of creating multiple pointer tables to reference to actual IO points, I’ll create number tables to reference the correct index I want to query from my IOStates table. It sounds like the same concept, just using a different data type.
I assume you are trying to achieve something like this. We designed our software so that users can assign each channel in each module to their desired output control. For example, in the image I shared, users can set the type of output they want to control for each channel.
Let’s take the irrigation valve, which is assigned number 51. Internally, we loop through the table to find where the valve is assigned. Based on this, we reference the output pointer table.
The toutvalveindex holds the irrigation valve number assigned by the user, and the dooutputptr table contains the actual digital output pointer. Accordingly, we activate the valve.
This is part of our fertigation manager software, which only handles digital outputs. In contrast, our other product, Climate Manager, also allows users to assign inputs in a similar manner.