gb119

QUOTE (Cat @ Apr 21 2008, 05:45 PM) I can't pretend to be an OOP guru - lI too have spent most of my programming time working in non-OOP languages (and a lot of that in LabVIEW at that). Because of this, I've never really done much with the various GOOP frameworks, on the otherhand I have found that I'm gradually shifting more of my coding over to LVOOP where the by-value encapsulation of data and inheritance seem to work reasonably naturally to my mind. Where I've found myself writing LVOOP classes in measurement code has been in two distinct ways: - I've converted a lot of my instrument drivers to a LVOOP heirarchy - I have a base Instrument class that providess methods like Initialise and Close and protected methods like Wrtie-Read, and some utilitiy methods for doing things like reading data from SCPI compliant nstruments. On top of this I layer classes that define generic instruments e.g. source-meter, temperature controller, lockin - these just define an interface but don't implement any actual code themselves. Finally, I write classes for each instrument that implements one of the generic instrument classes - this my measurement program can be written in terms of "Source-Meter" class and its methods, but then switching between e.g. Keiithley 24xx and 26xx source meters is just a question of sending the right child class down the wire. This makes adding new instruments to the code base really very easy... - Most of the measurements that we do boil down to "measure y=f(x,a1,a2,...an), extract some parameters, adjust a1,a2,...an, repeat. So I've started to write classes heirarchies that implement this - I have a base X-Y class which I then create child classes for doing e.g. I-V measurements with a source meter, G-V measurements with a current source and a lockin - again adding a new measurment just means implementing a new child class and common methods like saving data, plotting data are defined only in the parent class. Similiarly I'm doing classes to adjust the a1,a2 parameters - which are typically temperatures, magnetic fields, gate voltages. None of this is rocket science, and I keep discovering that I've made some error in my design of the class hierarchy, but I think it gives a flavour of how OOP (and for me LVOOP in particular) can be made to work in "real-world" applications. As for the by-ref vs by-value debate - I can see that for experienced C++ programmers by-ref is the only way to go, I suspect for LabVIEW developers who have never done any OOP, by-value seems more natural modulo those times when you have a class representing a physical thing that you need to work with in parallel loops, when by-ref is the only sensible way. It's certainly not worth a jihad

QUOTE (Michael_Aivaliotis @ Apr 21 2008, 08:50 AM) Ok, I've stuck in my Rusty Nails stuff - VI Scripting Tools and some XNodes, including my XNode for determing how a sub-vi is wired at runtime. In the process I've arbitarily established a directory structure that mimics the CR structure. It occurs to me that we might want to do something to indicate which LabVIEW version files are in... my stuff is all in 8.5.1 which I've switched to for primary development of new code. Share and Enjoy

QUOTE (Gavin Burnell @ Apr 19 2008, 11:59 AM) QUOTE (Aristos Queue @ Apr 20 2008, 04:21 AM) -You may also be interested in this article "Command Line Interface for LabVIEW" To output the results of your LV program back to the command line, use the System Exec.vi (which you can find by searching the palettes). It has the ability to output to either standard output or standard error. Ok, now I'm feeling pretty dumb.... Actually, I can see how the System Exec allows you to access the STDIN/STDOUT of whatever process you are running, but how does one persuade it to connect to the STDIN/STDOUT of the process that launched the LabVIEw app ? I mean if I did something like executing "cmd \c cat -" wouldn't I open a new command shell window which would display whatever I wired up as standard input ? Or am I missing soem trick here ?

Ummm, I'm pretty sure you can't (easily). LabVIEW doesn't give you access to the standard input/output and pretty much assumes that you are running under a GUI. There are various tricks one can do to make it not run with any GUI e.g. running as a Windows service, but even a compiled LabVIEW application doesn't run inpendently of the runtime and that assumes a GUI. The broader question is why? LabVIEW is great for many things, but writing console programs is not one of them.

QUOTE (Aristos Queue @ Mar 31 2008, 09:17 PM) I've just posted a first trial at doing this http://forums.lavag.org/Determing-if-a-control-is-wired-in-the-caller-t10604.html&view=getnewpost' target="_blank">here

