HouseMon Circuits Tutorial 07 introduced the ‘Fanout’ gadget.
This tutorial (08) will incrementally build on that circuit.
$ ./cirget circuit 8 $ ./cirget -y
We have added another ‘Pipe’ (Lines 23-23), and given out ‘FanOut’ 2 pins this time,
.Out:pin1 is as before, taking the ‘FanOut’ output into the ‘Printer’ for display to the screen. But
.Out:pin2 is also taking this same output and sending it into a ‘Pipe’ – so we have 2 ‘Pipe’ gadgets into the same circuit.
Ok, so in this circuit we have 2 ‘Pipe’ gadgets, you may ask “how come the messages from one Pipe don’t get used by the second Pipe?”.
You may think “aha – they are each a separate ‘instance’ of ‘Pipe’ and therefore exist as separate concerns”. This is not ‘technically’ the case within the current flow engine, however you should ‘imagine’ that each ‘Pipe’ gadget within a circuit is independent from each other. They take their own set of feeds and manage their own set of .In and .Out pins.
This MAY NOT be the case with other gadgets. It is wholly practical to have a single ‘instance’ of a gadget in many circuits, or duplicated many times within the same circuit, processing messages in a way that allows the one gadget to see the messages across ALL its instances.
Lets take a fictitious gadget called ‘Nosey’. We could design this gadget to sit in any circuit, multiple times, and to trigger a ‘Rumour’ pin with an outgoing message (on its .Rumour pin) whenever it sees a message passing through it with the keyword “secret” in the message text.
We could even use this as a way to communicate between circuits, but this would be a specialised case.
Just be aware that gadgets should be considered ‘instance’ specific unless the documentation tells you otherwise.
Here is the circuit:
#Read a Text file, output first delayed by 200ms, then sent to FanOut, #fo.Pin1 sent to console line printer. #fo.Pin2 sent to Pipe where its flow is lost --- init: gadgets: - name: "dummy" type: "Pipe" - name: "rft" type: "ReadFileText" - name: "p" type: "Printer" - name: "d" type: "Delay" - name: "fo" type: "FanOut" - name: "pipe" type: "Pipe" wires: - from: "rft.Out" to: "d.In" - from: "d.Out" to: "fo.In" - from: "fo.Out:pin1" to: "p.In" - from: "fo.Out:pin2" to: "pipe.In" feeds: - data: "setup.json" to: "rft.In" - data: "200ms" to: "d.Delay" labels: - external: "In" internal: "dummy.In" - external: "Out" internal: "dummy.Out"
If you run this circuit – you get strange, but wholly explainable output:
The ‘FanOut’ has been told to provide two output pins. The first is wired to our ‘Printer’ and the second to our additional ‘Pipe’ gadget. The Printer prints its output nicely to the console, but the Pipe does not have its .Out pin connected to anything, so its message is ‘lost’, and as lost messages are output to console, its messages are intermingled with those of ‘Printer’.
The important point here is the perceived order of those messages. These last two gadgets should be considered to be running in parallel. Rather like splitting the path of a River into two. One branch continuing on and the other branch abruptly ending in a lake.
Lets see what happens when we play about a little more with these multiple ‘downstream’ branches of messages.
(Appols – I should really use electronics analogies, but I like nature also…)
We will continue with this concept in the next tutorial.