gb119
-
Posts
317 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by gb119
-
-
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=)
guruthilak@yahoo.com[/email]' date='Feb 19 2008, 05:03 AM' post='41813']I have 2 quesstions to ask
1) Which is better? "Abort vi" method or the "stop" function under "Function palette->application control"? (I ma using ABort vi method currently)
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 theLVsession (at least that is what happened the last time I tried it, about a month ago underLV8.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=)
guruthilak@yahoo.com[/email]' date='Feb 15 2008, 12:59 PM' post='41737']Hello there...I have a question to ask........ Looks silly but i dont know whats happening here....I have an application which pings to a linux based hardware and it is supposed to get some response when its pinged. If the response is not recived within some 10 seconds i am killing this vi (which is attached ) so that the main application will call this vi once again.I have used the method "ABORT VI" to kill the vi itself.(The reason why i am killing it because the "System exec" hangs or enters to "dead lock" most of the time) But when this method executes it throws an error as "Error 1000 occurred at Invoke Node in test.vi->xxxx.vi->ZZZZZZ.viPossible reason(s):LabVIEW: The VI is not in a state compatible with this operation.Method Name: Abort VI"Now i dont understand why it isnt state compatible.....? Can someone analise the same and let me know whats happening in this vi.PS: The reason why i am killing it because the "System Exec" hangs or enters to "dead lock" most of the timeOne more thing.. If u run this vi alone it will run without any problem. call this vi as subvi and then u can see the problem..May be even you can remove the "system exec: vi and rplace with a "Wait (ms)" with the "milliseconds to wait" value as anything more tha 11000 (11 seconds)
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)
Essentially, yes. Events are *always* fully handled in the order they occur. So if you have two separate event structures registered for separate events, and both events occur, the first to occur will finish its event case before the next one begins being handled, even if these are separate event structures. This is important in case the event structures are accessing common queues, global storage, hardware or other refnum type. If multiple event structures are handling the same event, then all of them must finish handling the event before the next one begins being handled.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)
One of the options in the poll is LabXML, which is what I use. It inherently uses the MSXML parser, so I'm not sure which poll answer to choose in this case (went for LabXML).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)
Assuming I've a network of multiple computers, say A, B and C. On one computer A I've a LabVIEW application App_A running. In that application I've a valid reference to a remote LabVIEW application App_B running on a second computer B. Is it possible to find out the ip address and the port number of that application App_B from the valid reference in App_A. I need to be able to open a reference to the same application App_B on B from computer C. I need to somehow pass App_C on computer C sufficient information to connect to App_B on computer B and the only thing I've is the reference to App_B valid in App_A only.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>
-
QUOTE(Aristos Queue @ Jan 9 2008, 07:02 AM)
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)
I don't think it's possible to get XNodes to even work with LabVIEW classes. LabVIEW simply crashes when a class type wire in connected to an XNode. At least this is my experience. Do you have some knowledge that would allow using XNodes with LabVIEW classes? I would really love to use XNodes with LabVIEW classes.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)
This is one of those features that can be implemented with XNodes.... Simply use AugmentSelf ability to connect your XNode to the stop terminal of a loop and even place your XNode on top of that stop terminal so that it hides the original stop terminal.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)
I also prefer the first method (call me traditional ). To avoid the necesity of writing down the controls' names (so error-prone), I have developed an XNode to manage the Set Value and Get Value methods automatically. Visually is similar to the Call-By-Reference function, and you can easily drag a VI or browse to the desired VI: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)
I am using user events, you can see them in my Boolean XControl. Where I create the event registration in the Init ability and destroy them in the Uninit event.I fire events from methods and properties without problems and my facade VI gets triggered by them.
So it shouldn't give you any problems unless you get really fancy.
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)
Let's say I have a VI with a stack sequence with a fistful of steps and some sequence local to pass data from a step to the next, is it possible to turn it to a state machine, programmatically using scripting ?I suspect the answer is yes, which leads me to ask about the level of difficulty
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.
-
QUOTE(tcplomp @ Nov 12 2007, 04:36 PM)
Source Code Control?Ton
Of course, or just a versioning file system so I didn't need to remember to do a commit after every save... oh for the days of VAXen and VMS
Semi-seriously, has anyone else had problems with generating corrupt xml files when LV tries to handle non-unique filenames in multiple directories (like dir.mnu for example) - quite often I seem to get an XML file that has multiple entries for dir.mnu that originally pointed to different directories, but at some stage get set to all point at the same file. LabVIEW then decides my library/class is corrrupt and won't load it. A quick go with {CVS|SVN} Diff and a merge editor (I like WinMerge myself) sorts out the mess, but I wish I could work out what triggers this and how to stop it.
-
Ok, I've discovered a new way to shoot myself in the foot while programming in LabVIEW. Here's how you do it:
1) Create yourself a LabVIEW class
2) Create yourself an XControl to display your new class doing some nifty processing to prettyify your class's private data
2b) Note that you can't add your XControl to your class, so use some public methods to extract the private data
3) Decide you want a probe for your class, so create it and figure "why not just use my nice shiny XControl in my probe ?"
4) Add your probe to your class so that you can assign it in the class properties. Don't forget to save your class as soon as you have added the probe !
5) Notice that your class is now locked. Enjoy that sinking feeling as you realise this means you can't remove the probe and undo whatever damage it is that you have just done. Find a nice text editor and get hacking on the XML file that defines the class. :headbang:
I think the problem is that when a VI containing an XControl is added to a project, the XControl is loaded. creating a new application instance, which contains an instance of your class. Your class is now loaded in two application instances and is therefore locked.
-
QUOTE(Tomi Maila @ Nov 5 2007, 02:37 PM)
The problem is that I find out the queue element type only after I've generated the code by inspecting the element output terminal type of the generated Preview Queue Element node. Now I should update the Xnode terminals according to this new information I receive after I've generated the code but I cannot get LabVIEW to call the GetTerms3 ability multiple times per input change. Even if I send the Update Terms message multiple times, LabVIEW only calls the GetTerms3 ability once.So I need your help in finding out a way to get the output to adapt to input so that the output type depends on the input type but is not the same as the input type. In this example case the output type should be the element type of the queue type wired to the input.
I don't have 8.5 to play with (NI doesn't appear to have shipped the update DVDs to academic site licensees in the UK yet), but at least on 8.2 the Variant Type vi's will help here. Specifically, the Variant Type.lvlib:Get Refnum Info includes an output that will contain the type of the queue element when fed the refnum type of the queue. So, I think you it all before generating code. In Adapt to Inputs ability check first that the queue input is a queue refnum, then get the queue element type using Get Refnum Info, and put the element type into the XNode state. Then in Get Terms3, read the state to get the Queue type and set the element output terminal accordingly. Finally generate the code...
-
QUOTE(Justin Goeres @ Oct 31 2007, 09:54 PM)
As long as we're brainstorming...Perhaps simpler code challenges for when we get asked 'homework' type questions:
* The worst LabVIEW style solution - who can come up with the solution that whilst actually doing the correct thing without bugs like race conditions is executed in the worst possible style - I'm thinking multiple nested sequences and loops with sub-vis and wires that sit on top of each, wires that run right to left, daft connector pane patterns, the full works.
* The most obfuscated solution - again, a solution that actually works and is bug free, this time written in technically good stlye, but with hardest to follow and least obvious algorithm.
I'm thinking about solutions that will score a nice big zero mark but do actually work. Or am I just too evil
-
QUOTE(mballa @ Oct 19 2007, 06:15 AM)
Already there - http://forums.lavag.org/downloads-file87.html
(the cleanup all wires was a bit of example code, but I think it you search on LAVA you'll find other people's versions as well)
-
I wrote my own development environment toolbar for my own use - it didn't have plugins or any fancy key bindings, but I did include things like the XNode manager and some of my various scripting hacks like a "clean-up all wires" tool, a "wire up all possible tunnels" tool, a "re-link all badly linked subvis" tool, a "show node terminal locations and order" tool, and a "find tunnelling error wire and rewire to case selector" tool (my favourite for making my sub-vis more LAVA code repository friendly....)
Unfortunately other priorities (undergraduates mainly) have gotten in the way of my LabVIEW coding recently
!QUOTE(JDave @ Oct 18 2007, 10:37 PM)
Jumping out of the http://forums.lavag.org/index.php?showtopic=9297&view=findpost&p=37300' target="_blank">Connector Pane thread, I am wondering if there is any interest in making a Development Environment toolbar. Some varying efforts and ideas are out there. But I suppose some minimum requirements would be:- Plugin architecture to allow adding and removing tools.
- Shortcut keys to invoke tools.
- Monitoring of what the Active VI is
Maybe this would be better done as an OpenG effort. Or maybe as a Coding Challenge effort. But there are some neat ideas out there that deserve to be plugged into our IDEs. And maybe if the idea is cool enough, NI will allow tools to be added to the native toolbar. Wouldn't that be a dream...
Are there any drawbacks to this obviously involving scripting and thus features that are not supported by NI?
What are your ideas on such a toolbar?
David
- Plugin architecture to allow adding and removing tools.
-
QUOTE(Jim Kring @ Aug 29 2007, 07:43 PM)
It seems to me (and I still don't understand everything that's going on here, fully) that the feature which should be removed (if we have to make a choice) is the Swap Values function rather than the ability for a child object to have a parent object in its private data. It seems that the "problem" is that the behavior of swapping values in memory is a function of how LabVIEW stores data in memory and this is something that we should generally not have to care about in the domain of dataflow.I have to say that this whole thread just makes my head hurt ! The swap Values primitive reminds me of the fun I had when I wrote my own CIN to manipulate the string handles in a string array - all of a sudden I noticed backwards propagation of data
! Now I just need the new LV 8.5 DVDs to make their way from the darker recesses of my university to me...
-
QUOTE(MartinD @ Aug 6 2007, 05:30 PM)
You said: Don't forget: If you use GPL code, your complete work must be under the GPL as well!This concerns me a little. There may be some parts of code I would prefer to remove the diagrams from. Those that talk to bespoke hardware etc. I wonder where the line is drawn here because I cannot provide the source code for the NI functions for example. I guess the key is "all my work" becomes covered by the GPL.
There is a provision in the GPL to not include things that are normally part of the operating system. In the context of LabVIEW it would have to be taken that the "operating system" included everything that was installed as part of the LabVIEW runtime engine - if the person who wrote the GPL'd LabVIEW code hasn't or can't make this implicit extension to the OS exception then it is unclear whether you can redistribute their GPL code at all.
You can distribute code under the GPL with the diagrams stripped or protected, but you'd have to include someway of acessing the source code - i.e. the vi's with the diagrams unprotected and editable. In which case, why bother protecting it ? There's no way round that - it's just how the GPL works.
-
QUOTE(tcplomp @ Jul 20 2007, 08:44 AM)
http://forums.lavag.org/CR-Array-Xnodeszip-t8636.html#' target="_blank">Recently I advocated the use of OGP as an installer function for code distributed with the LAVA CR.Now I would start the discussion where to put these items.
My preference is:
user.lib\_LAVACR\_Controls\%Name of the Control
user.lib\_LAVACR\_XNodes\%Name of the XNode
user.lib\_LAVACR\_Code\%Name of the submission
Does anyone have other ideas?
Ton
Firstly, I'd support having a recommended standard location -but then I'm one of the guilty parties who is submitting code that relies on other code repository code. I'd rather hope that code repository wasn't just a place for snippets but there is clearly some overlap with OpenG when we start having significant packages of code in the code repository. In terms of layout - why not use the heirarchy that already exists in the code repository catagories ? Hence, user.lib\_LAVACR\Rusty nails\XNodes\... etc
I had a feeling that the LabVIEW linker works with relative paths ? If so, that would mean that the code repository "root directory" could be moved around would it not ?
TIFF Reader
in Machine Vision and Imaging
Posted
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.