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:
- 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. - 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) - 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. - De-energize Solenoid A (I<< button)
- When pressure at manifold is confirmed at 0 psi, return motor A to 0% duty cycle (button 0).
- 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.
Well I am back again and looking for some keen eyes. I had his thing working last night but it was all a big mess on the “main” project page. So i decided to break it all up into nodes and it has not worked since. it is possible i only thought it was working last night… Now i am not sure I had hoped that after some sleep and taking a fresh look i would see something but …no.
So here is the deal, if i do not connect the aux. VDC (dip switch 2 in off position), the program seems to work fine. Each (+) button push increases the duty cycle by 20%. When i hit the (-) button the duty cycle is reduced by 20%. and lastly, if i hit the (0) button the duty cycle goes directly to 0%
However, when i do connect the aux. VDC…
pushing the (+) button will either, 1. flash 20% duty cycle for less than a second then return to 0% or , 2. freezes up, (as in the picture below), and will not stop running at 20%.
Where have i gone wrong?
pictures, pcb layout, and xod screen shots attached
What pin is getting power when you switch DIP 2 on? Why are you doing this if it works with DIP 2 off?
With dip 2 off, only power from usb no power to mosfet drain. Common Source is still connected. (programming mode) It “works” only in such that you can watch it in debug mode.
With dip 2 on, no usb, only external power 7-12 Vdc. termination points are listed in the Nano Schematic V3.3 as, J2-1 (VIN) and J1-4 (GND). (run mode)
Dip 2 connects to VIN by way of jumper as it crosses the 3 soldered connections to the IR Sensor. Two or three button presses into trying to get it to start will result in the motor finally starting but then it is frozen at 20%, as seen in snip it of debug session. Also does this if both power sources are connected at same time.
Thank you for your quick responses. Very kind of you to help.
J.
Do you have a voltage meter you can use to verify 5v pin on the board with USB vs battery power? I’m not seeing any obvious reasons why it shouldn’t be working…
This is not about your query, it is about project management according to my point of view.
If you save locally, by making considerable changes you rename the project test-1.xodball test-2.xodball etc.
If you do it online, change the version 0.0.1, 0.0.2, etc. In this case download a previous version example "you-user"/test@0.0.1
oh no, i had not expected to stump a guru. lol
I will go over it again i a few hours. i have a Fluke MM and an o-scope. so theoretically i can track down everything, but i have no experience with the o-scope… probably the Fluke will get me enough data.
I will let you know what I find
When i went back to the bench last night the Nano in the project would not do anything. The computer would not even notice when it was plugged in. I changed to another Nano and it all worked as intended. Not sure what caused the Nano to die, static? short? mean faces i was making at it? I don’t know but both files, versions before and after creating the nodes to clean things up, worked just fine.
Cesars,
You are very correct about proper file management. The version seen in the screen shots is not the same as the version in the actual project (v20.02.19) it is a stripped down “working” version i created for the purpose of this conversation so that the other ancillary components of the program, (strings, formulas, pressure transducer nodes), would not muddy the discussion.
When I realized that the program was freezing up on me i had tried to go back to the previous version and it made no difference, this is what had made me question whether or not it had been working correctly during the previous nights work.
Thank you so much for all of your help, Xod is a very valuable resource but i could never get through it all without all of these threads to read through. Though sometimes i wish a magical Aduino fairy could wonder around the World Wide Net Web and disappear all the incorrect information out there, it really makes the learning curve a lot steeper.
Thanks again,
J
I have gotten everything we have talked about to this point to work as expected. All my little bugs have been worked out. So now i suppose it is time to put in more bugs. We want to be able to record and graph the various data we are getting from our sensors. i looked around a bit today in the documentation and the forum but I have not hit the specific topic i am looking for.
similar to these tutorials:
https://www.arduino.cc/en/tutorial/graph
and
but i have not found a such as these using xod
to be specific i will have three sensors graphed at the same time so we can see how they interact with each other over time… so 3 sensors and the 4th data point of time.
I will begin banging my head against the wall this evening but was wondering if there are some tutorials or instructables or whatnot that anyone would suggest i take a look at before i get started?
as always, thanks for any advise you might have