Buffer Hell

So you'd think you would see the signal coming out of this symbol going high when the buffer is enabled, 100% of the time, right?



Guess what? Not so much! Let's digress for a second before we show you what condition just might make "target_signal" never even hiccup in this program.

Look at this symbol:


If you haven't tried this in a 2-series processor, you might not realize that when "button_press" goes high, "target_signal" never does. Here's why - when the 2-series logic processor sees "button_press" go high, it evaluates all the logic immediately connected to it and doesn't return the results until after it is done. (Many will recognize this concept as a "logic wave")

In the process of evaluating this lone buffer symbol, the logic processor sees two results for "target_signal" - the first one where it comes out high from the 1 on input 1 - and the second, where it becomes low from the 0 on input 2. Since the logic processor doesn't return any results until after all the evaluations are done, we (and any other symbols that may have "target_signal" as an input) only ever see "target_signal" as being low.

But I started out saying that you can have a buffer with a single 1-enabled input not propogate a high signal on the enable line to the output, right? How's that happen? Well, what I forgot to tell you is that there's another symbol in this program:



This doesn't look all that different from the previous example, and even though our activitiy is split between two different symbols, the results are the same.

Remember what we said about the logic processor - it evaluates any/every symbol initially triggered by "button_press" going high, and doesn't return the result until it's done. In this case, the single "evaluation event" covers both buffer symbols, and the final evaluation of the state of "target_signal" - in this case the low level derived from the 0 input on the second symbol in the program - is not passed back until the entire evaluation is complete. You could put as many similarly configured buffers you want (or a single buffer symbol with multiple inputs like the first example) and arrange the high and low level input values however you want - the end result is that the last evaluation, based on the order of signals/symbols in the program, is the result returned by the logic processor and passed on to the next logic or device symbol.

At this point some of you are probably saying "Well, duh, that makes sense" or "yeah, I knew that", but this is really for the rest - the ones that someday might stare at a 1-enabled buffer in SIMPL Windows and can't figure for their lives why the output isn't going high when they trigger the enable while watching for the results in Test Manager/SIMPL Debugger. If/when that day comes, remember to F2 that signal and look to see if it happens to be coming from a buffer further down in the program tree from the one you're currently looking at. You'll probably find that buffer is keeping that signal level low.

One last note - this little tidbit applies to 2-series processors only. If you happen to come across this while working with an X-series or earlier processor, you have a different problem. The logic processor in pre-2-series controllers will actually propogate the signal value to other symbols each/any time it changes while being processed.