LOOP and DONE pins usage

[robertspark]

How does “Loop” and “Done” pins work?

[I know the principle behind them]

What I’m asking is: Is it good practice to use them to sequence how the code / nodes run?

Is there a way a “break” or “return” can be implemented to shortcut to done?

Say I have 10 nodes all in sequence that are checking the range of an analog value to output a boolean true on one of 10 pins should the analog value fall between one oft he 10 ranges, once the one “true” value has been determined there is no point in testing the other nodes as the range has been determined.

Thanks,

[gweimer]

In general, nodes in XOD “fire” any time any of their input pins change. If you are using not-implemented-in-xod, your C++ code can specify to immediately return with no action based on the state of a single pin (ignore other pin changes). That single pin could either be a pulse or a boolean indicating node should be active. The extra pins & code are likely to use more memory, but might save some processing power. I have a feeling that trying to add pulses to simple compares is going to take more processing power than just doing the compares, though…You can’t just stop the pulse when you hit a true, you need to make sure the following nodes get reset (unless your code will ignore “true” on later pins…).

What are you trying to do with the pulse from one of ten pins? There might be a better way to do it…

[robertspark]

Thanks for the info a its given me a little more info to work with.

I should probably be using the not-implemented-in-xod on second thoughts.

basically this element of the project takes two linear potentiometer inputs and for each has defined range to identify where on an X&Y grid a device is.

Its easier to explain this way. … think of it as a piece of paper in landscape, the paper is divided into 5 rows and 7 columns

One linear potentiometer provides feedback as to where vertically the “probe” is, and the other linear potentiometer provides feedback as to where horizontally within the 7 columns the “probe” is as 2 char values which are concat into a cell location A1, A2, D3, etc)

then via switch statements, two multistop linear (pneumatic) acuators guide the “probe” to the desired cell destination, based upon what the current cell location is and what the desired destination cell is, the microcontroller will know which pneumatic actuators to open which should move the “probe” along

[gweimer]

“map” might work better for you. If you can divide the potentiometer readings evenly, you can map 0-1 POT row output to 1-5 and take the “floor” of the output to get an integer. This doesn’t work so well if you have very specific values you want to trigger each grid for… You might have to fudge things (like using 5.9 for max output value, or 0.25-0.75 for start values if POT doesn’t run 0-1, etc.)

This would result in a numeric position for the probe rather than a specific pin set for the current location. You can quickly map the numeric position to a variety of values using nth-input node, but I don’t think you need that for this part of the project.

[robertspark]

Thanks, I started off with the map, but there is no guarentee that the readings will be equal.

here is a bit of code for an not-implemented-in-xod node:

Question>>>> I can get it to output in “1” in byte… but how on earth do I output as a sting (char) value… been trying all sorts this evening…

(I know the output node needs to be a string and not a byte… but I just could not get it to output a char value … I tried “1”… ‘1’ … XString (1) … XString1 … List <1> … (and every other combination I could not figure out…)

struct State {
};

{{ GENERATED_CODE }}

void evaluate(Context ctx) {
    Number inValue = getValue<input_AIn>(ctx);
    Number inLimit1 = getValue<input_Limit1>(ctx);
    Number inLimit2 = getValue<input_Limit2>(ctx);
    Number inLimit3 = getValue<input_Limit3>(ctx);
    Number inLimit4 = getValue<input_Limit4>(ctx);

    if ( inValue <= inLimit1)
    {
        emitValue<output_OUT>(ctx, '1');
        return;
    }
    if ( inValue <= inLimit2 && inValue > inLimit1 )
    {
        emitValue<output_OUT>(ctx, '2');
        return;
    }
    if ( inValue <= inLimit3 && inValue > inLimit2 )
    {
        emitValue<output_OUT>(ctx, '3');
        return;
    }
    if ( inValue <= inLimit4 && inValue > inLimit3 )
    {
        emitValue<output_OUT>(ctx, '4');
        return;
    }
    if ( inValue > inLimit4 )
    {
         emitValue<output_OUT>(ctx, '5');
        return;
    }
}

[gweimer]

They type output will depend on the output-??? Pin you add to the patch with the not-implemented-in-xod node

After first if, you return if value is <= limit1, so there is no reason to check for value > limit1 in second if.