Developing an Interface

[Vraagteken]

I'm developing an interface for my graduation project and I have some questions (as said before: I do not want that you make it for me). I have tried searching an anwser for these questions on the boards, but didn't find any. If I missed it then a handy link would be appreciated.

The file interface.jpg gives an overview of the general composition of the interface. The button which says "stop" will also become the start button of the vi (I still have to rework that button). And when it's pressed I would like to have some sort of pop up requesting a password. How can I accomplish this?

The next few questions regard the structure of the block diagram (see Interface_intern.jpg for more detail). The subpanels represent different submenu's in the interface. The data in these submenu's comes from a microporcessor controlled board. To pass data back and from the board I use the RS232 protocol. I would like to place the code that does this (from a LabVIEW example) in the main VI in such a way that when a button is pressed (this button has yet to be added) a routine will start that:

1. collects the data from the current selected submenu (can this be doen by the "call by reference" block?)
2. enters this data in a lowlevel protocol
3. transmits the data using RS232 (with regard to the protocol)
4. reports abck to the user that the operation was completed/failed/...

Another button would do the same, but it requests data from the board and communicates it with a submenu, which is then initialised with that data.

Also I would like to control the settings for the RS232 through a submenu (despite it being located in the main.vi; see Interface_4.jpg for more detail).

Thank you in advance.

[jdunham]

The first thing I would recommend is to fix your button selection code.  Instead of using "boolean array to number", use "search 1-D array", searching for TRUE.  Then you can number your cases sequentially instead of 2^N - 1.  This is how everyone polled buttons before the event structure was added.  Actually you should use an event structure unless your version of LabVIEW doesn't have it, but then the buttons will be just fine.

Another recommendation is that you use at least two loops.  Serial communications are asynchronous and often slow, and it will be much harder to manage the serial transaction in the same code structure which is handling the user interaction.  One loop should handle user events, and this loop should always run at least 10 times per second. The other loop can run as long as it needs to for each task your software must accomplish.  There are many ways to communicate between the two loops, but I think consensus is pretty strong that queues are the best way.  The task loop should also present status to the user interface.  For example, you can dim out a button (or all of them except "cancel") when a task starts, and then re-enable it when finished.  This not only provides feedback but also prevents the user from pressing the button at the wrong time.

Finally, be sure to code up the serial transactions in separate subvis.  Get each conversation working and tested before trying to drop it into your user interface.  The ability to get the pieces working so you understand the system before building the final framework is one thing that makes LabVIEW so great.

[parthabe]

Your application definitely warrants the usage of a state-machine architecture using 2 while loops, aka Producer-Consumer design, where you poll for the buttons programatically all the time; or, an event-driven architecture where LV takes care of the button-polling process in the respective value-change events of the FP buttons.

You can search the LV Examples thro' help in the above-said titles for more information, with nice examples.

And, also the forums, as usual as always...

[parthabe]

Forgot to tell...

As the last thing, follow some nice standard industrial colour-code for your Front Panel, albiet it is an academic project.

[Vraagteken]

Thanks for the advice jdunham and parthabe, I will look into these things (and if I have problems I will search/post about them).

---

@jdunham wrote:

Finally, be sure to code up the serial transactions in separate subvis.  Get each conversation working and tested before trying to drop it into your user interface.  The ability to get the pieces working so you understand the system before building the final framework is one thing that makes LabVIEW so great.

---

In that case, any light that shines on this problem: I connected a usb to serial connector, installed the drivers and ran the basic serial comm vi. I got the following error: Error 1073807253. Which is a framing error. 

I have tried looking up solutions, but don't seem to find any. 

[jdunham]

@Vraagteken wrote:

In that case, any light that shines on this problem: I connected a usb to serial connector, installed the drivers and ran the basic serial comm vi. I got the following error: Error 1073807253. Which is a framing error. 

---

