I made a simple patch to blink LED13. I called the patch twice in succession. The first time it blinks. The second time it blinks MUCH brighter. I don’t understand why.
Here is my “blink controller”:
Here is my main patch:
Why does the brightness change on the second call to the cntrl patch?
that happens because the two nodes use the same port (D13), then when the first one is high the second is low
then the node is already high and remains high
cesars, I would agree, but the LED is being driven by the delay node. When the delay ends, ACT goes false and the LED goes out. So, when the second control is called, LED13 should be off.
It would not be working like that, because the second node is the high state
there is no low state between a delay and another delay, therefore it is high and immediately returns to high
here an example
Hmm, interesting. I see. When I added a flip-flop to drive the pin low it did stop getting brighter. BUT …
Now, why am I not getting a 1 second pause between “blips” for my new, modified, cntrl patch? (It just stays on for 6 seconds instead of two 3 second blips with a second pause in between):
continue using D13 for two nodes simultaneously, that is not correct.
the only way would be to create a custom type if-else (port) and deactivate the port with 255
Now this does not make much sense, I do not know what he wants to do.
With a single led node can do everything, you can use node or xor and nand
cesars, thank you for your input.
I am new to XOD and just experimenting with it trying to put together simple circuits to see if I get expected results. I find that generally I DO NOT get expected results. Though I am not a professional programmer, I have programmed in many of the higher level languages (Visual Basic, Ruby, Python, some C++ and a little Assembler), and I have experimented with hardware circuits quite a bit as a hobby (to the point of building a functioning z-80 based micro-computer). I would like to use a “block based” or “visual” programming language to get away from the tedium of programming. But, I’m finding that the visual languages are either quite limited in capabilities or not especially intuitive.
I am putting XOD in the latter category. It seems quite powerful BUT I think it is a little misleading in the user interface because processes are constructed AS IF they were sequential, when, in fact, they apparently all occur simultaneously (in parallel). This is highlighted by your comment that you cannot “[use] D13 for two nodes simultaneously”. Of course, they do not APPEAR to be used simultaneously in the main patch. So far as the appearance of the main patch is concerned, it all LOOKS very sequential. But, apparently it is not. My intent was that each node be called sequentially, not in parallel. But sequential execution seems far more difficult than it should be.
I’ve experimented with Node Red before and it does appear to run sequentially, at least for the relatively simple projects that I made with it.
I wonder why XOD is designed so that a simple patch like mine does not work, but the rather complex “custom if-else” does - all because I cannot sequentially manipulate the same device from a sequence of nodes in my program. I am sure there are important design considerations that led to that, but I don’t know what those would be.
As you can tell, I’m not finding XOD particularly intuitive and am having a bit of a struggle with it.
please excuse my rant … 
you just have to experiment a little more and you will see that it is simpler than it seems
It is sequential down, but see the patch as a whole, where everything happens at the same time, you with the pulses can go giving the direction. That’s why, just as the delays exist even though they are not active, ports like D13 are already being used, and they can not be high and low at the same time.
In your patch D13 this low <> low, then high <> low (low brightness) and then it would be low <> high *
The example works because when one node uses D13 in another it is in D255, then inverted. But here you do not see the change because there is no shutdown delay, it will pass from high> high
you can practice in this way without loading it into arduino, then you can load and go trying with the ports, led sensors, buttons
ps: Maybe it will help you more, if you raise what you want to do, and I or someone else will give you the examples
Having multiple copies of objects that control the same pin can be a problem as cesars noted. In this case, the LED node should only fire when an input pin changes, so it SHOULD not be a problem having multiple copies as long as only one changes at a time. The tweak/watch nodes may be causing the patch to “fire” when you do not expect it to, which could be a problem. Your patch also has 2 copies of the node, trying to use the tweak probably creates a 3rd copy, which is going to cause issues if you try to tweak while the loop is in progress updating the other 2 copies.
Another thing that might be an issue, you don’t have a defer node before the DONE output pin, so the LED node may not finish its transition to off before pulsing the DONE pin. There is also no delay between the CNTRL nodes, so it should not be off long enough to notice that it blinked.
yes this happened to me, the two led nodes are in “loop”
From the clarification of gweimer, I realized that I had omitted something important.
Here is an example, using two nodes with the same port
test-led-port.xodball (7.5 KB)
cesars and gweimer, thank you again for your assistance. Since I was “ranting” earlier, I thought I would report a success. I’ve successfully programmed my Elegoo “smart car” to check the distance of any object in front of it. If nothing is within 20 inches, it moves forward. If something is within 20 inches, it rotates away (to the right). It repeatedly checks for objects and reacts continuously. Considering how much trouble I was having with a blinking light, I did not think I would be able to do anything this complex - but low probability events do indeed happen on occasion! 
Here is the main patch:
Of course it runs into many things, but that is to be expected. I can work on making it a little more discerning.
Oops, sorry for being late to the party 
If someone misses the point, the difference in the brightness on the original patch is related to the UPD pin. Since they both bound to “Continuously”, the led gets continuously updated every single transaction from two different (conflicting) sources. When the sources are False/False it is off, when they are False/True you effectively apply software PWM to enable at half-brightness, True/True leads to full on.
Agree. We’ll try to resolve the mess with conflicting updates to some extent in 0.31.0. So that the patch you presented will work as you expect.
The idea which crystallized just recently is that idempotent actuators (like LED brightness, LCD text, motor speed) should be controlled by a boolean ACT pin rather than the current UPD pulses. In the former case, the actual hardware interaction will happen only when necessary. That is when the value (brightness in case of LED) has changed and thus should be reflected in the real world.
C’mon, come back later this summer! 
Switching LED and similar nodes from UPD to EN sounds like a great idea. I’ve seen several users (including myself) get burned when we forget to send an extra pulse to set final value before leaving a patch, and EN would be a lot easier to code in these cases.
