ShaunR
-
Posts
4,942 -
Joined
-
Days Won
308
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by ShaunR
-
-
QUOTE (postformac @ May 9 2009, 01:24 PM)
Thanks for the reply, I have never seen that before, is that a "register for events" box? I'm not sure what I would need to do with it to have it affect a control, do I need to somehow connect it to the two controls?Oh ok, its a property node, I found it and got it to work thanks.
Is it possible to put that function inside a sub-VI and still have it affect the controls on the front panel of my main VI?
It is if you pass the refnum to the sub vi. If you just select the property node and select "Create Subvi" from the Edit menu you will see what I mean.
I don't consider it as good coding practice since it hides what you are doing. I would prefer to see a vi that returns the new values to the property node in the same vi as the control appears.
-
QUOTE (Yair @ May 7 2009, 05:52 PM)
References for queues and notifiers are NOT created automatically. You have to explicitly request them. Even then, LV will clean them up automatically if the queue goes out of scope. LV actually got better in recent versions in dealing with references which are created automatically (like control references), so that you don't have to close them.Lets hope it goes out of scope before you run out of memory then.
QUOTE (Yair @ May 7 2009, 05:52 PM)
In any case, no one is forcing you to use these (or even a new version ofLV). You can go back to an old version, but I still don't see why you say that you have to worry about memory, etc. in the newer versions.Tetchy
-
-
QUOTE (crelf @ May 8 2009, 07:25 PM)
Are you sure there wasn't a nag warning screen that the operators just ignored for 30 days until it locked?That's kind of irrelevant.
A customer will blame you (the supplier) not NI for stopping production by a fault in your software. Generally you will get a phone call and they will demand you come on-site to fix it. At best, it costs you (as in your company) 1 engineer on a field trip. But we also have a suppliers that we guarantee minimum down time and incur penalties for lost production. So far this year, we have had 2 occurrences similar to this, luckily not with a supplier we guarantee, but it still cost an engineer a day off each time from projects he should have been on (and car rental, etc).
We have been using Labview and Labwindows for donkeys years, But there have been murmurs recently from the upper echelons in our company, that Labview is "too risky" and although it may be better in the short term because of the short development cycle, in the long term it may cost too much especially as the sales guys have just gone and sold 2 more guaranteed down-time contracts. In the current climate we have loads of c++ programmers looking for projects and the "powers that be" are looking for excuses to utilize the spare resource. I'm fighting like hell at the moment to get the SSP paid this month. And this sort of thing isn't helping me fight my corner.
-
Such a simple request yet not as trivial as it first seems.
Nevilles idea will most certainly work if you trust whoever is drawing the triangles. Hopefully you can go with that. But if you want a programmatic method, more complicated, but less demanding on the user you might try the following.....
1. "Threshold" the image (I'm looking at your blue icons) to get it in black and white.
3. "Fill holes" so that the center part of your triangle is fully blocked (i.e. you have a solid triangle). This is your major mask.
4. Scale your mask down by a factor (say 5%). And invert. This is your minor mask.
5. Combine both masks.
6. Apply the mask to your original image.
You should now just have the white triangle without drawing anything.
-
Yes. The callbacks were also saved in 8.6.1.
I've attempted to save back to 8.0 and took them out of the LLB. Hopefully converted them all, but labview was very insistant on saving them in its current version.
Try these anyway and let me know.
-
This may help (Hint: Polygons)
-
Everything you need is in
\examples\instrsmplserl.llb\Advanced Serial Write and Read.vi
-
QUOTE (Aristos Queue @ May 5 2009, 12:06 AM)
When it needs a copy, it makes a copy. When it does not it does not. An easy example -- if you unbundle data from one object and bundle it into another object, clearly a copy is made along the way. If you unbundle using the Inplace Element Structure, modify the value and then put the value right back into the object using the bundle node on the other side of the structure, no copy is made.Thats more like it does unless you tell it not too. But I can see where you are coming from.
I was more talking about if I called method A and passed that data to method B and then on to C. Do I now have 3 copies of that data just because I invoked those methods (and labview has loaded but not released the VI's)?. Or is it just pointer arithmetic (as it would be in other languages ) and there is only 1 data structure and only a pointer is copied?
QUOTE
he workaround I mentionned is indeed the use of the vi request deallocation which just seems wrong to me for such simple task in an environment that handles memory automatically.This is one of the aspects I really don't like about the "new" labview (far more I do like though). One of the reasons Labview was much faster in developing applications was because (unlike other languages) you didn't have to worry about memory management. As such, you could get on and code for function and didn't necessarily need an in-depth knowledge of how Labview operated under the hood. There used to be no such thing as a memory leak in Labview applications! Now you have to really make sure you close all references and are aware of when references are automatically created (like in queues, notifiers etc). It's good news for C++ converts because they like that sort of nitty gritty. But for new recruits and programming lamen (which was really where Labview made its ground) the learning curve is getting steeper and development times are getting longer.
-
It's a bit like the Error thrown on end of file in file functions. Technically correct, , but counter-intuitive and a pain in the proverbial.
-
-
QUOTE (sachsm @ May 4 2009, 10:04 PM)
Ta very muchly. But I was more interested in how it works.
-
So does invoking a property or method cause Labview to copy the data in an object? Or is it all pointer arithmatic.
-
QUOTE (sachsm @ May 4 2009, 02:53 PM)
Yes, all the methods mentioned do indeed work with cRIO targets. In my system I have 2 9074 targets each with 9144 extension chassis. I am using the scan engine IO Variables which I can read programaticallyusing Data Socket (DS) and then filter and scale then transfer to my version of the Current Value Table (Fancy shift register based storage) and from there the data is written to a proper NSV library which has a binding to a 'mirror' library on the windows side. From there I cannot via the DSC toolkit to my citadel database.
Is there a write up somewhere on the "mirror" library approach?
-
QUOTE (Jarimatti Valkonen @ May 4 2009, 08:33 AM)
Hey! Why didn't I think of this before? Looks very nice and simple.I'm actually considering using this or similar approach for my next UI. In previous project I used the "references inside cluster" approach and it didn't feel like data flow.
I made a separate VI with the cluster of references as a pass-through value to update the indicator values and some control properties. When the UI needed an update, I simply placed the VI in the block diagram.I'm having this strange idea of Model-View-Controller paradigm: keep the state (model) as a single cluster in a shift register and unbundle after every state to indicators (view). Something quite like presented here, but with additional "hidden variables" inside the model cluster.
If your going with a model-view architecture the (very) old method of using a data pool works well.
If you put all your data in a global vi or variable and get your controller to update the global, you can bolt on different UI's for different views.
-
QUOTE (Aristos Queue @ May 4 2009, 02:02 AM)
And although you might be correct in your diagnosis, I would like to hear confirmation of that from Ernest.Ummm. Maybe it had something to do with this statement from Ernest.
QUOTE (Ernest Galbrun)
The data is constituted of a 2D SGL array whose size may be a few millions of elements. -
QUOTE (ccie @ May 3 2009, 11:45 PM)
Hi shawn , im sure it is a full wave circuit , i am just wondering why it dosent display curves as a normal oscilloscope , what im trying to say is how do i interprete this graph to my supervisor at my final year project defenseInterpret it as "it doesn't work"...lol.
Can't make out much from your graph. The time is in arbitrary units (ms, seconds, light-years?) and you haven't told me what what you are expecting (pk-pk voltage 10-100V? 20ms period?).
You say the A2D comes through the serial port. How? Does it have a serial interface and your reading AScii characters? Or are you using the serial port as a digital IO and expecting a bit pattern representing the voltage. The source would also tell us what you are trying to do and expecting.
Assuming it's not a software issue. I would check the polarity of the diodes. Getting one round the wrong way is easy to do and easy to check. Then I would probably stick a sig-gen up the A2D and see what was displayed. If you then get what your expecting, its your rectifier. If not its either the A2D or the PC (software or hardware).
With all these things its a process of elimination. Segment the system into testable parts and iteratively narrow it down 'till you find the culprit.
-
QUOTE (Ton @ May 3 2009, 02:51 PM)
The 'http://zone.ni.com/reference/en-XX/help/371361E-01/glang/file_dialog/' target="_blank">File Dialog' express VI has an input called pattern (all files) setting this to *.csv will default the files with an extension of csv.By using this input and the accompanying pattern label you can mimick your own filetypes. For instance you could set pattern label to Measurement files.
If you have a path control you can set the browse options to achieve the same effect.
However I advise you not to use text based files for Excel, either write directly to excel via the ActiveX interface, or save your data as TDMS and use the Excel TDMS plugin to open the file. This will prevent errors from localization.
Ton
LOL.
Looks like you pressed the send button just before me
-
You sure its not a 1/2 wave rectifier?
-
Open your own dialogue prompt (File I/O>>Adv File funcs>>File Dialog) and pass the filepath to the save vi. The File dialogue express VI enables you to set the default extension and passing the filepath means that the default dialogue won't be invoked.
-
QUOTE (Aristos Queue @ May 2 2009, 11:52 PM)
A) Known issue: in LV8.2, 8.5 and 8.6, the Request Dealloc prim does not affect allocations of LV class objects. So any objects allocated in the dataspace of VIs -- not just member VIs, but any VIs -- will not be deallocated by the prim. That does not mean they are leaked. We simply leave the allocations in place. This bug will be fixed in the next release of LV. (It is not listed on the official Known Issues page because it was discovered relatively recently. This prim is very rarely used, as demonstrated by the fact that it took 3 versions of LV before anyone noticed it wasn't having any effect.)B) Using this primitive often creates more problems than it solves performance-wise. I have a strong suspicion that it would not be desirable to use this even if it did affect LV class instances. Besides, Ernest already found some manual mechanism that he tried... I'm curious what that mechanism is. I think we need to know that before we can recommend solutions to the problem he is seeing. If he really does want the entire VI to leave memory, for example, the Request Dealloc prim is not the solution.
I disagree. IF it worked as it says on the tin (or labview help in this case), this is exactly the scenario where you would use it. Says nothing in the help that it won't work on classes (and they ARE vi's so it should, as in I would see that as a bug too). A slight performance hit using it is better than using up so much memory that you start using the swap file which would be even worse.
His problem is plain to me. Large data set remains in memory when not needed. I'm guessing that invoking the the properties and methods also creates copies of that data which remain in memory. I personally would have used a database to store the data and a class accessor to manipulate it (if I used classes...lol) but each to his own.
So when's 8.6.2 out?.
-
QUOTE (ShaunR @ May 2 2009, 08:04 AM)
Like this. Its very easy to manage.
-
QUOTE (MJE @ May 2 2009, 05:50 PM)
The real power of your way of doing it is you can use the callbacks to register for events generated outside of LabVIEW that are exposed in .NET or ActiveX objects. Basically, using the callback mechanism you used, LV code can synchronize with virtually any modern Windows code.Funny you should say that.
When I found it. It was used for hooking the I.E. browser Active X control (and its on the .Net pallet so presumably that was the intention). I'm not clever enough to come up with these things on my own
But I am ruthless enough to exploit them for every ounce of worth 
However, I have an aversion to active X and the obese .Net (for many reasons but the main one being, if I don't have the source, I can't use it). But I did see a potential for using it within Labview for a scenario that I'd been working around for a while and wasn't satisfied with. And as I explored, a whole new mechanism for inter process comms opened up with (it seems) few drawbacks.I think what I like about your Message Pump implementation is that it it goes far enough to be more than useful without being so huge and complicated to make it unusable. I see many OOP module designs (not just in Labview) that try to be all things to all people rather than a base from which people can start.Your porridge is "just right".
-
QUOTE (Aristos Queue @ May 2 2009, 03:40 PM)
In the second, LV doesn't have a "delete" or "freemem" command, so I am not sure to what you are referring. Could you describe this manual method that you're using?The Request Deallocation function might be of use here
QUOTE
When a top-level VI calls a subVI, LabVIEW allocates a data space of memory in which that subVI runs. When the subVI finishes running, LabVIEW usually does not deallocate the data space until the top-level VI finishes running or until the entire application stops, which can result in out-of-memory conditions and degradation of performance. Use this function to deallocate the data space immediately after the VI completes execution.
Data entry according to input
in User Interface
Posted
QUOTE (Ton @ May 9 2009, 03:06 PM)
Personal preference.
For me. I like to see controls/indicators and their associated property nodes at the same level so I can see whats going on and apply probes without delving into sub-vi's. I had one bug in someone elses application that I needed to fix where on certain occasions a particular control would change its decimal places and others their colour when they shouldn't. The culprit was 5 levels down the hierarchy from the vi's affected and was a property node that changed the DP (amongst other things) dependent on a limit test supplied from another parts of the code (they didn't include the upper limit).