Note: Deprecated!
Debugging time!!! (when isn’t it.) I sort of forgot about this one, until a couple of days ago, when I ran into a similar problem as for which I originally created this (ahem) simple little trick. To explain you what attached neurons are for, perhaps first a little explanation on how I have been designing my neural algorithms. (Caution: this is advanced stuff, not for the faint-hearted).
As with all algorithms, I take some input and process it to generate some output. The input with neural algorithms, is always expressed using neurons. The process to execute is defined through the meaning of a link (which also maps to a neuron). The link starts from the input neuron and usually points to some value that needs to be compared against or searched for,…, but this can also be something else.
The problem is the ‘split’ instruction. This is a very powerful thing indeed, which allows me to write simple, massively parallel code. It does, exactly as the word says, it ‘splits’ the current process into x nr of similar processes. They are similar, but not exactly the same: ‘the input neurons’ have been duplicated so that they contain the same values, but using new neurons, so that the process will eventually lead to a different result neuron. Also, the ‘variable’ that was supplied with the split instruction, has a unique value in each process (the value items are declared in the split instruction, they determine the nr of new processes in the split). And finally, globals can be declared as having to ‘duplicate’ their content when a split occurs. All this means that each process is similar (most variables point to the same neurons), but not exactly the same. (Mount Everest stuff, I know.)
The key thing to keep in mind here are the duplicated input neurons: when a split occurs, the idea is that each process will work on it’s own input and result data. But, sometimes, for various reasons, one or more of these neurons can spill over to other processes. And that’s when ‘contamination’ can occur, or when one process modifies the input/result of an other process, which is very bad indeed and excruciatingly difficult to trace using traditional debugging methods like breakpoints.
Thus come attached variables to the rescue. The idea is very simple: Whenever a ‘variable’ that has been signaled in the designer as ‘attach required’, gets it’s first value assigned, it attaches this ‘value’ to the process in which this assignment occurred. If, from that point on, another process tries to change this value-neuron, all alarms go off as if it were WOIII. And that’s basically it. From there on, it’s up to you to use the 
presented information (where and who), to figure out the why.
For practical use, I have found that the ‘CurrentFrom’ system variable, really is the most useful variable for this trick, though it is possible to put it on any other. You can even attach neurons manually to a process, if you’ve paused and selected one. This is done on a code editor, using the context menu item ‘attach to processor’. To activate the monitoring of a variable, make certain that it is added to the left most pane in the debugger view and select checkbox in the ‘attach’ column before you provide the network with some input.
Like I’ve already mentioned, it doesn’t take much to use and activate it. This little trick’s usage field isn’t very broad, it only traces down 1 specific type of bug, but one that is very hard to find otherwise. Also, if not used correctly, you can get a lot of false errors, since it’s very common for multiple processes to modify the same neurons. So use with caution!