Buggy LabVIEW Templates & Courses?

[SimonH]

---

@AStankov wrote:

Let's take the Continuous Measurement and Logging Project Template. Just add some delay to the "Start" case in the consumer loop, this is realistic because it may take some longer to execute a consumer command. Put a simple local var and increment it inside the same case and output it to an indicator. Then click the "Start" button quickly twice. It will enqueue the Start operation twice before the "Start" button is disabled by the consumer (watch your counter). This is the bug! Disabling the "Start" button immediately inside the producer event case solves the problem for me.

---

You are correct and your solution will work.  In our particular case the consumer loop is the UI message loop (as opposed to a hardware interface or processing loop) and there should never be any delay that blocks disabling the controls (since they don't need to wait for any blocking inputs). This is why we haven't had any problems during our testing and didn't anticipate users running into problems.  We have noted the issue and we'll get it fixed in a future release.

As far as a solution for you in the meantime I would rather see the intelligence belong in the message handling loop. If you were to turn the message handler into a state machine you could choose to either process or reject messages based on the current state of the application. 

In the template you'd want to add a shift register, enum, and case structure to the UI Message Loop like this:

 

This way instead of preventing the killer sequence of events you remove the possibility of a series of events killing the application. Same end result right now but I think this would scale better in the long run.

Of course you know the scope of your application you can better decide which way to proceed.

I apologize for the inconvenience and thank you for highlighting a well-justified concern. We are actively listening to feedback and will continue improve the templates and sample projects. 

Regards,

Simon

[AStankov]

Mark and Simon, thank you for the possible workarounds, I will have a closer look at them and the benefits, though they appear to me more complex than my solution at the moment.

[Mark_Yedinak]

---

@AStankov wrote:

Mark and Simon, thank you for the possible workarounds, I will have a closer look at them and the benefits, though they appear to me more complex than my solution at the moment.

---

A solid and robust UI is not a trival task and oftens includes quite a bit of complexity. At least this is the case if you want it to be bullet proof.

[AStankov]

---

@Mark_Yedinak wrote:

A solid and robust UI is not a trival task and oftens includes quite a bit of complexity. At least this is the case if you want it to be bullet proof.

---

I am well aware of this bit I am scared to find out that the developers of the templates and courses were not. Again, for me this is something a good developer simply should not "overlook". NI is working with these patterns for years and should be aware of the possible problems. The whole "lock front panel" concept in LabVIEW is a bit strange for me, as events are still enqueued while the front panel is "locked"...

Simon's proposal to insert an additional state machine inside the UI message consumer loop sound good but it also makes things even more complex. I am not sure if it is easy to adapt it to situations where there are more complex dependencies between the front panel controls. Would this require states inside states?

[Mark_Yedinak]

---

@AStankov wrote:

---

@Mark_Yedinak wrote:

A solid and robust UI is not a trival task and oftens includes quite a bit of complexity. At least this is the case if you want it to be bullet proof.

---

I am well aware of this bit I am scared to find out that the developers of the templates and courses were not. Again, for me this is something a good developer simply should not "overlook". NI is working with these patterns for years and should be aware of the possible problems. The whole "lock front panel" concept in LabVIEW is a bit strange for me, as events are still enqueued while the front panel is "locked"...

Simon's proposal to insert an additional state machine inside the UI message consumer loop sound good but it also makes things even more complex. I am not sure if it is easy to adapt it to situations where there are more complex dependencies between the front panel controls. Would this require states inside states?

---

You are expecting the impossible. The templates are not intended to be a fully designed system. They are a starting point. If you want more robust templates you are free to develop them yourself. If you get a C++ compiler they do not come with full feature templates handling all UI possibilities. You as the developer are expected to do some work. You can't expect the language provider to do everything for you. And that is exacting what NI is, the language provider. The other thing you want is a robust and full featured system that has no complexity to it. That can't really happen. Once you start adding all of the features you discuss your complexity increases. Yes, some solutions are better than others and you can create some overly complex code. But you can't expect to have the type of robustness you desire with no complexity in the code.

State machines within state machines is perfectly acceptable. There is nothing wrong with doing that. To achieve the type of robustness you desire will require you to create a solid design and choose the correct architectures to implement that design. While LabVIEW makes it easier for non-programmers to learn how to write basic applications you still need someone with a solid programming background to develop large complex systems.

[AStankov]

---

Mark_Yedinak wrote:

You are expecting the impossible. The templates are not intended to be a fully designed system. They are a starting point. If you want more robust templates you are free to develop them yourself. If you get a C++ compiler they do not come with full feature templates handling all UI possibilities. You as the developer are expected to do some work. You can't expect the language provider to do everything for you. And that is exacting what NI is, the language provider. The other thing you want is a robust and full featured system that has no complexity to it. That can't really happen. Once you start adding all of the features you discuss your complexity increases. Yes, some solutions are better than others and you can create some overly complex code. But you can't expect to have the type of robustness you desire with no complexity in the code.

State machines within state machines is perfectly acceptable. There is nothing wrong with doing that. To achieve the type of robustness you desire will require you to create a solid design and choose the correct architectures to implement that design. While LabVIEW makes it easier for non-programmers to learn how to write basic applications you still need someone with a solid programming background to develop large complex systems.

---

Good to know that expecting a bug free application in LabVIEW is regarded impossible. The templates are advertised as working best-practice projects and I pay for that. Probably the impossibility to deliver a usable bug free solution is in the whole UI event handling concept of LabVIEW? Or it would make the block diagrams so complex that noone would understand them? In other programming languages it is very common to just disable a button to prevent it from firing the event twice. But here it is not best practice, instead we rely on the fact that the user is clicking slower than our loop executes commands. The whole concept of simply queueing up events leads to serious problems in real world apps but it is still advertised as best practice without even mentioning the problems. How about moving a slider fast in order to change some parameter of a hw device in real time? This will fill your queue with events and they will all go directly to the hardware one by one later. But the courses and templates just ignore such topics. There is no excuse for that, it makes the user think that a program works while it is full of problems. Sorry, I do not accept your statement that I were looking for complexity and extreme robustness, I am looking for a bug free and usable concept and I demonstrated how easy it is to make the best-practice solutions crash. But obviously such problems have to be expected in LabVIEW at the moment. Please point me to some good books or other sources to find information on how to write an application with usable noncrashing UIs. Btw, I have programmed FPGAs in VHDL and I know what robustness and complexity means. Here we are talking about amateur bugs in pretty simple applications where not all controls should be clickable at any time. This is not complex.