Seeking to develop a complex application

[Evilopinions]

Hi I am a newbie to Labview software 8.5 and I have just started and am reading a lot of Labview tutorials so If one of the moderators feels that this is asked at the wrong place then please feel free to move this topic...

I am looking to develop a complex application which is described as follow..

I am looking into the total power consumption of a typical laboratory so I am looking into the following components..

1) Design something that will detect that the switches in the room are on / off .

2 )  detecting whethere the computers in a room are switched on / off / hibernation.

3) Detecting the room temperature of the room by sensor detection and temperature logging...

I have been suggested by a faculty to use Labview and am in learning phase..can someone suggest me some ideas or ways....

[falkpl]

Before you get into the labview side of it I would define the system parameters, how are you doing the sensing of the environmental settings

1. lights: photodiode for light or is there an automated switch Networked switch

2.  Probe the computer on/off using a message system or listen for fan activity

3.  Temperature TC or RTD, usb module, Compact DAQ Daq card .....

Once you decide how you are going to sense the physical phenom. then the labview code should be easier.

paul 

[Evilopinions]

Before you get into the labview side of it I would define the system parameters, how are you doing the sensing of the environmental settings

1. lights: photodiode for light or is there an automated switch Networked switch

2.  Probe the computer on/off using a message system or listen for fan activity

3.  Temperature TC or RTD, usb module, Compact DAQ Daq card .....

Once you decide how you are going to sense the physical phenom. then the labview code should be easier.

 Thanks for the quick reply 😉

The system parameters are basically

1)There is an automated networked switch... I would basically take a single switch into account and wait for it to be turned on / off to determine the condition of usage.

2) I would like to listen to the fan activity. / I may want to attach current clamps on computers to measure current usage and try and log data onto a computer

3) temperature to be measured by a normal cheap temperature sensor.. I am not sure about the USB module or any other DAQ card..

I would just like to Log the room temperature of the room at any given instance of time and save it on computer for further analysis.

Are there any tutorials related to these....Are there any readymade VI for this ? It would be very nice if you can point out some resources...Thanks.

[Evilopinions]

Bump...

[Gabi1]

as Falkpl pointed out, you task for the moment is not yet programming, but setting your hardware.

use a small oscilloscope, wire it to your switch sensor, observe signal.
decide on how you want to measure activity on the computer, and as well observe on a small scope that it does what you want. (side note: everycomputer has a small LED indicating operation. you can look on the motherboard and you will probably discover close to the LED connection some other unused pins. check if they give you a 5V signal when computer on - carefully )
purchase a temperature sensor - you have to decide what kind. if you are only for room temperature with no rate limit, you can just buy a cheap semsor with display of T and humidity, which has rs232 connection.

once you have your physical channels, then you can think of exactly what you want to do with them. the choice for Hardware will depend on the nb of sensors and rate of aquisition. from what i understand, you probably dont need more than a USB6008 (150$). once you have that, wire your channels to the DAQ card, and measure everything using MAX (Measurment and automation explorer - NI).

THen, and only then, it it is worth begining to develop your software. browse the Labview examples to get you started.

good luck

[DFGray]

The usual sequence for developing a program like you describe is as follows:

1. Determine how you will take your data.  This has been eloquently argued above.  Don't be afraid to write small data acquisition programs in LabVIEW to help you decide this.  It will help teach you what you need to know to write the actual program.  Resist the urge to make these the final program.  They will be too simple to be maintainable.
2. Determine your user interface.  Once again, write a couple of examples, if need be.  Use the event structure.
3. At this point, you have a good idea of what you need to accomplish it and how you are going to do it.  Take a couple of hours (or more, if needed) to design your program.  For example, you will probably have a UI loop and one or more data acquisition loops.  What tasks do each need to accomplish?  How are they going to communicate (queues?)?  What are the "objects" of your system (yes, you can write object-oriented LabVIEW - and it is easy to maintain).
4. At this point, it is time to write your system.  You will run into unexpected things, but if you did a good job on 3, they should pose no great problem.  Expect to spend almost as much time on this step as on the other three.
5. Ship It!

I would recommend an event driven state machine for your UI loop.  Your data acquisition should take place in one or more parallel loops (could be in other subVIs).  Communicate between the loops using queues or notifiers (queues are usually a better choice since notifiers are lossy).  Use single-element queues or action engines to hold global data.  Do not, under any circumstances, use a global.  If you know what you are doing, globals make excellent look-up tables, but as a beginner, you should avoid them.  It is too easy to produce race conditions that are very difficult to debug.  Similar comments apply to locals, although you do need these occassionally for UI related activities.  If you have a choice between a wire or a local, use the wire.

