gb119

New version released with a new Shuffle Array Xnode that randomises the order or elements in an array. A bit more explanatory text in the readme on the LAVACR entry.

I with AQ I think on this - I'm not sure it's a particularly common problem and the code to do it is both simple and obvious. Sure, one could make OpenG an incredibly rich toolkit but with the danger of it taking longer to search for the right function than it would to write the code inline directly.

Oops, that is embarrassing - it's actually a typo in the dependent Waveform XControl package. I've fixed that one and bumped version numbers to propagate the fixed package throuugh to this XControl too,

I was just wondering if anyone had ever put forward the idea of creating an OpenG XControls package ? I know from bitter experience that it is quite trickey to write really good XControls, yet they're also a great way to make nice reusable components - so they seem like a no-brainer for an OpenG package or ten... Possible suggestions might include: IP/network address control (perhaps with various network masking options as well) - a basic one exists within the LAVA CR a URI string control with properties to parse an entered URI a word completion string control - I'm sure I've seen one somewhere around a spell checking string control a function generator (I'd happily offer my own Waveform Xcontrol as a starting point) .... ?

View File Vector Waveform XControl lavag_lib_User_Interface_XControls_Vector_Waveform v1.0.2.25 by University of Leeds Author: Gavin Burnell Copyright: Copyright © 2011, University of Leeds License: BSD Compatible LabVIEW Versions: >= 2018 Compatible OS Versions: ALL. Description: This package uses two instances of my Waveform XControl to make a vector waveform - i.e. magnitude and direction or x and y co-ordinates. The resultant vector waveform is plotted on the third tab of the Xcontrol. The XControl can be switched between polar or cartesian co-ordinate modes and it is possible to vary both co-ordinates together or repeating one for every point on the other - thus allowing 2D scans to be built up. The waveform is represented as a complex number where the real co-ordinate corresponds to the X axis and the imaginary to the y. I use this in my own code to allow users to control both a vector magnet and to setup a laser scanning system. Release Notes: This Package depends on these other packages: lavag_lib_user_interface_xcontrole_waveform_xcontrol >= 1.1.2.0.18 oglib_array >= 3.0.0 Submitter gb119 Submitted 08/23/2011 Category X-Controls LabVIEW Version License Type

Yes that seems to be working really nicely now - thanks!

Hmmmm, but the old version of the site gave a nice mobile browser version that didn't need any 3rd party phone app (says he with a phone that is pretty much filled up with apps now . I was sorta hoping to get that back again...

New version that adds the ability to control the format string of the Amplitude/Offset controls - I've set this to default to SI numbers with 3 s.f. Also tweaked the layout code to straighten out the controls somewhat and give a bit more space for the SI prefix. This is likely to be the last LabVIEW 8.6 version as I expect to move to 2011 for future developments soon.

I must be missing something - how do I turn on the mobile theme? All I can get on my 'droid phone is the full site.

Of course this sometimes works the other way. Because I've been messing with XNodes, I now assume that all crashes of LabVIEW I encounter must be my own stupid fault for messing with the things I'm not supposed to and therefore I don't get so frustrated at National Instruments....

I think the thing that has put me off events is that it forces one to use an event structure as the only way to handle messages and then one might actually want an event structure somewhere else in the same VI and I have this prejudice against two event structures on the same diagram... Also, there's no equivalent to the queue/notifier status and flush primitives (although I take note of AQ's warning over race conditions when used in combination with dequeue/wait primitives). I guess what I really want is something that combines elements of everything: Non-lossy like queues One to many mappings like notifiers Something I can feed the reference straight into an event structure and handle 'new element' events. Re-ordering of queued elements so that one can have high priority traffic overtake lower priority.

Ok, I'm getting this feeling that I'm kind of missing the point here and probably being hopelessly naive, but... Isn't the two parallel loops exactly what notifiers were invented for ? Ok, yes they're lossy, but if you are just using it to stop two parallel loops and you know the last message every to posted on the notifier is the 'stop now' then it doesn't matter surely ? The problem surely with any queue based design is that you're stuffed if someone else grabs the queue and takes your message - or if you want to stop N loops in parallel where N is only known at run time. What would be handy for multiple loops distributed over indeterminate numbers of parallel running vis would be a one to many queue with priorities - so that you could enqueue an element with an arbitrary priority and have that element delivered to multiple waits and have the elements presented to the wait sorted first by priority and then by enque-timestamp. Thus each dequeue node could pull entries safe in the knowledge that it wasn't affecting any other dequeue node, could choose to discard elelemts if it wanted, but would process them in an order determined by the enquer that wasn't necessarily FIFO. Nut I don't see this is necessary for the stated problem...?

I had another near miss idea with XNodes - and that was to use the drag and drop abilities to let you drop something that defines the type of the ViRegister onto the XNode - unfortunately it won't work very well as those abilities only accept strings, paths and ProjectItem references - so you could use it to set the name of the vi register using a string or to use a custom control on disk or in a project window to set the name and type. (If there are any of the LabVIEW R&D wizards reading this and feel like letting XNodes work with variant data for drag and drop.... ).

