gb119

I've just discovered something slightly curious about the palette file API vis in newer versions of LabVIEW - they do not appear to the same thing as editing the palettes by hand.

In 2010, add a .xnode file to the palette manually and it will show the icon of the help ability vi and the name of .xnode file as the text. Now using the palette file API vis, read the same palette file and then write it out again and refresh. Now the palette files show "Help" as the text and not the XNode's name.... (at least for meon 64 bit 2010). Ho hum. I guess the palette file format must have been updated and the API vis haven't.

I've released a new version (0.22.1) that cleans up a few bugs and adds a couple of features that I needed to help write XNodes based on a templating approach more easily and quickly. I'm currently working on converting OpenG Array tools to XNodes using this toolkit (which is why I've removed the dependency of Scripting Tools on OpenG array tools !) so that they are not limited to just the types for which polymorphs have been provided but will work with any suitable array type. There is an initial release out now.

Name: OpenG Array XNodes

Submitter: gb119

Submitted: 26 Apr 2011

Category: XNodes

LabVIEW Version: 2012

License Type: BSD (Most common)

Click here to download this file

Additionally for user friendlyness: Help Ability should have the same Icon as the Xnode, that is displayed in a Menu Entry of your palette. You can write a short Help Info by typing the description of your Xnode into the description of your Help Ability VI.

Interestingly this is only true in LabVIEW>=2009 - in earlier versions the library icon was used in the palette. Oh well, that's what one gets for messing with unreleased features...

Hi,

I am new to labview and learning in slow phase. I have a doubt regarding String to number converstion vi's. why it is not converting hex string to number and it is giving zero as result. Can nay one help what is reason.

I think the source of your problem might be the type cast: you take your string containing a hexadecimal number and convert it to a number. This number is a signed 4 byte integer that happens to contain a number between 0 and 255 - i.e. the first three bytes of the int are zero and only the last byte has real data. You then convert that to a unsigned byte integer array with the type cast - so now you have a four elelement array [0,0,0,64] - hence you have some leading spaces ahead of the @ ASCII character. If you feed it 4 byte string of hex numbers then the intermediate signed 4 byte int won't contain any leading 0 bytes and so you don't get leadin \0 in the output string.

Moral of the story is that the type cast operator is almost always the wrong thing to use unless you are sure that it isn't.

If you want to display a string as a series of hex values representing bytes for e.g. a user to edit or inspect, consider using an array of U8s with the display format set to display in hex and then just use the [u8]->string primitive that you already used.

Cheers, all seems good now.

Gavin

Please try now. It's fixed. There was a glitch due to the recent server upgrade.

I cannot get the latest version of scripting tools package to install in LabVIEW 2010. I am not sure if this is a package or a VIPM problem. I suspect it is a package issue at present and somehow involved with format release of scripting. Is there a way to find out what the auto-conflict is referring to ?

I will force the install and see what happens

EDIT unselected the auto-conflict and installed in 2010 but did not load as expected

Dannyt

Ok,

I've got another rebuild that installs cleanly (for me anyway) on LV2010 64bit. Unfortunately the Code Repository file uploader is being funny and not letting me upload the file right now.

Edit: Code Repository playing ball now. Version updated. Any reports problems installing on LabVIEW 2010 or 2009 happily accepted.

Ok, now I have a new problem that comes under the topic heading. The file uploader is failing to upload my files... I select the file on my computer, I get the progress bar and then it comes to the end saying that the upload failed. I've tried Firefox and IE8 and also checked that it doesn't make a difference whether I access the local file via system Library or direct path (Win 7 64bit). So now I'm a bit stumped for ideas.

Unfortunately, the VIPM package does not work in LabVIEW 2010, I suspect this is due to the formal release of scripting so I cannot install (due to conflicts) the package lavag_scripting_tools >= 0.21.0.0 which is seen as a dependency by the xnodes package.

Have you installed the Scripting tools package from http://lavag.org/fil...cripting-tools/ ? That should provide the missing dependency (unless I've screwed up the packaging).

Are there plans for a 2010 release some time

Also does anybody using these function have any comment about performance.

I'm not using 2010 in production, although I've got it installed and as far as I know the scripting tools package works on it ok. With the release of scripting to the general public the need for the scripting tools package is rather less - they just wrap some scripting calls up a bit more neatly. I have seen some problems getting the custom palette to install correctly with some of these packages

Performance wise, the XNodes just generate static G code - all the scripting happens in the editor, so the resultant code should be close to what you would achieve with a sub-vi with the equivalent diagram to that generated by the scripting. There is a performance hit on the editor and compilation stage - especially when changing wire types and causing type propagation through the diagram.

No WAY!!!!

I always thought that if I make an average of a Sine Wave.. I would get Zero… or something as close as zero as possible….

Gb119, I apologize because I actually thought that you were Crazy at first but it actually works… and works perfectly…

This method is awesome… I wonder what’s the math behind this… are you guys warlocks or something??? Is it witchery???

No, just an experimental physicist. Hmm, on second thoughts, in some places and times, the two would be more or less the same thing !

The maths behind phase sensitive detection is quite simple really - I teach it to my undergraduates when I explain how a lockin amplifier works. Basically if you take the Fourier transform of your input signals then you end up with a bunch of sine waves at different frequencies, each with their own amplitude and phase:

S=a_0+a_1 sine (w_1 t + f_1) + a_2 sine (w_2 +f_2)+...a_n sine (w_n t +f_n)

When you multiply by a sine wave of known frequency w_r you can use the rig idenity:

sin A sin B = 1/2(cos(A-B)-cos(A+B)), for each term in S where w_n!= w_r you are going to have terms that involve cos (something t). Averaging those over time and indeed you get zero. However, the one term for which w_n=w_r, you are going to get:

1/2(cos({w_r-w_r }t-f_r)-cos(2w_r t + f_r)) which averaged over time gives 1/2 cos f_r.

Do the same with multiplying by cos w_r t and you get 1/2 sin f_r time averaged and you're away.

I suspect without thinking too hard that your x2 is just correcting for the factor 1/2 that comes from the trig identity.

Just a rough scetch of a different idea. Using an anlog oszilloscope, you would use the 1st signal for the X and the 2nd signal for the Y channel. If both are sine signals of the same frequency with a phase difference, you'd get an ellipsis. Then get the distance between the crossings on the X-axis and the Y-axis respectively. I don't remember the exact formula, but I think the phase was simply sine of the ratio of both, easy math I did at age 17.

If you apply this to the signals you have, just get all crossings of the signals at 0A and take the value of the other signal.

Does this still work if the amplitude is also varying with time ? I guess if you do lots of measurements and average over time it's ok...

Ok, first of all i want to say that is my pleassure to have this trouble and to have to fix it my self, so i don't want to sound like those students that actually want their homeworks done... it is just that perhaps i need another point of view ...

So here is the deal, i have a 3-phasic electric system, of currents, the currents came out from a filter so, ignoring the response of the filter, i have to meassure the phase angles between them...

i know there are downloadable modules to do this, but the fact is that the time they use to meassure things like RMS values or else... it is a trouble cuz i have this response in my signal

anyway... that's my case... sorry about my bad use of english...

but i'm mexican, and even if i try i do not, i repeat, i do not speak english... so greetings..

If you know the frequency of your signals then you could emulate a two-phase lockin in software. Take a section of your signal with say > 20 periods in it. and make two copies of it. Then for each of your three phases, multiply one sample by sine and average it and then multiply the other sample by cosine and average it. Take the two averages for each phase, feed them through a two input inverse tangent and get the phase ang;e for each phase (referred to an arbitary angle, but you are only interested in the difference between these angles). Although your singal may not be stable over the period you sample it over, so long as you use the same sample for both sine and cosine multiplications it should be ok.

If you don't know the frequency then you can probably extract the information from a fourier transform of the signal, finding the biggest peak in the appropriate frequency range for your expected signals and then useing the ratio of the eal and imaginary parts of the FT to work out phase angles.

This all assumes that I've (a) understood the question and (b) not had a brain storm.

It obviously still makes a copy of the data to the FP Object (rather than being related to a graphical update) just like any other.

Yes, but Why? I mean, I can see why FP controls that change their appearance need a copy of their data, but if the control doesn't change appearance why does the FP control need any data at all (other than type information obviously !) ?

Actually that might be an interesting idea for debugging dynamic dispatch calls - if the FP controls and inducators changed appearance depending on the runtime type of object they were being passed. Then there'd be a good reason to pay for getting a copy of the data....

However, if you leave the front panel in memory, you'll take the performance hit of updating the panel controls/indicators. So when you modify the VI to turn off dynamic dispatching, make sure that you close the front panel of the Write Boolean VI and then do File >> Save All before you run the performance test again.

Hang on a sec, so if I have a vi with only class object controls and indicators and leave the FP open, I take a performance hit updating the controls and indicators that don't change appearance by one RGB value of one pixel ?! Ouch.

In the same vein as Shaun, and beginning to push the off-topic envelope further, I get concerned when I hear about OpenG and other 3rd party tools seeming to become "coin of the realm". Yes, I'm an oldline LV hack (and an older line C/Unix hack -- and I DO mean C), but I don't like having to rely on 3rd party tools that are tied to certain non-NI implementations. For my purposes it works far better to use only NI "tools" and, no, at this point I haven't found scripting to be directly useful; so Shaun that club has at least doubled in size.

I'm not sure I really understand the problem here. With something like Vi Scripting I can see that there is a point as to whether it's useful to a develoipers other than those writing tools to run within the LabVIEW IDE (and XNode authors). For something like OpenG which in essence is just a bunch of straight G code that you can download, keep your own copy of and (since its BSD licensed) redistribute as part of your product, it seems to me that one is not dependent on the third party at all after the initial download. I don't see the qualitative difference between OpenG and say a manufacturer's instrument driver (the quantitative difference is that I'd trust OpenG to be written in sane LabVIEW ). There is a valid argument that expecting everyone to have VIPM and to be able to download and install VI packages is an ask, but on balance the vbenefits to my mind outweigh the hassle.

Releasing XNodes might be a bit like XControls - they're not something that every user will immediately want to go out and make use of, but they are a good way of handling reusable, type agnostic code without having to write huge numbers of polymorphic vis or use clunky to/from variant conversions.

Personally, I think that XNodes could be the next big thing we push NI to release officially. I mean, look what we did for scripting. We could start by creating more examples that use XNodes, and maybe clean up the documentation a little on the LabVIEWwiki. Anyone with me?

Certainly would be nice to have XNodes made "official". One thing that would be nice to do would be to write a reference example XNode that showed off as many features as possible in properly documented code.

I'm intending (as time permits ) to reimplement the OpenG Array tools as XNodes so that one doesn'thave to have loads of polymorphs for each and every type of array.

I really like that icon. I vote we use that as the palette category icon.

Umm, we already are....

If you have a look at the Scripting Tools and Array XNode packages you'll find that they install a LAVAG category with Daku's icon. I've not put them under a sub palette for the LabVIEW API yet, but I've used the LAVACR sub category icons for the palette icons for each package. If someone want to show me how to make a vipm package use a sjared second level of palette below the category then I'd be happy to move everything down one level in the hierarchy:rolleyes:.

For the package names I've gone for lava_lib_<lavacr category>_<package name> - or at least that's what I'm iterating towards...

New version (1.2) adds an XNode version of the OpenG Array sort routine - uses exactly the same algorithm but works for any sortable array type without needing using polymorphic instances.

Version bump to 0.21 - new feature is a routine for finding the downstream sink terminals of a wire from an arbitary point close to one segment of the wire (e.g. to be used for working out where in a multi-branched wire a node needs to be inserted if the user clicked at a given co-ordinate)

You can all send a thank you note to JGCode. He posted a question in the ni.com forums that happened to hit at a moment when nothing was screaming for my attention, and I finally got around to going through the VIs that handle New Accessor and the New Override and removing all the passwords and posting those VIs to the forums.

[...]

Thank you JGCode

How similar are the equivalent VIs for earlier versions of LabVIEW - specifically 8.6.1 and 2009 SP1 ? I don't suppose there's any chance of letting us poke at those ?

Build 10 corrects some packaging errors that caused problems in the previous build. No code changes in this version.

Thanks for your RCF plugin, but i have find one bug (LV2009) . When i want swap one bundle with two inputs, it's one input and cluster data who are swap, and not the two inputs like wish.

Oops, so sorry about that. Built the package against the wrong version of the source code .

New build 1.0.2-8 fixes the problem.

One another request, is it possible to add cleanup wire action after each swap to have better appearance of diagram

Will Add this to the TODO list. Shouldn't be very hard - just need to find the wires and then do the cleanup on them.

Released a new build as a VIPM package. Slightly redefined the version numbering so that this really is newer than the previous build. Should have correct dependencies on the RCF packages.

New build posted v 1.1.2 is now a VIPM Package file. No major changes in functionality, but should install a little more easily and has a palette file under a LAVAG Category.

Please ignore the slightly odd dependency of the .vip on itself. This is a result of a dirty hack that I've used to get VIPM to include a palette file of XNodes and is harmless

Uploaded a new build 0.20.02.6 which is now a VIPM Package (built with VIPM 2010). This doesn't add any new functionality, but does now install palettes properly into a LAVAG Category.