jpdrolet

Here is a trick that, as far as I know, has not been published yet. In exclusivity to LAVA.

You can convert to/from any compatible units. Oddly enough, it generates an error when converting to the same unit...

EDIT: OK as usual when converting units I get it the wrong way and inverted the converion coefficient. :headbang: So if you have downloaded the VI try this corrected version.

Download File:post-447-1140315289.vi

I've completed work on a VI that uses the SCC VI's included in LabVIEW to get the latest version of my groups Reuse Library. The VI works great and will be used at the startup of LabVIEW to hopefully keep all our Machines up to date with the latest versions of our reuse code. ( Another Thread in relation to this project is Launching Application at LabVIEW Startup ).

Alright, now for the issues that I've encountered. First, when I build an executable from the VI that uses the SCC VI's included in LabVIEW it does not work as it did when running the VI from within LabVIEW. The issue that It appears to be having is that it cannot find the Source Code Control Configuration settings, and therefore cannot connect to our VSS. This makes sense to me considering the fact that the SCC Configuration Settings are something that is Setup within LabVIEW. But, this leads me to question how we are supposed to get these VI's to function from within our own applications that run from executables. Are these VI's not meant to be used within a Distributed Application? Or, is there a Workaround that I'm missing to accomplish this?

I look forward to hearing your opinions and/or knowledge on this matter.

Thanks In Advance,

Dave Graybeal

If your application is to update your VIs to use them in LabVIEW Environment, why can't you run these VIs in LabVIEW before using the project?

I have not used SCC within LabVIEW recently but maybe you could try to put the application executable in the LabVIEW directory? There it could find the setting where they are expected to be.

Is it possible to run a LabView VI or an .exe automaticlly when Launching Labview. I do not want it dependent on the shortcut that is used to launch LabView. The use case is for sychronizing may reuse librarys with my source code control. Using the SCC VI's in Labview 8.0 I have writen code that will do the sync., I just want it to run automaticalyy when LV is launched, so I know I am working with the latest and greatest reuse VI's. I was thinking maybe somthing in the LabView ini.

In the vi.lib folder, put a VI named lv_init.vi. This VI is called at LabVIEW launch. You can use this VI to launch other executables or any other task.

hi -

i am working on a sub-GUI (displays a tree control) that pops up from the click of a button on the main GUI. Each time it opens, the sub gui generates an occurrance, which it feeds into a sub-vi. This sub-vi continuoulsly runs a while loop containing an event structure that controls the tree. when the user clicks OK/Cancel in the sub-gui, this gui sets the occurrence so that the sub-vi stops and we return to the main GUI.

My problem: the sub-GUI generates the same occurrence on each new run (unless you recompile it). Also, when the sub-GUI is opened a second time, the occurrence still seems to be set so that it stops immediately. Note that i cannot set the "Wait On occurrence" vi to "ignore previous" since it needs to time out every 50ms and would therefore not catch most of the occurrences at all.

Q1: do you know how to generate new occurrences each time a vi runs?

Q2: do you know how to "clear" an occurrence?

thanks. michael.

PS i've attached a simplified version of the vis, but the llb still contains 84 or so vis.

Use notifiers instead of occurences. There are nodes to create new and destroy them as needed. They work like occurences with data attached.

Similar to Scan from String, have unflatten functions a start index in the string and an offset past unflatten. That would simplify and optimize operations on flat data both in speed and string manipulation.

In LV8, unflatten node outputs the unused portion of the string. That prevents to compute the used string length afterwards. Not a start index and offset past unflatten but it does the job.

Here's an update...

There is no access provided to the 32-bit type descriptors in LabVIEW 8.0. NI recommends using the Variant API VIs (which are new to LabVIEW 8.0) located in:

.\vi.lib\Utility\VariantDataType

These are similar to OpenG's LabVIEW Data Tools library (but do not offer any where near the breadth of functionality of the OpenG library). The vi.lib Variant API will likely be extended to support more variant operations (currently there is not nearly enough functionality in this API to be of much use). And, the Type Descriptor interface will likely be phased out; but not very soon, due to the fact that there are a large number of toolkits and other VIs that use 7.x Type Descriptors.

I have flattened a Variant (a numeric) to string to see if the new TD was exposed but it is the 7.1 TD of the numeric that is flattened...

