jgcode

Curry was OK, nothing special just some takeaway from the local, could have been a bit spicier. I made Beef Rendang the other day that was damn good, poked me right between the eyes.

My wife makes a mean curry, her Father is a genius at them.

His special is a bacon bone curry that literally blows your head off.

I did not eat heat/spicy food growing up so I am easing myself in

I also do not understand why someone would want to eat something like that!

Although I think the bacon bone is coming up for me, if I make it through that then I am really considered family

I always go with option 1. However as this is a typical FGV (Conditional Stop always TRUE) and not a MFVI/module (Conditional Stop determined by logic) as Daklu mentioned if it only iterates once then it probably does not matter.

But with a MFVI - I saw some unexpected behaviour on RTOS with arrays that was seemed to be fixed going from Option 2 to Option 1 model.

I guessed that on every iteration of the loop, the array is being re- read and possibly a new allocation is made???

I too am interested to know what is happening at the memory management level on multiple iterations.

FWIW: I also put the command enum outside the loop as well. In fact even for SubVIs I put all controls on the left inline, and all indicators on the right inline for neatness/readability as well.

No prob mate

Just having a beer waiting for a curry, I can squeeze one out.

Have a play with this.

SpawnFP.zip

Sweet, got it to go - I had a bug, dammit (amateur mistake of releasing a ref) so the observation I made above can be ignored.

Thanks heaps for the post, really like the way you case out the VI.

Better than using a static ref because the VI will be in the build AND as you mentioned the Top Level will become broken.

Also playing with the build in LV8.6.1

Running the build errors when Spawn button is pressed complaining the VI is not in memory.

I figured this may be from the constant folding of the casing out and LabVIEW being smart - so I changed the constant to a control defaulted as false, re-built and it works. I guess this has changed from the version you are using and thought it may be of interest if you didn't already know?

Enjoy the curry! (is it homemade?) - for brunch yesterday I had takeout Dosa Masala and Purri's with potatoes. :YumYum:

Cheers mate

JG

At JKI, we currently are able to do UI testing using VI Tester and are running these tests to validate certain VIPM features. Adding UI testing capabilities to VI Tester is on our roadmap.

Hi Omar

This sounds extremely interesting! Are you able to elborate, give a sneek peek or show us a demo vid (jing)?

Cheers

JG

One trick you need to be aware of is that LabVIEW will strip the front panel of any vi unless you have the vi property "Show Front Panel When Called" set to true or you have a property node of a control in the code.

Hi Kurt - I tried the above but no luck - do you have any examples?

I still cannot seem to get two FP in memory at the same time. Lets say I spawn two re-enetrant VI's and open their front panels with Show Front Panel:Property Node. If both are instantiated at the ~same time (i.e. using For Loop) the FPs open but th VIs don't run (observing run arrow). If I use a delay, the first runs correctly, then the second runs correctly, but the second one stops when the first spawned VI completes execution.

As far as I remember: In LV 7.1 only method 2 works.

This is the only way I can get it to go in LV 8.6.1 as well. In order to create two independent FP in memory.

Seems re-entrant VIs share the same FP memory (mentioned in below post).

I did find some more info from searching here, here, here & here

One trick you need to be aware of is that LabVIEW will strip the front panel of any vi unless you have the vi property "Show Front Panel When Called" set to true or you have a property node of a control in the code.

Hi Kurt - thanks for your reply.

I have noticed the "do not delete" comment for a property node for a control whilst trolling through some of your old code here

I was trolling through NI's code documents when I saw this post and it got me thinking:

Which is the better way and why, to have multiple instances of a VI's front panel in memory at the same time.

1) Spawn (and specify re-entrancy on open ref node: 8) a re-entrant VI and invoke open front panel method OR

2) Spawn .VIT template

I was under the impression the later is the way to do it. The user mentions in the post a problem with loading, and the need for a wait in the for loop.

How does LabVIEW handle each approach (with respect to memory allocation?)

Cheers

QUOTE (candidus @ May 25 2009, 05:19 PM)

Hi,

the error message contains useful information about the problem:

---

LabVIEW: One or more untitled subVIs exist. This file cannot be saved until all dependent files have been named.

Method Name: Save:Instrument

---

When you instantiate your VIT it instantiates the templates it owns. You can't save your template instance before

you save its callees. Rewiring of the "Build Array" primitive puts things in right order:

First the callee, last the calling VIT instance.

I didn't try that (obviously)

I didn't think the order would matter as long as I kept the reference open.

This worked for standard VIs but not ones that called .vit/.ctt files

Thank you so much for posting!

Cheers! :beer:

[Cross-posted to NI Forums]

Hi

I have VITs that call other VITs or CTTs in some of my templates.

