LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

State diagram that monitors voltage and displays at the "same time"

I have a vi that works just fine. It works just fine by itself. I need to, however, have 40 instances of it running simultaneously. They need to all monitor an AI voltage. After designing my vi, as a stand-alone application, I come to discover that my tasks cannot run on the same card, at the same time. I am using a PXI-6225 card for these analog voltage measurements. I have finally resigned my self to the fact that I have to start over and lay this out in a state machine. I am trying to figure out how to make the different states interact to make it seem like I am constantly monitoring all 40 AI signals, yet contantly displaying them (yes, I have a 27" widescreen monitor). Should my states scroll through the maesurements, then go to update the UI, or should I measure, display, measure, display etc... The timing is not real fast, I am monitoring garage doors, not high speed signals or anything. I am tring to build a state diagram that makes sensse.
 
Also, I have set up a task with AI1-AI40. How do I pick these measurements out one at a time, and have them sent to the proper corresponding indicator? Build an array, and then pick them off by index? I am just getting dangerous with this stuff. I know the theory, but the implementation is kicking my butt.
 
Thanks in advance. Y'all have been a huge help in making me dangerous!
Chris
One should welcome adversity as an opportunity to excel.
0 Kudos
Message 1 of 7
(2,895 Views)
Chris,

This seems like a situation where both top down and bottom up design may be appropriate.

You have done some of the bottom up part in getting the data acquisition running.

I suggest that you think carefully about how the data will be used. You mention displaying them (on your monitor which is almost as big as the garage doors you are testing!). Do you need to save the data to file(s)? If so, in what format? Are the displays graphs, numerics, booleans,...? Can the user really perceive and interpret correctly 40 displays simultaneously? Maybe a single Error LED and a "Show me the Problem" button might be more user friendly.

The usage of the data will drive much of the design of the program. A Producer/Consumer architecture (an enhancement of the basic state machine concept) would probably be a good starting point. This would allow the measurements to run continuously in the background at a rate suitable for the data being collected while the display is updated at a different rate.

Lynn
0 Kudos
Message 2 of 7
(2,888 Views)

I can give you a little more info here.

My front panel is such that it is a fill tank indicator that shows the door going up and down. When I get an failure (a timeout for the cycle time of the door) the fill tank turns red and an invisible button pops up over the indicator, letting the technician know there was a problem. This, due to the large monitor, is possible from across the large lab floor. I have already laid out a front panel (at least the geometry for it), that allows all of my indicators to show at the same time, and represent a "map" of the test floor. (allowing the techs to know which door has the issue at a glance).

My front panel for the individual doors is relatively simple.

I have this "base architecture, but I am struggling to implement my VI into it.

 

I need to monitor and display all 40 instances, yet still be able to make front panel entries  / mods on individuals at some points, while leaving the others being monitored.

I do not need to log any of the data. I have a front panel cycle counter that keeps the only information I need. At some point, I will be wanting the techs to be able to log data to an excel spreadsheet, concerning cycle count when reset, but other than that, it's just a matter of realtime monitoring of these doors. I hope this has clarified, rather than muddying the waters.

ALSO, How can I make attachments, rather than pasting these big pictures, on this discussion forum? I know I can look it up, but while I have you on here...

Thanks.

Chris

 

One should welcome adversity as an opportunity to excel.
0 Kudos
Message 3 of 7
(2,880 Views)
Chris,

The pictures do not show up, probably because the links point to your computer. To attach a file (picture, VI, or other) use the Attachment button which is carefully hidden BELOW the Message Body box. After you attach a file, do NOT preview your posting. Doing so causes the attachment to be removed. When attaching pictures please do not use .bmp files because they can be quite large.

It sounds like you have a reasonable front panel layout.

I might handle the data in the program as an array and perhaps make the display a cluster so that one wire can connect data to all 40 door indicators. The array of data is easily saved to a file later. The user can only make modifications to one door test at a time. Clicking on a door indicator could bring up a data entry panel (in some unused part of the screen, if available) with an indicator showing which door test is being modified. An Accept or Enter button hides the panel and applies the new data.

Lynn
0 Kudos
Message 4 of 7
(2,870 Views)

That sounds like a configuration that could work. Here are the pictures I didn't send last time... Am I on the right track? I hope to God I am. If I can't get this working soon my next post may be a resume!

Chris

One should welcome adversity as an opportunity to excel.
Download All
0 Kudos
Message 5 of 7
(2,867 Views)
Chris,

It looks like a reasonable starting point.

Try to avoid using local variables. They are prone to race conditions and make the code hard to troubleshoot and maintain. Direct wires are best. Passing the stop comand to the other loops via a queue or notifier works well.

Also use caution with colored backgrounds on your diagrams. They can reduce the contrast on some wires to the point of near invisibility. I think Ben commented on this more extensively in another thread within the last week.

Your pictures do not show how the front panel controls are being handled. An event structure and a queue to pass the commands to the state machine is a commonly used approach. I often put this in what you have called the UI updater loop. Update indicators, if needed, in the timeout case of the event structure.

Lynn
Message 6 of 7
(2,856 Views)

I really appresiate your help Lynn. The "base architecture" state machine was actually something I got from this forum. I am definitely removing the colors. Now I am just faced with building this thing. Thanks again. I will keep you informed. I will give you your stars tomorrow. I am also hoping others will chime in today, and if I give you stars now it will look completely resolved and no one will reply.

Chris. 

One should welcome adversity as an opportunity to excel.
0 Kudos
Message 7 of 7
(2,850 Views)