The first thing to check is to make sure the serial (RS232) baud rate, parity, and stop bits which you have set on the serial port match the device on the other end of the cable.  You set these items VISA property nodes (VISA.Serial Settings....).  If they don't match you will always get bad data and usually get framing errors.  There are also settings for those items in Device Manager, but those are just defaults and will be overridden by your VISA property node settings.  The settings for your device must be documented along with the device; this is a requirement for using serial ports.

If those are set right and you still get occasional framing errors, you may have crummy hardware.  I have an application where the occasional framing error is reported, but I just retry the message in a loop and it always works the second time.  This is a lot less likely than bad settings.

Jason

[Vraagteken]

A longer reply, since I now have some more time to focus on the practival realisation.

---

@jdunham wrote:

The first thing I would recommend is to fix your button selection code.  Instead of using "boolean array to number", use "search 1-D array", searching for TRUE.  Then you can number your cases sequentially instead of 2^N - 1.  This is how everyone polled buttons before the event structure was added.  Actually you should use an event structure unless your version of LabVIEW doesn't have it, but then the buttons will be just fine.

---

Well the button code kind of warped into that, since I was thinking of adding two extra screens. The first would be the pasword screen, and the second would be a "warning" screen (whenever multpie buttons would be pressed). But I'll look the event structure up and try to work it out.

---

@jdunham wrote:

Another recommendation is that you use at least two loops.  Serial communications are asynchronous and often slow, and it will be much harder to manage the serial transaction in the same code structure which is handling the user interaction.  One loop should handle user events, and this loop should always run at least 10 times per second. The other loop can run as long as it needs to for each task your software must accomplish.  There are many ways to communicate between the two loops, but I think consensus is pretty strong that queues are the best way.  The task loop should also present status to the user interface.  For example, you can dim out a button (or all of them except "cancel") when a task starts, and then re-enable it when finished.  This not only provides feedback but also prevents the user from pressing the button at the wrong time

---

Loops, as in while loops? I get the feeling that you are refering to a different type of loop.

---

@jdunham wrote:

Finally, be sure to code up the serial transactions in separate subvis.  Get each conversation working and tested before trying to drop it into your user interface.  The ability to get the pieces working so you understand the system before building the final framework is one thing that makes LabVIEW so great.

---

So make a subvi for each transfer? Isn't that a bit complicated. I was more thinking of coding it in a mdoule and then hook it up with the RS232 code.

---

@jdunham wrote:

If those are set right and you still get occasional framing errors, you may have crummy hardware.  I have an application where the occasional framing error is reported, but I just retry the message in a loop and it always works the second time.  This is a lot less likely than bad settings.

Jason

---

I'll have to do a retest, but I agree. Its most likely the hardware.

---

@parthabe wrote:

Forgot to tell...

As the last thing, follow some nice standard industrial colour-code for your Front Panel, albiet it is an academic project.

---

I have shown the interface and it was approved. So I'll just go ahaed with the nice grey colours.

Once more; thanks for the replies jdunham and parthabe.

[jdunham]

---

---

@jdunham wrote:

Another recommendation is that you use at least two loops. 

---

Loops, as in while loops? I get the feeling that you are refering to a different type of loop.

---

Yes, While loops

---

---

@jdunham wrote:

Finally, be sure to code up the serial transactions in separate subvis.  Get each conversation working and tested before trying to drop it into your user interface.  The ability to get the pieces working so you understand the system before building the final framework is one thing that makes LabVIEW so great.

---

So make a subvi for each transfer? Isn't that a bit complicated. I was more thinking of coding it in a mdoule and then hook it up with the RS232 code.

---

I think it doesn't matter too much, whether you use one VI for your instrument or several, though I prefer to use different VIs.  The most important thing is that you have the protocol for dealing with your instrument in self-contained VIs which you can test without running your user interface or main VI code.  That means keeping direct calls to the VISA Serial libraries out of the user interface loops and it means the subvis which do call those items don't know anything about how you have implemented your user interface.  That will make your code both reusable and easier to test.