I've created a project using node-red-contrib-modbus(v5.23.3) and node-red-dashboard(v3.1.7). In it there are 7 tabs/subflows in which every subflow has another IP address for modbus data reciver/transmiter but the subflow node is mainly the same on every tab. There are maybe 2 or 3 nodes +/- on each subflow.
Reads what? 1 lot of 100 registers? Or 100 single register reads?
If you count all the nodes in each subflow and multiply that by how many instances you have in your project, what number do you get?
E.g. subflow 1 has 20 nodes and the project has 5 of these === 100
Subflow 2 has 10 nodes and the project has 10 instances=== 100
Subflow 3 has 25 nodes and there is only 1 instance inside subflow 2 === (10 x 25) === 250.
How are the modbus reads triggered? By using a modbus read node that auto polls? Or by input into the subflow? In short, are they all triggered at the same time or are they staggered?
Do you REALLY need to use subflows? Each subfloor instance essentially multiplies the number of nodes internally by the instance count. It may prove to be better suited to the link--call nodes.
One node "Fetch modbus data" has read quantity of 30 and another has 35, so 30 and 35 registers. And that node reads with inject node every 1 second after 0.1 of starting the project(on every subflow). Soo I assume its not staggered ?
1 subflow has 320 nodes(all kind of nodes), and I have 8 subflows. So that is 2560 nodes in total.
I have 8 PLCs and every PLC has its own data, but in same way shown. I don't know how could I implement it differently (Without subflows). I need to copy 1 subflow 8 times and I only need to change the IP of every PLC, and name of the tab in dashboard.
Then subflows are not the right thing to use (not really).
A better layout would be...
Main Flow
steps through a sequence (8 steps) and triggers the 2 READ operations (in series)
the result is then passed to a subroutine (or subflow) for common data processing / data normalisation etc
the result of this subroutine is then used to populate the dashboard items.
This will result in a more PURE solution without all the duplication (much smaller flows, this faster running up on a slow device) AND staggered comms (to avoid any issues with network or IO saturation)