Reasonable. Do you think the node should have a STEP parameter? In any case, even if the STEP is hard-coded to 1, what should happen if the lower limit is -1.5 and the upper limit is +1.5. The current value is 1, we pulse on INC… what the output value should be after that?
Yes, please. A STEP-parameter. Of course. I forgot to mention.
There is always a 74192 BCD-counter in my head…
My target is to count from 0 up to 1 in 0.001 steps.
But, it offends my sense of efficiency, because all the nodes will fire for each calculation (no short-circuiting). Is it good enough for you purposes?
Added awg/logical/string-compare to my library of nodes. Compares 2 strings, has 3 outputs: less, eq, greater. Only one output will go true. Recalculates if any input changes. https://github.com/awgrover/xod_lib
This likely doesn’t work all the time. It looks like the strings in XOD may have some bugs, but maybe the bug only happens when you “concatenate” strings.
Hello awgrover,
thanks for the new nodes! I have tested if-else-string an it works fine. digital–input is not tested yet, because it is late and my soldering iron is far away. At this time hardware has pull-ups.
Yes, test-if-in-range can be done by standard nodes. Did this patch use more memory than a standard node from the library?
I don’t understand. Do you mean by “standard node” something build in c++ rather than built out of other nodes? Then, yes, it uses a lot more memory, and is a lot slower.
Some nodes come with XOD IDE by default (in the folder xod/ in the menu on the left). I think more memory is used when I create a new patch made with these standard nodes from the menu instead of using a node from this menu which is “ready to use”. Even if the have absolutely the same function.
Patch nodes are created in XOD itself by composing existing nodes (no matter which ones). The test-if-in-range by @awgrover is a patch node.
Native nodes are implemented in C++ from scratch and, yes, they’re more resource-efficient than patch nodes because they skip cross-node communication overhead. Although it’s likely always would be a penalty for patch nodes, we strive to make the difference as low as possible. @awgrover have native nodes in his library as well.
The second dimension: Standard vs Community nodes
Nodes are done by users. It doesn’t matter whereas they are native or patch nodes, they belong to someone. The standard nodes are simply nodes by the user xod. It doesn’t affect efficiency anyhow.
BTW. Node requests are very reasonable. We’ll do it. For now, you can do what you need by yourself or use other’s nodes.
Added to my libs in github as awg/count/limited-counter.
Counts up or down depending on STEP
Never exceeds MIN or MAX
Can change MIN/MAX/STEP at any time.
Counts up/down only on INC
Only outputs if the OUT actually changes. E.g. you can set the STEP to 0, and you’ll not see any OUT because OUT doesn’t change.
but, if you change MIN, and OUT is currently less than that, you’ll see output. E.g. if OUT is at 10, and you set MIN to 20. OUT will change to 20.
The behavior is a bit complicated in the details:
Starting with MIN as the first OUT value
STEP is positive
RST must have a pulse on the first transaction (or rather, with the first INC). Otherwise, INC will add STEP and you won’t see MIN.
So, RST is set as “on boot” as default. And RST inhibits INC. You could also ensure that RST receives a pulse at the same time or before the first INC pulse (e.g. both on the same initial pulse).
This seems like a hack.
Starting with MAX as the first value:
same as above, except STEP is negative
RST will reset you to MIN or MAX depending on STEP. If you are counting up (STEP is positive), you reset to MIN. Counting down, you reset to MAX
The last value of OUT may not be a complete STEP. E.g.
OUT is 18
STEP is 3
MAX is 20
The next INC will make OUT = 20. Because we never exceed MAX. That’s only +2, not +3.
Rounding accumulates
I set the defaults of this node to count from 0…1 in 255 steps. This was to make it instantly usable with a PWM LED (the LED node).
But converting to 0…255 by *255 and rounding makes the last 2 values 253.99944120 and 254.99943900. But, those are supposed to be 254 and 255.
I ended up tweaking the step to 0.00392157, so that conversion to integer would give 254, 255, etc.
Yes, I made a few tests in the last days (cascading if-else and if-else-string nodes). I have some problems after uploading and debugging my project. I didn’t get an error message but debugging hangs and arduino will not work. Don’t know why. The project has lots of patch-nodes and after removing one third of the nodes the rest works fine. It takes also a lot of time until the upload screen (green timeline) appears. After removing some nodes upload starts faster. Perhaps my patch-nodes need too much of the resources? Because the project is in an early stage and im still plaing around, I will not upload it. Perhaps I will not need all the functions I have implemented yet. I have to think about it first.
The whole thing reads the analog output of a HEITRONICS Infrared Thermometer. The value is send to the LCD. You can set the temperature range and the output from 0 - 20 mA to 4 - 20 mA. Perhaps there will be a more comfortable menu control (with incremental decoder?) in future and some more features (0 - 1 V / 0 - 10 V input, min. / max. Alarm, more acurate measurement with activated external reference voltage, over / underflow alarms, stored menu settings, temperature logging, ambient temperature and humidity readings… )