Switch case question / lost in terminology

how can i get the switch case node to defer to the current value instead of 0? i want to use as a simple motor control but always goes right back to 0 instead of keeping speed at set amount until i change it. how do i hold this value ? so many node names and the terms in the descriptions are still not familiar to me. i waste a lot of time trying to get some node to do what it is not intended to do. please help
thank you.

I don’t understand the question. As long as the switch-case-IN value doesn’t change, the output value is not going to change. If it is defaulting back to 0, it is because you are changing the input value to something that doesn’t match any of the X# values. You will either need to quit sending it invalid input, or use a unique value for DEF that can be ignored on the output side (currently DEF & Y10 are the same).

I’m also somewhat confused, but I think something like that could work as long as the income is 0.

maybe it will give you an idea of how to implement it.

it may be better to use select instead of sw-case

Nth-input might make sense since consecutive X# values are being used. Generating pulses to use select is going to require compare nodes for each select pulse input pin, which hardly seems simple than what they currently have…

If I did not misunderstand, what he wants is a memory of last value. And I think the input is random, it does not seem viable nth-input, but it not is clear what the input of the selector value is.

Yeah. That is why I suggested a default that didn’t match any other output value. If output is default, then ignore it (either by disabling gate like your example above, or not updating buffer).

I understand, also something that makes sw-case more versatile is that not only can the numeric value be the selector, it could be string or byte, so in that case nth-input can work better but only in the second selector, not so in the first of the initial example. (for the values ​​entered in X)

Thank you all so much for your responses.
The source of the input is an IR-Remote. An example sequence is as follows:

  1. Motor A is brought to 70% duty cycle, (button 7)
    Amperage is confirmed (Fluke), and RPM is recorded to log. motor remains at 70% duty cycle.
  2. Energize Solenoid A, (button >>I).
    Confirm pressure at manifold (gauges) and record to log
    Confirm pressure at transducer 1, record to log, record deviation. (hold in energized state)
  3. Open Metering Valve at 50% duty cycle for 10 seconds then bring to stop(>II button)
    Confirm data acquisition of max Delta P from pressure transducers, (peak Delta P stored Value), in log.
    Confirm data acquisition min/max from Amp meter and tachometer, (min/max stored values), Record in log.
  4. De-energize Solenoid A (I<< button)
  5. When pressure at manifold is confirmed at 0 psi, return motor A to 0% duty cycle (button 0).
  6. Confirm all log entries and then reset transducer, RPM, and Amperage peak values (button EQ)

This is just an example as the true sequence is still being worked out. but the ease of controlling the whole thing with a little remote seems like a good idea to us. So we thought we would set it up with a switch case node for each actuator in the system. Some actuators would have a pre-planned start and stop but others would remain in whatever state we put them in until we change the state. We are fluid dynamic engineers and we want to stay away from expensive AB or Siemens PLC’s for simple experiments like this. If we can learn our way through some of these xod nodes then we can achieve results without the controls expenses we have had to have in the past. when an idea looks promising we can then begin to employ industrial level controls to finish the task.

I hope that my new explanation above will shed some light on what we are trying to do. By no means are we stuck on using the switch case nodes. If there is a simpler idea then we would be glad to use it. We are not familiar with many of the terms used in describing the various nodes. I for example spent several hours learning how to make a “false positive eliminator node” only to realize later that what i needed was a “debounce node”. This is OK to some extent, as learning takes time and research but not trying to make a new career out of xod, only want to learn as needed.
I have gotten many good ideas and lessons from this forum and i do thank you all.

Just FYI: it may have had a lot to do with the cheap IR remote I was using, but I did not have very good luck getting consistent reading with each button-push on the remote. It was OK for moving a robot around just to show I could do it, but unless your remote provides more consistent readings, I would not trust it with anything important.

If you want to control several items with the remote readings, then you will need a way to remember state for each item. You will not be able to feed button-press directly to motor speed because some button-presses will have nothing to do with speed for that motor. If button-press has nothing to do with speed for that motor, then you would not update motor speed. As stated above, one way to get around this is to only list buttons for speed control in the switch-case, then have some unique value for default. If you see the default value on output, then you ignore and leave speed at its current setting. Probably the best way to remember current speed is with a buffer node.

In this example, we enable gate if switch-case-OUT is not equal to DEF (99). pulse-on-change will generate a pulse to update buffer each time there is a change. defer makes sure gate is updated before we send the pulse. If output is not DEF, gate is enabled and pulse updates buffer for a new motor speed; otherwise pulse is blocked and motor-speed keeps its old value. switch-case can be expanded to cover all motor-speed buttons (but no other buttons…those would be handled by another switch-case to provide some other functionality).

Buffer! perfect!! thank you so much. i had searched for “store”, “Fail last”, “retain”, “hold” etc etc… Buffer, wow, i knew it was a terminology issue i had to over come. I will use this knowledge to further develop an approach to this project.
Yes, the remote we are using is a cheap little thing. Odd how it gives multiple codes, seemingly at random, from same button. Our work around for now is to use a left over stereo remote from a Yamaha Home Stereo system. It seems a bit higher quality but also has many more buttons. In addition to this we are controlling all “critical” timing events in the experiment with programming instead of relying on the function of a remote.
I will update this thread when i have more to show.
Thanks again,
J.