No problem. Thanks for the praise and I am sure that post will help some other people as they stumble upon it.
The FB itself uses little power as you found, but each output port can give off 500mA (12v x 0.5A = 6W) by itself to power a relay which pretty much covers all automotive and standard relays directly. If the relay doesnt use as much power, it doesnt send out as much power obviously.
The "echos" are normal too as you found. Once you actually hook up another sensor to it, it wont be floating around anymore and will be just as accurate. Or if it bothers you or is for a demonstration or something, you can jumper the sense to ground which will stop it from floating and is the same as attaching a sensor that isnt outputting anything.
USB is a quirky standard, and the big EM disruption from the solenoid is definately enough to overpower the weak signals and turn those 0's to 1's screwing it all up. Good rule of thumb is never put signal cables by big interferance or power lines.
Programmer to programmer, I rarely use the configurator for logic. It took me a bit to come up with that, but it is geared towards the newcomer who doesnt know much. If you look in the XML file, you will see each logic section gets its own <if> block. Then the way to look at it is every time you do an operation, you do it on the second part of the level. And it evaluates the whole thing starting from the top level <if> all the way through recursively.
Here is me trying to explain it a little more so hopefully it makes sense. If you understand it, then I will make it its own tutorial and add more to it later.
So 01 opens up the block. It tells the program there is a statement I need to evaluate. That is all the "if" part does. It looks at its attributes. The "fire_on" attribute signals to it when to evaluate it. The program has 4 timers. 2 for USB communication (input and output), 1 for graphics (gui) and the other is the logic timer. You can make the fire_on part any of those 4 timers, and there are times when you want a section to evaluate as it draws the screen, sometimes right before it send out a command to the brain and so on since all these timers fire at user settable intervals. The other interval in the root node is "minimum_delta_vote_time". The number is is milliseconds, and it means if this expression evaluates to true, it can only vote (evaluate its "then" part which is empty here between lines 10 and 11) if more than 100mS have passed since it last voted.
01 <if fire_on="logic" minimum_delta_vote_time="100">
02 <boolean_operation type="greater than">
So if the program is to evaluate this block in this timer, it reads line 02. It is a boolean operation and will be doing a "greater than" comparison of 2 numbers. So it must see if parameter 1 is greater than parameter 2. So it looks for parameter 1. It is on line 03, but I could have switched it with line 06, and the program will seek out the node, so it is foolproof that way.
So it gets to parameter1 on line 03 and evaluates everything between 03 and its closing tags on line 05. There could be 100 lines of code in there, and it will recursively go down and evaluate them and feed the results back up until there is a single expression there. Luckily in this one, it is just the number "5". Once it gets its single value of "5", it searches out parameter2. It is also a simple node and just the number "7".
Now that the boolean operation has parameter1 and parameter2, all it does is
So it will get a true or a false back from that. Obviously a false because 5 is not greater than 7. Since that is the top of the expresion nodes, the whole block of code is now resolved as "false". So it will skip over the "then" blocks on 10 and 11.
"return (parameter1 > parameter2);"
If the code was like this:
You notice the only changes are that now the "greater than" boolean operation between lines 04 and 11 is surrounded by a "not" operation between lines 02 and 13, and there is something to do in the "then" section between lines 14 and 16.
01 <if fire_on="logic" minimum_delta_vote_time="100">
02 <boolean_operation type="not">
04 <boolean_operation type="greater than">
15 <do function="Change Timer" functionTargetID="Output" vote_opinion="+5" vote_priority="Medium"></do>
So the program will get to the if node (line 01) and check the timers just like before. If it is the logic timer, it will start to evaluate.
Line 02 says there is a boolean operation. A NOT operation only needs 1 parameter, so it then looks for parameter1, and finds it on line 03. So it evaluates everything between line 03 and 12 and gets the simplified expression of "false" back as we already concluded in the first part of the example since 5 is not greater than 7.
So now the program returns the opposite of parameter1 back up the chain. So since parameter1 evaluated to false, the whole block will evaluate to "not false" or "true". Since that is the whole logic part of this <if> block, the whole block evaluates to true.
Since it is true, it gets to look in the "then" section between lines 14 and 16. There can be as many <do> statements as you want. There is only 1 in this example on line 15. The <do> block has the exact same syntax as all other voting areas to change pages, send emails, play sounds, trigger an output, anything. It is all done with that syntax. The current do statement says to change the timer interval of the output timer to 5 milliseconds more than it is now and it has medium priority when voting. So it does that and registers its vote. Since there are no more <do>'s to evaluate, it is done and moves to the next "<if>" block somewhere else and if no more, then just returns to what it was doing before.
So that was how the program works under the hood basically. And it does it for every if/then node and does it every 50 milliseconds or so usually.
If you have any other questions, just let me know.