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.
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 *
Here the following happens, in a node this is going to be low, but the DONE pulse puts it high in the next LED node, prevails 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.
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!
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.
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.