Just looking for comments on this application

[GregFreeman]

Lets be honest, the best way to learn is to do the dam* thing yourself. So I am hear looking for comments on my app before I add more classes to it and really dig myself a hole. Any comments/critiques are appreciated.

A couple of questions first:

1. I want to query the GPIB every 125 ms and let the user know if it isn't responding(now I do this in the error case, but the error case is called every time a read fails, and I don't want to let them know 8 times a second...a bit overkill don't ya think?) What is the best way to handle this? I need to look into if the hardware responds to an identify cmd and maybe I will just query each piece of hardware at the beginning and let the user know then what's connected and whats not

2. Would it be better to have a subVI that takes a reference to the FP "update" indicator and appends strings there, or should I return a string from each subVI as it executes and append it (as I am doing now)?

3. I don't know if its an illusion cuz I have frames around the fp LEDs but I have manually sized the LEDs to the same width and height, yet they still look different sizes. Also, is there a way to manually set the frames' width and height as you can do with the LEDs? Suggestions?

K, have at it, and go ahead and be honest.

In lv 8.5

Message Edited by for(imstuck) on 02-04-2010 02:29 PM

[GregFreeman]

Doh, just noticed somehow PowerOn_PowerOff was renamed to copy of standby_operate. Could that have been my fault? noooo.....

But yeah, just rename that copy to PowerOn_PowerOff and the app will find it.

[Mark_Yedinak]

---

for(imstuck) wrote:

Lets be honest, the best way to learn is to do the dam* thing yourself. So I am hear looking for comments on my app before I add more classes to it and really dig myself a hole. Any comments/critiques are appreciated.

A couple of questions first:

1. I want to query the GPIB every 125 ms and let the user know if it isn't responding(now I do this in the error case, but the error case is called every time a read fails, and I don't want to let them know 8 times a second...a bit overkill don't ya think?) What is the best way to handle this? I need to look into if the hardware responds to an identify cmd and maybe I will just query each piece of hardware at the beginning and let the user know then what's connected and whats not

2. Would it be better to have a subVI that takes a reference to the FP "update" indicator and appends strings there, or should I return a string from each subVI as it executes and append it (as I am doing now)?

3. I don't know if its an illusion cuz I have frames around the fp LEDs but I have manually sized the LEDs to the same width and height, yet they still look different sizes. Also, is there a way to manually set the frames' width and height as you can do with the LEDs? Suggestions?

K, have at it, and go ahead and be honest.

In lv 8.5

Message Edited by for(imstuck) on 02-04-2010 02:29 PM

---

I generally like to separate my UI processing from my application processing. If you are only interested in the lastest status updates from your polling use a notifier to post the updates. Have your task that is updating the display run at whatever frequency you want and at its regular intervals simply get the notification. Only the latest information wil be available. You could use a lossy queue of size 1 as well. In this instance the queue would probably be the more technically correct structure. I also prefer to use a Producer/Consumer architecture which would separate your UI processing (the event structure) from your processing tasks. You can use user defined events to post information to your UI task. Another possible architecture would be to have one task which handles nothing but the application events. A second parallel task that handles front panel updates and a third task which is your processing task.

I don't like to pass references to front panel items into subVIs unless the sole purpose of that subVI is front panel processing. I like to keep task processing separate from UI processing. By passing references to your task processing subVIs you are coupling the two types of processing. This reduces the reuse of your code. By keeping things separate it is easier to modify one side or the other without impacting other parts of your application or modifications causing unintended side effects.

[GregFreeman]

---

Mark Yedinak wrote:

---

for(imstuck) wrote:

Lets be honest, the best way to learn is to do the dam* thing yourself. So I am hear looking for comments on my app before I add more classes to it and really dig myself a hole. Any comments/critiques are appreciated.

A couple of questions first:

1. I want to query the GPIB every 125 ms and let the user know if it isn't responding(now I do this in the error case, but the error case is called every time a read fails, and I don't want to let them know 8 times a second...a bit overkill don't ya think?) What is the best way to handle this? I need to look into if the hardware responds to an identify cmd and maybe I will just query each piece of hardware at the beginning and let the user know then what's connected and whats not

2. Would it be better to have a subVI that takes a reference to the FP "update" indicator and appends strings there, or should I return a string from each subVI as it executes and append it (as I am doing now)?

3. I don't know if its an illusion cuz I have frames around the fp LEDs but I have manually sized the LEDs to the same width and height, yet they still look different sizes. Also, is there a way to manually set the frames' width and height as you can do with the LEDs? Suggestions?

K, have at it, and go ahead and be honest.

In lv 8.5

Message Edited by for(imstuck) on 02-04-2010 02:29 PM

---

I generally like to separate my UI processing from my application processing. If you are only interested in the lastest status updates from your polling use a notifier to post the updates. Have your task that is updating the display run at whatever frequency you want and at its regular intervals simply get the notification. Only the latest information wil be available. You could use a lossy queue of size 1 as well. In this instance the queue would probably be the more technically correct structure. I also prefer to use a Producer/Consumer architecture which would separate your UI processing (the event structure) from your processing tasks. You can use user defined events to post information to your UI task. Another possible architecture would be to have one task which handles nothing but the application events. A second parallel task that handles front panel updates and a third task which is your processing task.

I don't like to pass references to front panel items into subVIs unless the sole purpose of that subVI is front panel processing. I like to keep task processing separate from UI processing. By passing references to your task processing subVIs you are coupling the two types of processing. This reduces the reuse of your code. By keeping things separate it is easier to modify one side or the other without impacting other parts of your application or modifications causing unintended side effects.

---

Completely agree with separating the two. In fact I usually do this. I suppose I figured that this is an application that doesn't require a lot of user interaction (you wont be turning amplifiers on and off, switching amps, changing modes etc repeatedly). Once it's set, it's pretty much left alone, so first through was it wont be running into issues with UI and processing stepping on each other. Therefore, I made it one thread. However, who knows what it may grow into, in which case I should keep that in mind because at some point this may become an issue. Time permitting, I will go back and split it up. Thanks for your comments.

[Mark_Yedinak]

I almost always assume that something I write will be reused, especially something that is interacting with a piece of hardware. It has saved my butt more than once by a future project came together very quickly or a new feauture to an existing application was added quickly because a little thought up front made the job easy later on. As programmers we should always be thinking about reuse and extension. We all know that released code lives on for many years.