Every so often someone posts a question along the lines of "is it possible to determine inside a sub-vi whether a particular control of that sub-vi is wired up or not in the calling vi ?" The normal answer to this question is no, followed by various workarounds. One obvious way is to make the default value of a control an obvious "bad" value, e.g. NaN or -1. This is not always possible, since sometimes you can't predict what a 'bad' value is. There are also other various workarounds floating around on LAVA. As fas as I can tell, most of these involve parsing the diagram to locate the sub-vi reference and then examining which of the sub-vi node terminals are wired. This has various problems: * You need to parse not just the top-level diagram, but all the sub-diagrams of case strictires and sequence structures etc. * What happens if the sub-vi is called twice in the same vi - which sub-vi node is currently executing ? * It only works in the development environment * It's slow The last time the question was asked, I thought maybe an XNode could wrap a sub-vi call and somehow pass in the wiring data into the sub-vi. Here is my initial implementation of this scheme. You need to download the very latest version of my Scripting tools from the Code Repository (0.17.01) and possibly do a mass compile of them to ensure the linkages are all correct for whereever you keep them. The magic XNode is in the attached zip file along with a very simple demo. NB This is pretty much hot of the wireworks and barely tested proof of concept. To wrap a vi, drop the xnode onto the callers block diagram and right click on it. Select the option to Load a vi into the wrapper. The wrapper then takes on the icon of the wrapped vi and has the same terminal pattern as the wrapped vi. When you wire anything into the wrapper it generates code that will set a control on the wrapped vi with the wiring data. The control should have the same name as the wrapped vi and should be an array of clusters of string, string and variant (there is a term types.ctl in the Subvis folder of the XNode wrapper for this). The two strings in the cluster are the terminal name and an ID which is the order of the terminal on the connector, pane. Doublie clicking the wrapper will open the wrapped sub-vi Bugs and outstanding issues: *LVOOP and XNodes don't mix and may therefore break LabVIEW in unpredictable ways (like this code doesn't :!: ) * If you don't wire anything up then it probably doesn't generate anycode ever... * The help window doesn't (help that is). I need to write a help ability that clones the help info from the wrapped vi * I tried to get it so that you could drag a vi onto the wrapper to load it, but I can't get it to work - any XNode Gurus know how to fix that ? * subvis with icons that are not 32x32 will probably look ugly * The directions of the wiring stubs may be a bit wrong * I'm fairly sure that the code that is used to connect terminals to the cal-by-ref node in the generated code is slightly wrong. * Oh yes and did I mnetion that this is almost entirely untested code that I've written to see if it worked at all.... Download File:post-3951-1208385414.zip

QUOTE (yasmeen85 @ Apr 1 2008, 07:06 AM) Ah, that's easy. You just have to load the requested vi on to the server. Then you won't get the error. Seriously, you need to give us a lot more context to even begin to understand what might be the problem that you're having. What is your program trying to do - which vi is it not finding loaded into memory and how does it normally work. Is this a program that runs on just one computer or is it somehow distributed across a network ? Does it have any fancy architechture like plugins or is it just one program loaded up in one go ? Are you working with a compiled executable created by someone else or are you working with a LabVIEW development system and can access the source code ? The error message is pretty self-explanatory in as far as it goes - you are trying to use Vi-Server functions to access a vi that hasn't been loaded into memory and so can't be accessed.

QUOTE (Aristos Queue @ Mar 31 2008, 08:32 PM) But it would be really really nice if it were. Sure the trick of using a 'null' default value works but I've done too many enums that go ["don't change","on","off"] to represent what ought to be naturally boolean data that I might want to change. Actually, how about having an XNode that wraps the sub-vi calls and somehowpasses the connected term types into the sub-vi - trivially by the sub-vi having a 'special' terminal that is only used by the XNode to tell it which of the other terminals are wired. Perhaps there's a more elegant way thi can be done with tagging a reference to a contro on the subvi with the connection data. It's sort of cheating, but might do the trick.

QUOTE(ibbuntu @ Mar 7 2008, 07:41 PM) I have a feeling that this has been suggested before, but Aristo Queue (aka the great god of LabVIEW Native Classes) had said that it was extremely difficult to implement because it would involve loading not just the class, but the entire set of ancestors to work out what methods were available (or something like that anyway). Personally, I'd settle for right clicking on a class wire and doing an insert bundle by name and have it wre up the cluster prototype and output correctly

