How do I leave a "comments" field in my table?

[corelogger]

Hello!

I am using a table in a very simmilar manner as perscribed in this tutorial video: http://www.youtube.com/watch?v=RbDLJ1aaG3E

My data comes from a coil that logs magnetic ocean sediment core sample data. My project is nearly done, but I have one major issue. My table (designated as a control)  has a "comments" collumn so that the tester can readily annotate readings. I'd like for him or her to be able to do this during the lengthy test sequence, which occurs in a while loop. However, this column is unwired (only has input for first four columns) and I believe it is being overwritten as zero at each loop iteration. I can write in the comments collumn, but it dissapears at the next loop. I can write all my comments after the loop is complete, but I fear this would be a waste of valuable testing time. Does anybody have any ideas? I'm fairly new with all of this, so please forgive me if Ive overlooked something obvious. Thank you all! You've been with me for almost a year through this project, whether you knew it or not.

[RavensFan]

Attach your VI.  The video you attached shows nothing about typing values into a control while it is behaving as an indicator.  (I actually have no idea why that person created that video by using a control as an indicator.)

I'm sure there are ways to do what you want to do, (an event structure might come in handy).  It sounds like your use of a control as an indicator requires local variables, and you are getting a reace condition between when the control terminal is being read vs. when data is being written to the local variable.

[corelogger]

If I attach my VI, don't laugh at me! This is actually my first-ever labview project, and I have no background in coding. I'm sure that anyone whos experienced would want to swat me upside the head after seeing my VI. So yes, I know I should be using more "data flow" technique, and I'm sure there are numerous problems, but the program works the way it is now, and there's not enough time to completely revamp it. I'm chalking it up to a learning experience. So here it is! You won't be able to run it without the drivers and sub-VI's, but thanks for taking a look.

[RavensFan]

Okay.  I won't laugh.  It's good if it is basically working for you for your first project.

I'll give you a couple of quick tips that would help.

You have many places where you use local variables to read from a control, yet you have the unused control terminal elsewhere in the code.  You should replace the local variable with the actual control terminal.

You have a chart that is set up as a control.  That makes no sense because I don't know of any actual way that a user could "control" a chart.  It is an object that isn't intended for user input.  As a result, you have the unused chart control terminal sitting unused.  And when you want to send data to the chart, you are writing to a local variable of that chart.  Change the chart to an indicator, then replace the local variable with the indicator terminal.

Many of the structures you used are unnecessary.  I saw a For Loop with a 1 wired to the iteration terminal.  You can eliminate the For Loop and have the same result.  You have an abundance of sequence structures.  Some are necessary because you use the wait primitive to create delays.  But several are unnecessary because the wires from the code in the first frame automatically sets the order of execution ahead of the code that is wired to it in the second frame.  For those structures that are quick and easy to eliminate without changing functionality, getting rid of them will make the code a bit easier to read off the bat.  Other code restructuring might be a bit harder, but should be done when you get a chance to make the code easier to maintain and reduce the size of the block diagram.

[corelogger]

I really do appreciate your advice. There are a few things in there that are vestiges of trial and error. Sometimes I got some things to work, but didn't really know why, and so I just left it the way it was, knowing that something was most likely unnecessary. 

Well, I tried turning the chart into an indicator, but it seems like an indicator can't be edited during runtime at all, so I want able to type in it. So then I tried various uses of shift registers, wiring the last column 4 into the next iteration. The comments I typed still dissappeared at the next write. I also tried puting the chart in my test sequence both before and after the local variable. And I tried using a property node as well. Also many combinations of all of these and more. Iv'e attached my latest attempt. If you have any other ideas, I'd surely  be glad to hear them. If I cant accomplish this, I'll just have to tell my users to add the comments in between tests, which wouldnt be the end of the world. Thanks again!!

[Yamaeda]

In the lower left you have Display Message to User and clear the Raw Data, also in the test-sequence-structure.

Though i suspect it's the test-loop and the insert into array that pushes your comments away.

Some Sub-vi's would make things alot easier to debug. 🙂

/Y

[Yamaeda]

Value property nodes are worse than Locals. 🙂 They have the same functions but are 100x slower. The upside is that they can be connected with error wire if execution order is important.

/Y

[Yamaeda]

Some cleanup (there's still lots to do) and a change in the testing loop, see how this feels.

/Y

[RavensFan · Accepted solution]

I never said to change the table you wanted to add to be an indicator.  I said change the chart to an indicator.

You still have an issue to work out with the table that is a combination indicator and control.

I would try to encapsulate the table so that it is only operated on within the context of an action engine.  Store the table data within an Action Engine/functional global variable.  Use an event structure to detect when the user makes changes to the table.  Send the change to the action engine and let things update within that uninitialized shift register.  Whenever something needs the data within the table, it uses the "read" action of the action engine.  Any time something needs to programmatically update the table, it does it through the "update" action of the action engine.   (This includes handling of the data that is coming from the event stucture when the user tries to change the table.)

I'm not going to guarantee this works perfectly.  But if it was me, that is what I would try to do first so that you don't run into this race condition issue of having a user update a control and the program update a control haphazardly in random order.

I tried to fix some of the thing I was talking about in the earlier post.  See the attached VI and use that.  Some things like adding a 1 to a value can be done easier by using the increment function (+1) from the numeric palette.  When there are multiple AND's and NOT's going on, you can use the Compound Arithmetic node to combine the boolean logic.  Inputs and outputs are individually invertable.

[corelogger]

Thanks guys! Your wisdom is much appreciated. I'm studying up on my action engines now.