If you have trouble finding examples for any of the above, let us know.  Good luck!

[Evilopinions]

Too much of information to digest but all good 🙂

I have actually thought of a few things which are a priority..

I want to connect a simple temperature sensor to a DAQ card and get the temperature reading into labview..Using a data logger I will log the data for different times of the day...

I want to connect the interface card to the switch sensor so that every time a switch is pressed on it is recorded or logged ? (Is this possible - if yes directions would be helpful.)

I have read that a system fan program is used to determine the temperature of the system ...well is there a way to have the output of the system fan program on a labview fron panel..

I also wish to connect two computers and log the total amount of time that a computer has been active / inactive or in hibernation....

I am so amazed at the labview software and am equally pleased from the discussion forums and the replies...

Is there a way to rate your replies...all of you are truely great

[HEV]

First and foremost...realize that asking a question like this is like asking for advice in parenting...EVERYONE is going to give you their approach that has worked for them...not necessarily what might / will work in your work environment...

Here is what has worked for me...

REQUIREMENTS DOCUMENT:  You need to develop a written requirements document for your system...this can be segregated into separate documents for hardware (measurement accuracies, sample rates, required frequency response, etc.) and software (user interface, data acquisition, data logging, historic data retrieval, etc.) or it can be integrated into one document...either way...prepare the document and have your customers formally review and sign up to it...

REVISION CONTROL:  If you haven't already within your company...develop a rigid configuration management plan for your system...this will help you tremendously in the long run...

TEST DOCUMENT:  After writing your requirements document...this guy should be rather easy...prepare this document and live and die by it...if you need to make a change to your code (which cannot happen until you change your requirements document)...change your test document...then only complete the required portions of the test document after you are finished coding...

SOFTWARE:  Develop your software in a modular fashion...in other words...break it up into manageable chunks: user interface, data acquisition, data logging, historic data retrieval, etc...this will help in system development...testing...and also deployment...I say that it will help in the deployment process because depending on your required dates for implementation...you may not need to have the historic data retrieval module online as long as you know that the data is being properly written...bottom line is that you could get your system up, online, and acquiring data faster and push a new revision as time permits for something like the data retrieval...also...as already mentioned in previous posts...you might need to do some proof of concept coding to ensure that certain things will do what you assume they will do...this is often done with hardware (drivers)...

HARDWARE:  If you are selecting hardware that you are not familiar with...consider the possibility of getting a loaner from the company that you can "play" with...and do some quick testing with...also...BEWARE...if a company advertises that they have LabVIEW drivers for their hardware...don't take this as a "canned" application that you will be able to drop right in with your code and move on to the next module...often times...the proper word is not to drop...but it is to jam...

There are other odds and ends that I haven't put in here...but these are the "biggies"...

As most people on here will agree...one of the most difficult things to do is discipline yourself to not dive right into a new project and start coding away into the sunset...this is a very simple case of "pay me now or pay me a lot more later"...this isn't just a mindset that you have to break...but also with your management because some of this stuff is often seen as "fluff" that appears to be cost prohibitive...it is not...

And finally...good luck!

[PJS]

As for ratings, see here.
I agree with the above.  In addition, what is your budget for this activity?  I have not seen how you are going to calculate actual power consumption?  How do you know how much power a computer is drawing?  Printers? lights? Other AC sinks such as people charging devices; cellphones, mp3 players, laptops etc... externally powered hardrives, test equipment etc, etc? I am not sure how much use knowing the inside temperature of a computer is, but ambient air temp can be a big problem for test equipment and computers, especially in the summer if the AC is shut down during certain hours. 
If you are thinking of monitoring AC current consumption, how many circuits feed your lab?  Are any shared with adjacent offices/labs/hallways? Just a few of the headaches I can think of.
I can not stress enough to develop a design specification.  Feature creep is the developers worst nightmare, as you get bogged down with adding this that or the other.  Especially when people see early prototypes and say... WOW! but can it do this?  Develop this design document, get it signed off and draw a line in the sand until rev 1 is complete and released.

[HEV]

...Some more "parenting advice"...as for the modular code...do some reading at this site:  http://www.idef.com/

Using tools like this will assist in defining the relationships between your modules in your system...if you have multiple developers working on the same project...I would categorize this as a must...this will also greatly reduce the amount of rework when it is time to integrate each person's puzzle piece...it also helps out when you need to change a portion of the system...you can very easily see how it will affect the rest of the system (modules)...