[Robotics] How to setup a robotics project with a GUI

[JoeKellyATI]

Hello all,

I started a thread earlier asking a question about a QMH, but I had more questions, so I thought I'd make a new thread.

I have a project that scans a part and measures the thickness and width of the part.  Currently, I have two linear slides, each with a laser rangefinder on it.  The premise is I subtract the rangefinder measurements from the distance between the rangefinders themselves to get the thickness.

I'm using a NI USB-6218 DAQ to control/measure the laser rangefinders and watch the length encoder.  The slides are controlled via serial commands.  All of this has to be controlled by a computer that an operator can use to see the thickness of the part and run the scans (as well as see other various digital readouts from the fixture).

Right now, I'm using a sort of Queued State Machine (QSM) with all of the components (UI, slide commands, logging, and laser commands) all in one queue.  The serial commands are run in parallel (separate While loop), but everything is run from one VI.

Here's where I'm having issues:

Right now, I'm having some issues with the UI locking up because of certain tasks waiting for a certain condition to be met (e.g. "Wait for material to be between sensors")  I also have a "Start Scan" state that queues up a multitude of states to be run that execute the scanning procedure.  This is probably where the UI freeze comes into play.  Because of this major flaw, I started looking into multiple queues for the different components.  Through my research, I came across a Queued Message Handler (QMH).  This is what I'm currently trying to figure out.

Here's my question:

My question is, is the QMH the right way to go for this type of project?  This project has to keep the UI clear of "freezing", constantly be pinging the slides for status updates (e.g. position, "In Position", velocity, etc.), logging to a data file when appropriate, and controlling the DAQmx tasks that check the length encoder and the two laser rangefinders.  Can anyone point me in the right direction for a structure to use, or a project that someone has made that uses multiple queues that need to communicate with each other?

Thanks!

Joe

[MichaelB123]

Hi JoeKellyATI,

What exactly do you mean when you say the UI is locking up/freezing. With the QSM, do you have an event handler consumer loop to handle all the events from your UI? It should allow for buttons to be pressed while the code is executing. If you can share parts of your code it will be easier to visualize your code. It can also encourage other users to look into your code.

I would also link the other thread you made to add more context to your project.

forum 

Regards,

Michael Bulua

Applications Engineer

National Instruments

www.ni.com/support 

[JoeKellyATI]

I have to make a few adjustments, but right now, I'm using the JKI State Machine, and they have it built where the Event Handler is inside the loop.  When there is nothing in the queue, it checks for UI events.  I'm not a fan of this method, but so far, it's gotten me to a good first step.

Here's my first post: https://forums.ni.com/t5/LabVIEW/QMH-Having-a-state-repeat-until-a-condition-is-met-without/td-p/375...

[MichaelB123]

From the JKI state machine, it looks like the event handler is in the same loop. If you build off of a QMH, then you will have the event structure in its own parallel loop.This should allow you to click buttons while the event is running and not freeze up the UI while the code is executing in another section.

In the LabVIEW example finder, there is a Queued Message handler example. This may fit well from what you described of your application.

In addition here is a document which goes over some of the basics of QMH in LabVIEW:

http://www.ni.com/tutorial/53391/en/

Michael B.

Applications Engineer

National Instruments   

[paul.r]

If you go to File>Create Project>Sample Projects and chose the Continuous Measurement and Logging sample project, you can use that as an example of how you could structure your code for multiple parallel tasks. 

[JoeKellyATI]

Thanks all!  I've started with the continuous measurment and logging project as a template.  Now, I'm trying to figure out the best way to carry out a list of events with some of the events having to wait for a condition before they move on to the next event.

For instance, I have a Move Slides command (moves a specified distance at a specific speed), a Wait for Part command (looks at the lasers, and wait for the lasers to "see" something), and a Move Until Material command (moves (or "jogs") the slides until the lasers "see" the material).

How can I work with a QMH that will work with a repeating process?  Note that a lot of these commands get used outside of this "multicommand" command.  The QMH is designed, from what I can tell, to work with one task after another, dequeuing each thing one after another.

If I wanted to repeat a task, is it bad practice to just re-queue it at the front of the queue?

Thanks!

[paul.r]

---

@JoeKellyATI wrote:

Thanks all!  I've started with the continuous measurment and logging project as a template.  Now, I'm trying to figure out the best way to carry out a list of events with some of the events having to wait for a condition before they move on to the next event.

For instance, I have a Move Slides command (moves a specified distance at a specific speed), a Wait for Part command (looks at the lasers, and wait for the lasers to "see" something), and a Move Until Material command (moves (or "jogs") the slides until the lasers "see" the material).

How can I work with a QMH that will work with a repeating process?  Note that a lot of these commands get used outside of this "multicommand" command.  The QMH is designed, from what I can tell, to work with one task after another, dequeuing each thing one after another.

If I wanted to repeat a task, is it bad practice to just re-queue it at the front of the queue?

Thanks!

---

Well, you have no guarantee that no other components have not enqueued a new message in between you carrying out the task and re enqueing the repeat state - so you dont really know if the task will be immediately repeated, which may or may not be what you want. 

What determines how many times you will want to repeat the task? Can you put your task into a subVI, then create a wrapper VI that calls the task subVI in a for loop. The problem with this is that your message handler will be unable to process any other requests while that is executing - again, which may or may not be a problem depending on your design. 

[JoeKellyATI]

---

@paul.r wrote:

Well, you have no guarantee that no other components have not enqueued a new message in between you carrying out the task and re enqueing the repeat state - so you dont really know if the task will be immediately repeated, which may or may not be what you want. 

What determines how many times you will want to repeat the task?

 That's the tricky part.  A lot of the time, it's not "how many times", but rather "when is another task done".  Right now, I have multiple consumer loops.  One for logging, one for the DAQmx tasks (lasers), and one for controlling the slides (via Serial commands).  So, in the main UI consumer loop, I wanted to know if I could put in various commands to the different consumer loops, but have the main UI loop wait until those loops are done.  That's the tricky part 🙂