Discussion: Simple programming task?

[Nordstern]

Hi all,

i read http://forums.ni.com/ni/board/message?board.id=170&message.id=259737 some time ago and decided that i wanted to create an example for this one.

So i started right off with the attached result.

I have done several mistakes during creation of this VI and since i am aware that (too) many LV-users are not aware of "style guides" or "Rube Goldberg", i want to use this thread for discussion on these matters in regard to my example. So please feel free to post everything you like/dislike on this. Esp. design-"feature" should be a focus!

thanks in advance,

Nordstern

[smercurio_fc]

I think the LabVIEW forum is a better place for this post.

Also, I'm not sure I understand what it is that you're asking. In fact, I know I don't understand what it is that you're asking for.

[tst]

The LabVIEW board comment is basically correct, but here is my quick review:

In general, it works, so it's OK. Some comments I have about its implementation:

• Simplify the process itself. Don't do the pause\continue in the process. Instead, do it in the top loop and simply send the right command.
• In the same area - you don't need two booleans to do a single thing. Simply have a boolean for the top loop (run\pause) and toggle its value when pressing the button.

As for a more generic comment, I would avoid doing it like that, because it's not very reusable. Instead, I suggest you use an Action Engine.

AE Hint 1: (select text to see): Potential actions are "Set time", "Check time", "Pause", "Continue".
AE Hint 2: When you do a check time action, you can substract the ms timer value from the previous run from the current ms timer to find out how much time has passed since the last call.

Message Edited by tst on 07-18-2007 08:49 PM

[Nordstern]

smercurio_fc,

i am not sure if the LabVIEW forum would be the better place, since the solution is working, but it has some major flaws. So i am not asking for "how do i solve..." or "help! help! i'm being repressed", but want to discuss the flaws and possible (better) solutions. The LabVIEW forum imho should serve the first part, breakpoint i was told does the other one....

Nevertheless, you are right since the LabVIEW forum has the most visitors so a discussion would probably be more.... attended there.

But for now, i think i will stick to breakpoint...

Nordstern

[Nordstern]

tst,

nice ideas and good feedback. So i can see you are suggesting two points of rework:

a) User Interface: Reduce the number of buttons or at least reconfigure them. This is something i am honestly surprised, because i thought the UI is quite ok despite of some layout-issues.

b) Architecture: I was waiting for something like this since i have made an error many, many developers around the world do, esp. in LabVIEW. I just started programming wihtout thinking first. Therefore i stuck with an architecture which solves the programming task, but has some flaws in its way how it solves it.

Just to give you some advice what i was up to by creating this post was:

- My solution has a strange behavour from countdown when pressing pause/resume very fast several times. (this would be a bug!)

- The datatypes (esp. for the boolean text) are aweful. i should have created a better/more general implementation for these data.

- As tst states, my solution is bound to the task, so not very reusable. As far as i understand, tst is suggesting to generate a module for timer-oprations with countdown-functionality which can be used by a UI the same way as internally in a larger project. Very good feedback.

maybe you can find some more, useful feedback,

Nordstern

Edit: Changes to layout

Message Edited by Nordstern on 07-19-2007 03:18 AM

[tst]

---

@Nordstern wrote:

So i can see you are suggesting two points of rework:

a) User Interface: Reduce the number of buttons or at least reconfigure them.

---

Not exactly. I can't look at your code at the moment, but the booleans I refered to are not the buttons, but the booleans you have inside the shift register of the top loop. Since they both refer to the same thing and have only two possible states (T-F and F-T), they can just be a single boolean.

If this will only be used for display, you could try making it an XControl. That would encapsulate all the code (including the UI handling code) into a single control.

[Nordstern]

---

@tst wrote:

[...]. Since they both refer to the same thing and have only two possible states (T-F and F-T), they can just be a single boolean.[...].

---

Sadly no, because they refer to two different buttons and therefore can take different states each. But you are right that the datatype i use here is more than suspicious. Something "grown", as i would call it....

[tst]

Ah, I see now. I missed that the Start button also becomes a Reset button. The structure itself seems reasonable, although I can't say I understand the "default" part of their labels.

What you could do to make it cleaner is to make the upper loop into a small state machine with an Update Controls Display state and in that state set the controls' strings and enabled state based on the values in your shift register. Then, you just need to call that state when pressing the buttons. This could also rid you of updating them before the loop.