GraemeJ

QUOTE (Aristos Queue @ Jul 15 2008, 04:25 AM)

True. But several of the style tests have the effect of improving performance.

Here are some VI Analyzer tests that can find performance issues:

• .
  
• Enabled Debugging—Checks whether debugging is enabled or disabled. Disabling debugging improves VI performance.
  

In my original post, one of the things slowing down the code was that debugging had been left on in Simple Error Handler.vi. When the main.vi was checked with VI Analyser, this was not detected (LV 8.5).

Regards, GraemeJ

Is there a way of measuring code performance? In particular, can the performance of blocks of code within a vi be compared with one another?

The background to this question is that (and this is my first LV program) my code is a monster bowl of spaghetti. From previous advice from the forum, I am aware of one inefficient section but the performance was then OK. Now that the code has grown, it has slowed down and I would like to isolate the problem.

Regards, GraemeJ

QUOTE (Yair @ Jun 30 2008, 04:19 AM)

That's because it was a quickly written example and it simply has a bug. I'll leave it to you to debug this, but I'll hint by pointing at the bottom shift register. If that doesn't help, you can enable debugging on the VI or make it non-reentrant and then use probes to understand what's going on.

Thanks for the tip – bug fixed. However, I have yet to fully understand all the subtleties of your Buffer.vi : part of my continuing education.

GraemeJ

Hello Yair,

I was tempted to describe your vi's as 'elegant' but I guess that is too formal a word to use in a post.

Functionally, your code will suit my application but the user is expecting to see an XY graph with data plotted incrementally from the origin, rather than a chart. In addition to a plot of a single channel of data I also wish to simultaneously include incremental plots of both a smoothed data curve plus the sensor model response curve. .

I have not been able to work out how you made an XY graph operate like a chart.

Because I am new to LV I do not have an intuitive idea of the memory allocation due to increasing array size. Could you comment further?

A problem I have had with your vi [using LV 8.5] is that it will only run once and has to be closed and restarted for the next run.

Regards, GraemeJ

Hello mballa,

Thanks for your interest.

Data is being acquired by a sensor, plotted on a graph to confirm to the user that the data looks OK, eg. the sensor is working correctly etc., and then further information is derived from the data in the balance of the program.

In the first use of the program I know that the data is collected at 10 Hz for 60 secs but this may not always be the case and I would like these parameters to be user controlled (which would include control of DAQmx Read).

There are two reasons for trying to use a buffered plot. The first is operator boredom. Rather than have the user watch a blank display while the data is collected I have tried to have the graph plot change incremetally in one second increments. The second is a fuctional one. The data is used to model the response of the sensor and derive the equilibrium voltage (which can be a very long time – 45 min). While it has already been established that 60 secs of data can produce an answer, the buffered data should allow this to be done dynamically and establish when equlibrium is within a tolerance range before the full reading has completed.

I would appreciate any comments you may have.

Regards, GraemeJ

The attached vi incrementally plots data on an XY Graph while retaining the earlier plot. As written, data is plotted in one second increments, for a total of 60 seconds. This suited the application in which it is to be used but it would be much better if this could be controlled programmatically. I would welcome help with this or any other comments.

The code generated data option was added as an afterthought and is only there for demo. purposes.

The essential piece of code is an extract from a previous post by Becktho on 04-06-2006 (cannot find the thread). The vi was simulation_graph_1.vi and I would like to give my thanks for that help.

Regards, GraemeJ

Sorry I may have been a bit vague before - LV will perform code for SRTM App Events, but if you need to capture these events for other reasons then you need to use Shortcut Menu Selection (App) not Shortcut Menu Selection (User).

Many thanks indeed jgcode,

that solved the problem and I am most grateful for your help. The user being able to enter data in the table is an issue

and I will use your suggested solution.

Thanks again, GraemeJ

Thanks jgcode,

Still in trouble. I have not understood what LV is trying to achieve with the RTSM: with the default menu, eg. 'empty table' seems an unambiguous requirement which would have had prewritten code, as is the case for much of LV. However, 'empty table' is also a custom app. which requires code to be written.

Attached is my current code. As always, would appreciate any help.

GraemeJ

Hello jgcode,

Re: Runtime Shortcut Menu

Thanks for your advice. I have got it partially running, but am still in trouble.

For "copy" and "description and tip" each case operates correctly. When either if these is selected in the RTSM,

a probe on the selector terminal for these cases within the event structure shows the correct Item_tag, and the

case is then processed. For all other Application Items eg. 'empty table' or 'delete row', the Item_tags do not appear

in the Event structure.

I have not been able to figure out how to step through this bit of the code to see what is happening.

Any further advice would be much appreciated.

Regards, GraemeJ

Thanks Orko,

Your suggestions worked fine!

Regards, GraemeJ

I am fairly new to Labview and am in trouble with the attached vi. The purpose of the vi (part of a larger scheme)

is to let the user measure a series of chemical standards, and then derive a calibration equation from the data. The user

would enter data in a table, edit the data and then store in a file.

The problems I am aware of (and I imagine forum members can find plenty of others) are:

- Write to Text File: data is correctly written to the file when LV is first started and the vi run, but even this is not

consistent. Sometimes the file remains blank. Having run the vi once, on later runs the file is not cleared

and new data has not been able to be subsequently written to the file, even though the new data and the

path are present at 'Write to Text File' on each occassion.

- Run time shortcut menu: a custom menu for the table, made up from application items, has been saved as a file

in the same directory as the vi. When running, the menu appears, but no action occurs when a menu item

is selected. I had assumed that no further code was required. If code is necessary I would appreciate

some help in getting started.

Any advice would be very much appreciated.

Regards.

Sorry, wrong attachment: try again