LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Building a table from a N dimension array with Timestamp data

Hi, I am trying to use LabVIEW to collect plant downtime data. I have created a vi that opens if a certain time limit is breached and records the length of time that the tags are above this limit, thus measuring the length of downtime. Whilst measuring the time above limit, a ring control prompts the user to enter a downtime reason from a pick list and into a text indicator. Please see attached vi.

I am trying to get the last selection from the ring control to show in the text indicator, and upon clicking of "OK" I would like to log this data to the table shown below with both start/stop timestamps and length of time (in secs). I am having trouble organising my text arrays and wiring to show this data in the table.

Any guidance/quick fixes on this particular problem is greatly appreciated.

Best regards,

Stuart

0 Kudos
Message 1 of 6
(3,156 Views)

Stuart,

Your program has major dataflow issues and cannot work in the current form. Could you explain in more details how the program is supposed to work from the user perspective?

Here are some flaws I noticed just glancing at it:

  1. The inner WHILE loop in the upper code part can never end because the comparison is always false. It will just keep spinning as fast as the processor can until the entire program is killed. Notice that there is no new data ever on the inputs because "read multiple tags" is outside the loop and never executes again. You need to place a resonable small wait statement inside the loop and you must also ensure that the wires for the comparison operation are updated with new data while the loop runs. You might need ot add the tag reader subVI inside the loop.
  2. You have three ring controls that each show a selection. Does one of each need to be selected for each downtime? Why is there no selection for e.g. "no mechanical problem"?
  3. Why do you built all three into an array that grows by three elements every 100ms. Forever! Ultimately gobbling up all system memory. Shouldn't it only grow whenever an event occurs? And then only by one reason?
  4. The shift register probably needs to be initialized with an empty array.
  5. Stopping the lower loop will not stop the VI because the upper loop might go on forever. Is this VI suppose to keep runing with the FP closed?
  6. ...

Please clarify operation before I look into this in more detail. How is this VI called? How does it stop?

Message 2 of 6
(3,136 Views)
altenbach, many thanks for the help so far.. answers to your questions below should make my problem a little clearer:
 
  1. Thanks for pointing this out - should have noticed that one!!  I have updated my vi (attached) to include your suggestion.
  2. You have three ring controls that each show a selection. Does one of each need to be selected for each downtime? Why is there no selection for e.g. "no mechanical problem"? Only one down reason can be given for any downtime event, so only one reason from all 3 ring controls can be given.  I have seperated the 3 menus for a more user-friendly data entry, and i would like the string indicator (labelled by "Reason Selected:") to show whatever one reason has been selected.  Then by clicking "OK", whatever reason is in the string indicator will be the recorded downtime reason.
  3. Shouldn't it only grow whenever an event occurs? And then only by one reason? - YES!  How do I do this?
  4. I have initialised loop with an empty array in updated (attached) vi.
  5. No, it is my intention to close this vi once data has been entered.  Summary of vi function below...

I have a parent vi which monitors the plant performance day and night.  It is currently recording production times.  When a certain production time is recorded to be excessive (ie. above 60 seconds) the downtime codes vi is called and asks the machine operator for a reason.  He/She picks the reason from the Mechanical/Electrical/Process menus and the reason is added to the string indicator acting as a selection box.  If the operator is happy with their selection, he/she hits "OK" and the reason is logged to the table below. Once the tag data is under 60 secs, the table should be updated with timestamp & downtime data and the vi should automatically stop and close.  Going back to the parent vi front panel.

Is this possible?  Any guidance on how to create this properly would be an extremely big help.

Many thanks for your continuing support,

Stuart

0 Kudos
Message 3 of 6
(3,111 Views)

Hi Stuart

 

I have been looking at your vi’s I have written a vi for you concerning the ring controls and building the string and adding it to the table it also deals with the problem of continually building the array till you run out of memory.

 

You might want to consider putting this in to an even structure which is triggered when your 60s down time limit is reached.

 

You also might want to look at the even tracking example From LabVIEW example finder. This just monitors events if you don’t do any thing a time out value is passed in u do it list it.

 

Hope this helps

 

Tim Matthews

Applications Engineer

National Instruments

http://www.ni.com/support

0 Kudos
Message 4 of 6
(3,067 Views)
Thanks Tim, that is a big improvement and very close to what i am looking for, however your vi selects one reason from each list to be included in the string (i.e. one electrical, one mechanical, and one process). There can only be one reason in total. The reason is either electrical, mechanical or process. Within each of these categories only one reason can be selected. Can your vi be edited to control the vi so that only one downtime reason is given? I'm sure this is a simple change, but I am unsure how to go about it. Many thanks for your continuing support with this, Best regards, Stuart
0 Kudos
Message 5 of 6
(3,058 Views)

Hi Stuart

 

Well a very simple way would be to add a blank space to each list and set it to default. This would be the simplest and quickest way. If you don’t want to do this then it actually get quite complex and you have to start looking at event type stuff and blocking the other two once you select one. Or having three Reason boxes and three ok buttons would be fairly straight for would but might make your front panel a bit cluttered.

 

Regards

 

Tim

0 Kudos
Message 6 of 6
(3,042 Views)