gb119

Thinking about this, the general case is quite tricky. I think I'd do a template that handled the 1D case - that's essentially what the existing XNode does. The 2+D input array being filtered by a 1D boolean array is relatively easy - a template something like this: You'd then need to script creating the constant that initialises the shift register (pretty easy actually) and duplicating the innermost case structure cases one per dimension of the input array, editing the delete and insert into array nodes to wire the index into the correct terminal (trickier but probably do-able). Handling multidimensional boolean conditional terminals as well makes my head hurt.

Ok I'll add that to the TODO list. Right after I get the palette files to play hice in 2009 onwards and finish the remaining OpenG vis! New version 1.1.0.14 uploaded. Fixes some of the palette file issues in 2009/2010 and implements the Reorder array.

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) OpenG Array XNodes v1.4.2.43 by University of Leeds Author: Gavin Burnell Copyright: Copyright © 2011, University of Leeds, 2002-2007 Cal-Bay Systems, Inc., Jim Kring. 2006-2007 MKS Instruments, Inc License: BSD Compatible LabVIEW Versions: >= 2012. Compatible OS Versions: ALL. Description: This package simply reimplements the OpenG Array tools as a set of XNodes. This has the advantage that any array time (apart possibly from arrays of LVOOP classes) can be worked with rather than just those that have polymorphs in the original OpenG versions. The disadvantage is that you can't inspect the code, but it's the same honest ! What is an XNode ? ~~~~~~~~~~~~ An XNode is a type of LabVIEW library (like a LVOOP class, XControl) that defines a collection of vis that provide on-the-fly scripted nodes on on the block diagram in LabVIEW. In other words, they allow you to create a node whose code is generated programatically as it is dropped on the block diagram or when inputs are changed. This allows the developer to simulate some of the effects of LabVIEW's builtin primitives such as polymorphism, node resizing and edit time configuration. Unfortunately, it is not possible to edit XNodes in the regular IDE (unless you work for National Instruments) as they are locked in the IDE. However, the individual vis are not necessarily locked and either by editing the xml file of the XNode directly, or with the help of some third party tools listed below, it is possible to edit and implement new XNodes. For a fuller introduction, you are rrecommend to read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint). For developing XNodes I use (a slightly modified) XNode Manager by Aitor Solar (http://lavag.org/files/file/57-xnode-manager). There are also a couple of ini file settings that make it easier (but still not trivial) to debug XNodes: XNodeWizardMode=True XTraceXNode=True At all times remember that XNodes are not a supported technology as far as NI is concerned (as of LV 2010Sp1 anyway) and you should expect neither sympathy nor support from NI if bad things happen as a result of using them. The algorithms used in this toolkit are taken from: oglib_array v3.0.0-1 by OpenG.org Author: Jim Kring <jim@jimkring.com>, Doug Femec <doug_femec@mksinst.com> Copyright: 2002-2007 Cal-Bay Systems, Inc., Jim Kring. 2006-2007 MKS Instruments, Inc. All rights reserved. License: BSD Description: The array package contains several routines for operating on array data. Click here to download this file

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...

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

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.

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). 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, 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.

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...

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.

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....

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.

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.

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.

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)

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.

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. 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.