Multi-button detection and counter

[VinnyAstro]

Hi!

I am trying to improve a bit my user interface (or rather the user experience) :
I have a few buttons sending commands to stepper motor drivers, internally via a message handler structure and then via wifi to a platform where the electronic is.

The system response is slow and the user has to wait for the motor to finish moving before sending a new command.

For various reasons, the user commands only in fixed positions (1 step, 10 steps, 100steps etc. But my software can send random number of steps.) So if the user wants to move to 56 steps (rather not happening but just for the example) then he'll have to click once on 10 steps, wait. Click again, wait, etc. 5 times and then .... you have the idea.

So I'd like to implement a "button counter" which is also recognizing the button itself.

That way if the user clicks 3 times on B1 et right after 2 times on B2, my software will send only two seperates commands.

I came accros this idea that wouldn't be difficult to implement in my soft, after 1 second of inactivity on the buttons, then the command is sent, but if the user clicks 2x on B1 and then 3x on B2, then it will send 5x B2 which is not acceptable. 

 

Any tips to improve this?

Should I create one cluster per buttons so they all have their own counter? Should I use user events instead?

Thanks in advance.

Vinny.

[GerdW]

Hi Vinny,

you may use a queue to store commands for your motor driver.

The driver reads the queue and processes the commands.

As long as the command is processed the queue can collect new commands.

When the driver checks the queue next time it can read all received commands and sum up the steps to be processed…

[VinnyAstro]

The driver is embedded on a PCB I don't have acces to its code. The idea for me is to send a command (any command) to a µc on a platform via wifi, the µc "translates" that command into something readable by the driver and the driver executes.

So whatever I send via wifi should be my "number of clicks*motor steps" basically.

I'm trying to think of a solution as simple as possible, but I don't see any that doesn't involve one queue or one counter per button.

[LLindenbauer]

---

@VinnyAstro wrote:

The driver is embedded on a PCB I don't have acces to its code.

---

Hello!

"Driver" means different things in different contexts. If You wish, You may replace the word "driver" with the phrase

"Sub-VI that can interpret a list of user-commands as a list of signals to send over the connection to whatever hardware will receive them"

This may help You in making sense of the hints. They are the simplest way to describe a producer-consumer pattern, which seems like a fine solution for Your problem.

Edit:

I think I now understand the task. Please correct me if I am wrong: You want to collect all user commands that are entered while the communication takes place for the previous command and then send them all at once for the next command?

I may be overcomplicating this, but depending on the complexity of Your hardware, You could simulate the current motor state, have the queue handler pick up the current difference between the actual state and desired state and send that as the next command. Of course, the simulation can be very simple it it just the number of steps on a linear device.

---

[altenbach]

You need to make it scalable. Instead of a counter scalar in the cluster, you could use an array of counters and an array of button names.

[altenbach · Accepted solution]

Here's what I had in mind...

[VinnyAstro]

I was also thinking of evetually using two arrays, but you made it so simple I clearly need more experience haha

Thanks a lot!

[VinnyAstro]

---

@LLindenbauer wrote:

---

@VinnyAstro wrote:

The driver is embedded on a PCB I don't have acces to its code.

---

Hello!

"Driver" means different things in different contexts. If You wish, You may replace the word "driver" with the phrase

"Sub-VI that can interpret a list of user-commands as a list of signals to send over the connection to whatever hardware will receive them"

This may help You in making sense of the hints. They are the simplest way to describe a producer-consumer pattern, which seems like a fine solution for Your problem.

Edit:

I think I now understand the task. Please correct me if I am wrong: You want to collect all user commands that are entered while the communication takes place for the previous command and then send them all at once for the next command?

I may be overcomplicating this, but depending on the complexity of Your hardware, You could simulate the current motor state, have the queue handler pick up the current difference between the actual state and desired state and send that as the next command. Of course, the simulation can be very simple it it just the number of steps on a linear device.

---

---

Ah ok mis-interpreted that one, thanks for the tip.

Yes and no. My system's response is very slow (on the electro-mechanical side) but for some reason the µc managing the platform cannot receive too many commands either, so I need to watch out not spamming it. 

Thus the idea of sending "one command move M1 to position 37" instead of "4 commands move by 10 and then 3 commands move by -1"

The times response of my system makes it also somehow difficult and dangerous to simulate as if ever the user decides to move in the other direction I'd have to make sure where I am 🙂