QUOTE(HeLo @ Mar 3 2008, 07:17 AM) [...] QUOTE(HeLo @ Mar 3 2008, 07:17 AM) Wow - how your old code comes back to byte you ! <img src="http://lavag.org/public/style_emoticons/default/smile.gif" style="vertical-align:middle" emoid=" " border="0" alt="smile.gif" /> I think I wrote the original version of that code about 10 years ago now. Certainly the orginal (still available from <a href="http://dmg-stairs.msm.cam.ac.uk/%7Egb119/labview/" target="_blank"><a href="http://dmg-stairs.msm.cam.ac.uk/~gb119/labview/" target="_blank">http://dmg-stairs.msm.cam.ac.uk/~gb119/labview/</a></a>) was written in LabVIEw 5.1 which was shiny and new then (and now 8.5 won't even open the original version !). Good to see that after a decade the code is still some use to folk.

QUOTE(tcplomp @ Feb 28 2008, 05:13 AM) Hmmm, I tried the XControl Inheritence tool, but it's not working for me. Specifically, it creates the properties all ok, but whenever I try to access those properties, I get a control 'XXX' not found, error code 1 message. Looking at the generated code I see 2 potential problems: 1) The technique seems to rely on stuffing a constant reference to part of the XControl into the state variable in the facade and then using that reference in the property read/write code. Now, the facade is running in one application instance and the property node code is running in the main application instance and you can;t use a refnum from one application instance in another. I wonder if this is behaviour that changed between LabVIEW 8 and 8.2.1 (which I'm testing in, although the same problem does happen in 8.5 'cos my attempts hit this same problem). 2) I don't follow why the generated code is looking for the label.text property of the stored refnum to be equal to the name of the property that I'm trying to access - surely the label.text property will (should, see 1) above) return the label of the part of the XControl that I'm inheriting and not have any knowledge of the name of the property. Apologies if I'm being terminally stupid here - :headbang:

A somewhat similar problem, only this time I think I want to mess with the refnum in the user program - why on earth do I want to something quite this dum ? Well I've been playing with making an XY plot with error bars XControl (why oh why hasn't NI provided a native version yet ? Don't people believe in error bars when looking at real data ?) and I'm too darn lazy to try and write wrappers to export all the properties of the standard XY Graph control, so I thought I could save time by just exporting the refnum to the XY graph on the facade... Ok, well I worked out that the facade is running in a separate application instance, so you can't just stuff the Control refnum into the state cluster and then read it with a custom property. I worked around this by storing the "This application" refnum into the state cluster from the facade, and then in the read property code, opening a reference to my facade vi in that particular application instance and then getting a reference to the correct control and passing that back. Now I can get/set properties on my XY Graph Control, but I can't get the XControl on my application vi to update its appearance. Curiously, if I unload and reload my application then the XControl has picked up the new settings, so I do change something, but it's not exactly runtime behaviour.... Any thoughts (other than to (a) not be so stupid and to stop trying to do things which were never designed to work or (b) suggest that NI give us a proper XY with error bars graph control) ?

QUOTE([email=) Not sure if it makes a huge difference, I'd go with the Stop primive since I'm sure that the Abort method is functionally the same as hitting the stop button on the toolbar which is definitely ugly... QUOTE([email=) guruthilak@yahoo.com[/email]' date='Feb 19 2008, 05:03 AM' post='41813'] 2) when the vi is aborting, i can see a small pop up window (looks like the window property of this vi is "Model") which says "Resetting "vi name" " .. Now how can i remove this.. Somettime this pop stays and does not go at all making me to kill Labiew from the "windows task manager" QUOTE(neB @ Feb 15 2008, 08:29 PM) That is true right up till you get to doing an I/O. THe VI will be aborted BUT it may hang the LV session (at least that is what happened the last time I tried it, about a month ago under LV 8.2.1) This is why neB warned you about aborting a vi in the middle of an I/O operation (like using the system-exec). That 'resetting...' message is LabVIEW trying to clean up resources after you killed it mid-operation. You really want to be doing this by coding the operation (a 'ping' I think you said) directly in LabVIEW with suitable timeouts for the network functions. That way you get to catch a timeout error and can close connections and cleanup etc. Plus you don't have to start extra top-level vis using vi-server calls which means the code is simpler to understand and maintain...

QUOTE([email=) Do you really want to abort the vi - that is equivalent to stopping the entire call chain of vis ? Which, incidently is your problem: you can't Abort a sub-vi because Abort stops the entire call chain from the top-level vi downwards. It sounds like you want to do a premature return from the sub-vi call which is harder... Do you absolutely have to use an ICMP ping packet - i.e. is this just a way of checking whether your remote hardware is on the network. if so, does it have any TCP ports open that you could attempt to open a connection to (and then close without sending any data). If so, then you can write a vi which attemps a TCP open to the correct port with a timeout set and then use the error from this to determine whether the remote machine is there to talk to. If it is, you just do a TCP close right away and other than generating some log messages it shouldn't do too much harm.

QUOTE(Aristos Queue @ Jan 29 2008, 05:33 PM) Ouch ! That would have been something I would have certainly fallen foul of - I can easily imagine a system with two 'quick' events being broadcast to multiple event structures, but one of the event structures being busy doing a longer task when the events are fired and me wondering why *none* of my event structures got the second event in a timely fashion....

QUOTE(Saverio @ Jan 22 2008, 03:52 PM) Ummm, I thought the later versions of LabXML used libxml2 - the open source XML parser ? The earlier versions did use the MS XML parser though. It doesn't seem to have had active development for a couple of years - somehow I don't think that's because it's perfect already

QUOTE(Tomi Maila @ Jan 16 2008, 12:30 PM) My first thought was to run a vi in App_B from A that opens an application reference to itself and uses that to inspect the 'local only' properties and then report them via its front panel - I assume that if the App_B vi is running on B, then when it opens an application reference it gets a local application reference. That has the advantage that it is then OS independent. Of course, you have to arrange for the relevant vi to be loaded into App_B's memory otherwise you'll have to find a suitable path, but I guess a static reference in App_B would do the trick until the compiler learns to optimize non used static references out... There is a way of looking at Remote Panel connections (both client and server) from the local app reference, but I think the remote panels were working over the web-server which is not what you want...

<cite>QUOTE(christinabest @ Jan 12 2008, 09:33 PM) </cite> Ok, I really couldn't resist it this time... Attached, I *think* solves the problem, but I'm sure someone can improve on my solution - hey look no XNodes, no Scripting, no LVOOP yet... Download File:post-3951-1200181532.vi

QUOTE(Aristos Queue @ Jan 9 2008, 07:02 AM) I'll settle for "immiscible" QUOTE(Aristos Queue @ Jan 9 2008, 07:02 AM) Caveat empor. Well, it's like those medieval maps that marked large areas at the edge of the known world with "here be dragons and all manner of strange beasts" - if you sail your ship there and it gets eaten by a sea-serpant you can't sue the map maker (!)

QUOTE(Tomi Maila @ Jan 8 2008, 10:55 AM) Hmmm, yes I hadn't fully appreciated the weirdness that a combination of XNodes and Classes can give - I just tried to use one of my Array XNodes with an array of objects and whilst it claims that the output is an array of objects like it should, I can't then index the output array. Seriously strange !

Has anyone out there succeded in adding an XNode to a LabVIEW class ? Ideally I'd like to write an XNode that accesses some private methods of a class, so it would need to be part of the class. As a work around I can just change the scope of the private method to public, but it isn't as elegant...

QUOTE(Tomi Maila @ Dec 15 2007, 03:37 PM) I was thinking about an XNode replacement for the compound arithmetic element that would handle mixed boolean/error clusters and also array versions of either. Should be relatively easy to implement. It would even be possible to put back the optional input invert. Add it to my list of XNode projects...

Wow ! :worship: I was trying to write an XNode to do just that (well, actually I was going to have two XNodes for writing controls and reading indicators), but I couldn't work out how to probe the incoming vi reference to work out the pattern of the connector pane and the types of controls connected - I had thought that if I had a strict vi reference I could do this at scripting time, but no it doesn't seem possible QUOTE(Aitor Solar @ Dec 13 2007, 01:06 PM) Ah, I guess this the hint - you don't try and work out what the connector pane is from the vi reference.... Are you planning to release your XNode on the Lava CR ?

QUOTE(tcplomp @ Nov 29 2007, 06:49 PM) Presumably, running a property or method vi 'wakes up' the facade of the XControl because it is likely that some aspect of the appearance will need updating, in which case the facade can catch your user event. Since the XControl doesn't know that the callback vi might want to mess with the facade, it doesn't get woken up. I guess if your callback vi could get a reference to the XControl you could call some random (dummy) property or method after you send the user event to manually 'awaken' the XControl facade...

QUOTE(TiT @ Nov 29 2007, 02:56 PM) I would think the difficult bit would be to code the intelligence to analyze what the data flow of the sequence locals was - i.e. you want to turn them into wires that are connected to shift registers but how do you identify whether sequence locals A,B and C are in fact all carrying the same item of data from frame to frame, particularly if the data is passed and in and out of sub-vis in some of the frames. I guess you could look at the data type of each sequence local and then work out the number of reads from each local node and the data types of each node to work out the minimum number of shift registers and wires that you need, but there would be no guarantees that the result would be 'sensible' to a real human coder.