I want to programmatically open a reference to a template and save the new VIs/CTLs to disk but I am getting errors

My code works fine for any VIs or VITs that only call other VIs or CTLs.

However if the VI or VIT contains calls to other VITs or CTTs then it fails.

When I try to get a reference to the new VI or CTL in memory the reference seems dead?

Can anyone point me in the right direction?

Cheers

JG

Download File:post-10325-1243008955.zip

Coded in LV8.6 and Saved for Previous Version in LV8.0.

QUOTE (Karissap @ May 18 2009, 03:39 PM)

Hi,

I have a front panel with a vertical splitter bar with a lot of controls on the left pane that can be scrolled and some buttons on the right pane that I don't want to scroll with the rest of the controls so they are easily accessible. I wanted the user to be able to print the left side of the pane somehow. Whenever I try I can only get a cut off picture of the whole thing so some controls aren't visible in the print out.

Here is an example of what I have so far in LV 8.6. (I'm using the report generation toolkit)

Hi Karissa

There seems to be a bug? where using the FP.Get.Image method with a splitter on the panel as it does not return the entire front panel (when Visible.Area.Only is toggled it gives the same result?) without a splitter it works.

My only suggestion is to take the image subset as attached but expand the panel programmatically first to the lowest control to include all controls??

http://lavag.org/old_files/monthly_05_2009/post-10325-1242652061.png' target="_blank">

Cheers

JG

Hi

What is the standard practice for testing source distribution code:

Should I write tests cases for source code OR source distribution code OR both?

I can see issue with either choice:

Source only - you want to test source to pick up any errors before you make it into a source distribution but...

Distribution only - distribution may apply name changes and in case of an error with dependency code that meant the source was ok but the distribution isn't

Both - best coverage, but redundant tests case, changes mean updating code (tests) in two places (due to re-naming etc..)!

What do you guys do?

Cheers :beer:

JG

QUOTE (normandinf @ May 13 2009, 10:07 AM)

I've noticed that a lot of newcomers on this forum are already using LabVIEW 2009... (or so they say )

I feel I've been left behind...

Dude I don't even think its out yet.

Major release are done at NI WEEK.

This is a major release.

The only place I have seen its name is on Darren's Blog.

Unless I, like you, have been left behind!!

The CBR node "blocks" the thread its in i.e. the called VI must complete execution before returning its outputs (which obviously makes sense) through the node.

With the Run Method you have the option to spawn a new thread.

However in the app when a new plugin command is generated, it has to unload the first VI, wait for notification from it that it has completed running (last thing it does before it goes out of memory), then launch the next plugin VI.

Otherwise if you don't wait you have potential race conditions.

Aside from passing data into out of a plugin VI, the CBR node is handy in the fact that it sequences the code.

And you can easily standardize a connector pane; Either Variant In/Out at top and Error In/Out at bottom.

This will maintain any new data added to your application.

Or you could have simply Error In/Out for each VI and load/read data from a shared resource FGV/GOOP/File etc..

But the cost of the CBR is usually another loop I have to maintain, so I am with others, and 95% of the time I spawn the VI using the Run Method.

Thanks everyone.

Very much appreciated

Will look at all the above, make some changes and let you know

Red File = Red colored class in picture - is a file format of a KKD File

DP & For = Displacement and Force - is a processing method of a file but is not tied to a specific format.

Class Hierarchy

KKD File as Parent

Red File as Child of KDD File

DP & For as Child of KDD File

Problem

I want to select a file format e.g. Red File Load File Method then call a processing method e.g. DP & For Process Method

Essentially I have different file types AND I have different processing methods for files.

Both operate on KKD File Class (which contains the data) but I want to be able to choose the format AND processing method - not have the processing method tied to the file format or vice versa.

I tried to downcast to the parent then upcast to the processing method?

The above generates an error (due to dynamic dispatch I guess) but is there a way to do this?

Can I jump through the hierarchy like this?

Can I code the above somehow?

Or can anyone suggest a better class hierarchy?

I was trying to avoid a separate independent class as both classes operate on a File so I thought they should inherit from KKD File and be siblings?

Any suggestions?

Cheers

JG

sh..are you can??????

Sorry couldn't resist

QUOTE (Chris Davis @ May 5 2009, 07:25 PM)

I'm finding that spending time on our reuse libraries, and using VIPM to package and distribute them, even between two people, has saved us time (and thus money) already.

Amen to that and to OGPB.

QUOTE (mesmith @ May 5 2009, 08:41 PM)

OK - I saw JGCode beat me to the punch but I'll post this any way!

Good summary tho!

Also MGI VIs can take any data - it does not have to be cluster.

We use XML configs a bit e.g. for RT when the user does not have to see the contents of the file.

I.e. like in the cRED.

Maybe this toolkit would be good for you to clean your XML so it is human readable?

If there is no constraint for the file to be human-readable (which was not mentioned) then you could also use datalog files.

But I preferred the auto-conversion features of MGI and OpenG VIs for most apps when the typedef changes.

However, another thing I am currently playing with is config/file versioning.

I.e. setting data to default is ok sometimes, but other times it might be more appropriate to insert a known value and alert the user that the defaults have changed.

The idea being that on an upgrade (i.e. new release to client) these files can be read back in and handled appropriately if the file structure changes to the new version.

The old file or section then gets re-written in the new format.

Plus old keys are cleaned up.

This is used only if it is appropriate for the application.

All this happens within a class so its nice and encapsulated.

The only thing to do is save out the typedef and version it on Release in my project so that is does not ever change.

I kind of set it up like how an XControl reads its Library Version and acts appropriately on running init ability.

QUOTE (dblk22vball @ May 5 2009, 08:11 PM)

I am looking to pick the brains of the LAVA members on how they deal with config files and/or large initialization files.

Is there another method that you have used?

Thanks.

By far the easiest way is MGI or Open G solutions.

The hard work is already done for you!

When working with classes I currently like to do this (props to MGI).

This way makes a lot of sense to me.

Both sets of VIs are elegant solutions for any size application - Get VIPM to install both!

The only time I do what you have done is on a Windows CE (last time I used it on a TPC config VIs do not work) and when I want to write my own style or format of file.

I recommend this book: Oldie but a goodie. There is some interesting ideas on config management.

A Software Engineering Approach to LabVIEW (National Instruments Virtual Instrumentation Series) (Paperback) by Jon Conway (Author), Steve Watts (Author)

But unless it is a requirement then why bother - use the above VIs!

I currently write to multiple files for config data.

One thing I am currently looking at is protecting the config file if I want multiple classes to read and write from the same file.

Obviously using different section names - but I mean the problem is config files can be opened and manipulated by simultaneous read/writes!

I am still playing with this but thought I'd mentioned it and am looking forward to what others say!

QUOTE (asbo @ Apr 16 2009, 11:11 AM)

Decidedly off-topic, but the first thing I thought of after reading the title was http://www.youtube.com/watch?v=qRuNxHqwazs' rel='nofollow' target="_blank">this.

lol :laugh:

QUOTE (JustinThomas @ Apr 8 2009, 12:57 PM)

Hi Scooter X,

You can use a cluster with one string and one numeric for each racer build an array of this for your data. Clusters allow you to keep different data type elements together.

As far as the sorting goes I am not aware of any ready made functions for sorting a cluster. You may have to write custom code for sorting your cluster, but should not be very challenging.

Justin Thomas

You can sort a 1D cluster array with the native LabVIEW function.

QUOTE (flarn2006 @ Apr 6 2009, 10:11 AM)

I recently upgraded LabVIEW to 8.6, and I noticed that the Tank indicator has gone missing. It's always been there before, but now it's just an empty space in the controls palette. What's going on?

I have it in 8.6.1

QUOTE (Kal @ Apr 4 2009, 04:17 PM)

In one of the example VIs they say that you cannot use internal timebases for clock and should be supplied 'externally'. I guess this means you will have to give the clock signal to one of the PFI lines of 9411. Internal routing (which is the case when you use cDAQ1/ai/SampleClock) may not be supported.

Thanks Kal. I was told by NI Support that this configuration is correctly setup to use an external timing source - i.e. the clock is supplied by the NI 9237 module.

Are you saying this is not an external clock?

QUOTE (Kal @ Apr 3 2009, 07:00 PM)

A quick check can be to replace 'cDAQ1Mod1/ai/SampleClock' with 'cDAQ1Mod1/ai/SampleClockTimebase'...

Unfortunately both gave the same results.

Cheers

JG

[cross-post to ni.com]

Hi

I am trying to setup a buffered counter acqusition (correlated) using compact DAQ.

Hardware: cDAQ 9172 chassis

Slot 1: NI 9237 (AI Bridge used as an external timing source only)

Slot 5: NI 9411 (High Speed DI TTL)

I have to use the extra module to export it's clock as I am using the internal counters in slot 5.

1) Is this hardware compatiable?

2) If so, any suggestions on how to get this to work as I am having trouble running it.

I use the following parameters which works fine for an On-Demand sampling - it reads back the expected value from the sensor.

But when I switch to Continuous the I get a timeout error.

However, if I use simulated hardware through MAX I don't get an error and the buffer fills on the screen.

Any ideas?

Regards

JG