The 8.0 TD is kept private, although the help on type descriptor seems more extensive about 7.1 TD so we could fill some gaps in Data Tools...

- I love skateboarding and LabVIEW!

That is the meaning of G&S :laugh:

sure, just pass the VI path as command-line argument.

<labview version dir>\labview.exe -pref "%l" "VI1_Path" "VI2_Path" "VI3_Path"

Yes but that will open the same VIs for all INI files.

To open both INI file and project VIs I usually use a shorcut with a specific command line.

The file association is not required with this shortcut technique.

Write text in numeric controls: The FormatString property allows to include text in numeric controls. You can set the format to "%f ft" or even "Invalid %f" (if you put enough spaces after the text, the number is hidden.

To display percentage without explicit scaling, for example set the format to "%d %%" and the unit string to "cm/m". The controls stays unitless but the displayed number is multiplied by 100 (100cm in 1 meter).

Each of my projects has its own labview.ini file. I've created different file extensions for each LabVIEW version (.lv7ini, .lv71ini,...) so that when I double click on the ini file the right version of LabVIEW is opened for the project. The action associated with the ini file is <labview version dir>\labview.exe -pref "%l"

Ah, but that assumes you have a named wire of the right type to use in the first place.

[...]

I just wish that there were a better way which is why I spoke out here.

I can't imagine a most convenient way to rename a wire than to use a wire of the right type. Otherwise you'll have to enter names for every member of the structure and need something like a tree or tree menu to provide them.

I don't bother at all to use a typed control to provide type to a wire. I just add a comment "For type only" and the job is done.

I am doing an operation on a VI using VI server. I would like to change the VI's modification bitset to show as changed, so that that user is prompted to save the VI when it is unloaded from memory (and also the VI Name in the window title should have an "*" to indicate that it has been modified). I have experimented with "Begin Undo Transaction" and "End Undo Transaction" and calling these is not enough to cause a "modification".

Anyone know a good way to do this?

Thanks,

When you open the VI reference, do you set the option mask 0x01? From the Help:

0x01 Record modifications. An asterisk (*) appears by the VI title to indicate that changes have been made using VI Server. The VI must be in edit mode for LabVIEW to record the modifications.

If the change you made is still not enough, you could simply rewrite the VI Description property or something like that.

As things work now, many wires (data paths) have a name associated with them. It may be derived from a control label or a constant label or a VI terminal. This is useful if a group of wires having unique names are wired to a bundle node** since it later allows the cluster data to be accessed using an unbundle-by-name node. If however, a wire does not have a name because it has passed through something like an Initialize Array node or if it has a duplicate name then this bundle to unbundle-by-name option will no longer work.

It would be very useful to be able to set (or reset) the name associated with a data path either by directly modifying the properties of the wire (right click option?) or by the insertion of a (tiny) naming node into the wire that would take a name as an argument and change the name of any type of data path that passed through it.

** While it would be possible to use a bundle-by-name node instead, that assumes that the cluster definition already exists. Creating (and later maintaining) the initial definition of the cluster can be, in some cases, more trouble than the job warrants (e.g. temporary data passing through a state machine).

You can use the Type Cast node or the Variant to Data node. Wire your named wire on the type input and the misnamed data on the x/Variant input.

I'm trying to do a quadratic formula .vi I have the equation complete and everything will run fine for real numbers, but when I try to get an answer for the imaginery numbers I can't display it in the indicators all I'm getting is NaN. Any help would be appreciated.

The formula nodes work with real number only and the function sqrt() returns NaN for negative arguments.

You should cast A'B'C to complex and use math nodes instead of formula nodes since they handle complex numbers.

Otherwise you have to manipulate real and imaginary parts explicitely like this (not checked for correctness):

float D;

D=B*B-4*A*C;

ReE=-b/(2*A);

ReF=ReF;

if (D>=0)

{

ReE=ReE+sqrt(D)/(2*A);

ReF=ReF-sqrt(D)/(2*A);

ImE=0;

ImF=0;

}

else

{

ImE=sqrt(-D)/(2*A);

ImF=-ImE;

}

Manfred,

Thanks for the reply.

Unfortunately it didn't work.

I removed the checkmark in LabVIEW like you said. I then rebooted (just in case) and rebuilt the application into an EXE and the same thing still happens.

I tried a bunch of stuff and noticed that the only thing that matters is the decimal point. If I change the decimal in the Swedish region settings to a period everything works fine. If I leave it a comma it goes wacky again.

Right now I'm changing the region of my development computer to Swedish and and then going to rebuild the EXE to see what happens.

Thanks again.

Jack

You don't need to rebuild the application to change the decimal setting since it is an application option that is stored in its ini file. The ini key to force the use of the decimal point is:

useLocaleDecimalPt=False

Set it to True and the application will use the local (swedish) comma.

By forcing LabVIEW to use decimal point, that should solve your problem.

However, the best solution is to revise your code so that your application is independant of the local setting for the decimal separator. Use the format specifiers "%.;" (use point) "%,;" (use comma) or "%;" (use system) to force the separator when it is needed, for example reading the numeric reply from an instrument or reading a spreadsheet file.

Erm, Average Joe?

I'm using the OpenG variant VIs and they're great! However (there's always a 'however') one of the clusters that I convert to a variant contains a huge amount of data. When 'Variant to Flattened String' started running out of memory I realized that there was a problem. Since all I really need is the 'Type String' for what I'm doing, generating the 'Data String' is a waste of resources. Is there a way to directly get the Type String from a Variant without relying on 'Variant to Flattened String'?

There is a 'Type Descriptor' in the properties of a Control Server Class, but I can't create a reference to my variant's since they're only on wires. I've looked at creating a CIN or DLL to do this but I didn't see much in the documentation about how to use Variants although 'LVVariant' is defined in extcode.h. :headbang:

Thanks in advance for any insights!

Arlan Sprague

The only thing you could try is to use Variant to Flattened String without wiring the flattened string output. LabVIEW may be smart enough to not generate the data if the output is not wired. That is an interesting piece of information, please post the results.

I have an I32 vertical slider control (attached) which has non-sequential values running from -2 to 8 but lacking a value for zero. The control produces the correct values and, if you ignore the placement of the slider on the scale, looks right. But the slider itself, in most cases, never aligns properly with the scale. The slider does not move in even increments from value to value. I suspect this might be a bug.

Can anyone else confirm this behavior on their system? Does it work properly in version 8?

I confirm. The behavior is correct if you set the type to double. You may also try to use arbitrary scale markers.

Okay, but what is your point? My suggestion in this thread is to have a notifier/occurence structure or a way to make an event structure act in stead of the wait on occurence function. Since they have a global scope, I do believe it is possible. Does this suggestion make any sense?

You can achieve the same functionality using user events. Create and register a user event to an event structure. Every time you'll invoke Generate User Event (instead of generate occurence) the event node will awake and receive the data. Indeed there could be a mechanism to register an occurence to an event structure but since occurences are rather obsolete and that user events do the job and are more versatile, I don't see the necessity of that feature.

Try to set the string to "limit to single line". When that is set the string will lose focus and its value updated when receiving \n (or maybe also\r)

Well it didn't help. There already out of the race.

Great web coverage. I'm disapointed there's no TV coverage not even CNN Headlines.

Much better race than last year. Thank's for the link.

-WDC

The BBC did cover it

GASP! *faints*

... Also, I am not liking the LabVIEW approach to source code control. The Source Code Control settings are a global LabVIEW setting (configured in the Tools>>Options... dialog), rather than a project setting. Since LabVIEW 8 has projects, why are Source Code Control settings global? This doesn't make sense to me.

I don't know about LV8 yet but the old SCC stored its settings in the default directory so all projects were sharing SCC settings/repository if you let the default directory to be the LabVIEW directory. It was better to have each project with its own default directory (usually the project directory)

Then I change my wish for a "labelled frame" where the frame is not drawn under a transparent label.

Well granted, sort of...

I realized that when the label colors are set to <anything>/Black, the label background takes the color of the underneath panel. It was by accident, seeing the application run on another machine where some labels had the correct system colors...

Yes, you are correct. I've been throught this exact dilemma before. There is no object (decoration) that mimics the WinXP themes stuff. This is a real wish, to tie-in somehow to the winXP skinning.

Then I change my wish for a "labelled frame" where the frame is not drawn under a transparent label.

Thanks PJM.

However, the system tab color seems special in the sliver theme. The color is not uniform, slightly darker in the bottom (see my previous post) so there is no single color one can use to put a label over the decoration. The solution to use a normal 2D tab colored with object/panel color seems to work well but for the sake of uniformity I'll have to change all tabs in my application.