Nice ! I was just thinking the other day that the array to cluster would make an obvious target for an XNode but hadn't done anything about it. One little thing though - you don't handle the case of the stupid user who feeds a cluster with different element types in very elegantly (i.e. it just produces the XNode couldn't cope because of some failure in scripting error (well not quite those exact words, but you get the general gist...). I had a go at checking to see if the type descriptor of all the elements of the cluster were the same when I flattened them to strings and then return a more informative error if not. It works in that it doesn't return an error with code generation, but it doesn't return my error - just error 1 invalid terminals. Which is correct but not what I wanted to do...

Thanks ! I've used your patched Find tagged and replace and added a new Copy and WireTagged Element which is essentially the same as yours except that I put the tagname and value to look for into a front panel control (with the defaults set for my standard tags). Uploaded as version 0.24 Keep the bug fixes and additions rolling folks and I'll merge them as and when I get time...

Hi, I finally got a chance to get round to looking at this and I've hit a tinsy snag - VIPM refused to install the package properly. I managed to manually install it ok though and it all seems to work nicely. The coding style seems quite familiar

Nice. Added to version 0.23.0 (after back saving to 8.6.1f2 and renaming Find ? to Found ? on the indicator label ) Gavin

I found this quite interesting. I had a go at making a version that avoided the array reverse to try and stop allocating additional buffers for the string by indexing from both ends in the same loop. The result was slower (by about 10% or so) that this version. This was on both 8.6.1 and 10. I'm guessing that the extra overhead of reversing the array is worth it to let the two loops indexing each end run truly independently (my version also had some overhead to handle the - common - situation of unequal amounts of white space at end of the string). The really impressive thing was how much faster both versions were than the regular expression based one - for my tests it was an order of magnitude for short strings and more than that for 4k strings. I've attached my slower version (8.6.1) in case anyone is interested enough to spot if I've done something stupid.GB String Trim.vi

Hmmm, does it count the arguments from 0 or 1 ? If the former, then the problem would be the hWnd=0 which I think I would interpret as creating a client window on the desktop - perhaps it doesn't like doing that ? I'm afraid I rather suspect the intersection of the sets of SAP users and LabVIEW coders is probably a small number approximating unity

Hmmm, oops. Thanks for spotting that - now fixed in 0.22.02. Too much working too late at night methinks. Gavin

Yes, I use the XNode Manager along with a couple of other things. Most of the XNodes that I've down (both the OpenG and the other Array XNodes) use templating to avoid doing the messy scripting. Basically I have one or more vi's that have the code wrapped in a sequence structure. The structure and all the tunnels are tagged using the (slightly obscure) tagging api. Generatign the code is then just a case of moving the tagged sequence from the template vi into the XNode's working diagram and then wiring up the tunnels to the terminals. I've gradually adapted the templating process to reduce the number of vis that need to be written for any given XNode. to speed things up, I've customised the blank_Xnode that the XNode manager users - I've attached my current version on this post.blank_xnode.llb My XNode State.ctl normally keeps an error cluster for determing if the XNode is going to be valid and if not, what the error message to return will be (Get Errors3 ability then uses this). The State generally has a variant to hold the type of array so that Get Terms can set other terminals to match the input array type and then I keep a vi reference which holds a statically linked Viref to the template (so that if one needs multiple templates, Adapt Inputs ability can select the right template and stuff it ointo the state. The Image ability can either use the XNode library icon, or alternatively get it from the VI template. The final bit of head banging is to get an entry in the palette file that works across the platforms. I mainly develop on 8.6.1 and that uses the XNode library icon and description in the palette, while newer versions of LabVIEW use the Help Ability. If you make a palette of XNodes in 8.6 and then try and import it into 2009/2010 then all the XNode icons get replaced with the Help Icon and description. Even if you set the icon and description of the Help ability vi to be sensible, the text in the palette file ends up being 'Help.vi' which is not a self-fulfilling prophecy. If you create the palette in 2009/2010 then it seems to get the text string in the palette right. Until you edit the palette with the palette API vis... I eventually took the solution of simply naming the vi that implements the Help ability to be the same as the name of the xnode. That seems to work. For the OpenG Array Tools XNodes, I wrote a quick an dirty helper programme that created a template with tagged structure and tunnels from one of the polymorphs of the originally OpenG Tools vis, used the polymorph vi icon and description to set the XNode library icon and description and that of the Help Ability vi to, and then inspected the template vi's connector pane to generate the details for the Get Terms3 ability. All that is left is to check the inputs to make sure they're valid, adjust the types of the output terminals and then package it up (which I always find to be the hardest part despite the cleverness of VIPM). Gavin

Ummm, yes. Will try and work out what how I've screwed up the packaging... Edit: Identified the packaging problem (somehow the how XNode had disappeared from my source directory - thankgoodness for SCC..., coupled with some weird linkage problems). Version 1.2.1 should have the missing XNode I believe.

I guess the OpenG packages should probably treat these as deprecated and drop them from the palettes - I was just blindly implementing the existing palette as XNodes for the fun of it...

Have now got XNodes for all the OpenG Array tools. Other than not caring about the type of the array the only extra functionality is that the Empty Array? XNode will work with any number of dimensions of array. Most of the XNodes still dump their generated code to the clipboard for testing purposes, so that will be turned off next.