Jump to content


  • Posts

  • Joined

  • Last visited

ahlers01's Achievements


Newbie (1/14)



  1. ZITAT(Kevin Payne @ Apr 21 2009, 09:33 AM) If you have a PDA, you might be interested in this nice emulation... I use it on my HP iPAQ, so I don't have to unlearn RPN...
  2. ZITAT(Ben Zimmer @ Jan 3 2009, 05:37 AM) Hi, I use the services offered by http://www.origo.ethz.ch/, and I am so far very satisfied with it. The big pluses for me: - they also host closed source projects - the server location ETHZ (the 'European Harvard' Eidgenössiche Technische Hochschule Zürich) should be a very reliable one... - anf of course it's free You might want to give it y try. Franz
  3. ZITAT(Ronnie @ Jan 30 2008, 08:49 PM) It will work with all pdfs, but of course only text will be converted. And don't expect that it converts all text correctly. Ligatures, e.g., are not converted AFAI remember. You've got to try it... -Franz
  4. ZITAT(Ronnie @ Jan 30 2008, 06:27 PM) Yes, it can be done, but not in a straightforward way, AFAIK. When I did it some time ago, I used a (free) utility 'pdf2txt'. Google will show you where to find it. I called 'pdf2txt' with LV's 'System Exec.vi' to generate a temporary txt file, which then could be opened and analysed. If I find my old VI I'll post it here..though it's not difficult to rewrite it once you have the pdf2txt.exe. -Franz
  5. I also thought about using the .NET file dialog since I want to include a file preview thumbnail within the dialog (something which is not possible with LV's built-in dialog, AFAIK). I found this thread as a starting point for using .NET and of course was stuck then by the 'dialog not on top' problem. There is a workaround though. (I couldn't get the other workaround offered in this thread to work) By using a WinAPI call ('Move Window to top.vi' from lvwutil32.llb) the dialog can be brought to top: the subVI code is this: Interestingly this does not work when the 'Move window to top' call is in the subVI... -Franz
  6. ZITAT(yasmeen85 @ Dec 8 2007, 06:23 PM) Yasmeen, you might want to have a look at the example ...\National Instruments\LabVIEW 8.5\examples\general\uievents.llb\New Event Handler.vi The example is meant as an introduction how to use (user-)event handling in Labview, but it also may help to answer you question. In the example 2 subVIs open their front panel when a corresponding button on the main VI is pressed. The subVIs are declared to be 'modal' in this example: That means that no other LV window is accessible before the modal window is closed again. Therefore no two sub-windows can be opened at the same time. If you want to switch off the 'modal' behavior please look under the topic 'Customize Window Appearance Dialog Box' in the LV help to see how to proceed. However, in the given example switching off 'modal' would not make sense since the 'Analyze' sub-window can only do a meaningful job when the 'Aquire' sub-window (or subVI for that matter) has terminated. Whether a subVI with opened front panel should me made 'modal' or not depends on the intended application. Hope this helps, -Franz
  7. AFAIK those VIs are part of the Wavelet toolkit, which needs to be purchased separately addition: Searching for 'detrend' in www.ni.com I found that there also is a 'detrend' function in Mathscript. And the wavelet toolkit I couldn't find anymore, maybe it is now integrated into the Advanced Signal Processing toolkit
  8. Thanks, I knew that one and I used it long time ago for retrieving data that had been measured with a 'quick&dirty' assembled aquisition program. I hadn't even found the time to write the 'save to file' part of the VI at that time and therefore used the data logging feature of LV. In order to retrieve the data for processing later I used this 'enable data base' access trick. It all worked nicely but at one point I changed the main VI (added or modified controls) and didn't save the old version. I could no longer access the old log files, since they are binary and could only be read when the controls and indicators were exactly as specified in the log file's header part. After that bad experience I stayed away from the log files, but I agree that the technique might be helpfule here. I'll check it out. But for now I finished the XML approach and I attach the first version here, maybe it is helpful for others: Download File:post-833-1163876298.vi regards Franz Thanks for the tip, Ton! I actually had thought about that but I had problems lately to download the OpenG software. Do you know a working download link? Franz
  9. I can't get the 'Convert from XML' function to work when the input type is a variant, see attached code. Am I doing something wrong, or is this a bug? Code picture: Code: Download File:post-833-1163832727.vi ********** UPDATE*********** I found the answer to my question at this ni.com site where it says: "Although you can flatten LabVIEW variant data to XML, attempting to unflatten variant data from XML results in an empty LabVIEW variant". So it's a feature, not a bug. Background: I wanted to write a VI which stores all control values of its calling VI to an XML file, and reads them back. In my first approach I had accessed the calling VI's 'Panel' refnum to obtain the Controls[] refnum array and from them the Value property, which is a Variant. That I wanted to write and read to XML. This does not work due to the reason above. I will now try to use the 'Get all control values' method node to access the calling VI's controls. That method delivers a (flat data|type desc) pair for each control, which should allow to do what I want. BTW: A VI doing what I describe above should have been written by someone already, but I couldn't find it. I'd be grateful if there is such a VI and somone can point me to it. -Franz
  10. To me it seems that Search and Replace Pattern.vi IS able to remove the tags, see attched example. Can you post a specific example where it doesn't work? (Or maybe I misunderstood what you want to achieve?) -Franz Download File:post-833-1160287566.vi
  11. mpa, if you listen to the Mistaken Podcast you will know that a native OO in LabVIEW is not too far in the future. It might be worth while to wait for it. -Franz
  12. I had a look at your equation. If I read it correctly, you can substitute z:=x+a*y and then bring the equation to the form x=f(z). You could then try to use this for non-linear fitting, treating x as the dependent and z as the independent variable. Also I would recommend you normalize your values in such a way that reasonably sized coefficients occur, not ones which differ by 23 orders of magnitude. That would probably help to avoid numerical errors -Franz
  13. Is there somewhere an up-to-date listing of these undocumented .ini settings? I used to look them up on Brain Renkens page http://labview.brianrenken.com/INI/ (and the LAVA FAQ http://forums.lavag.org/index.php?showtopic=299 also still refers to that URL), but I cannot find this supersecreteprivate stuff there. regards Franz
  14. o.k., I got it running now. The execution speed results you obtained are indeed very interesting. I basically could confirm all the timings you obtained. In addition to your tests I added one where the whole array is passed to the subroutine (which contains what you call 'inline' code). Interestingly the subroutine performs slightly faster when you set the priority not to 'subroutine', but to 'time crritical' only. The fastest pure-LV solution i came up with was one where the formula node (with external indexing) is put in a 'time critical' sub-VI, and where the cos calculation is replaced by sqrt(1- sin*sin): It is nearly as fast as the lcc-array solution, as the green line in the following diagram shows (the diagram lists msec used for 500000 array length): So the LV solution is only 10% slower than the lcc one (and faster than fortran), unless you speed up the dll code by avoiding the cos calculation there, too. Remarkably, the timings of the two LV-subroutine solutions (black and green lines in the diagram) are much more constant than the timings of the inline, lccc and fortran solutions, which sometimes are longer due to some backgrounf activity in the system. That becomes especially obvious when I did not turn of my PC's DSL network. The following diagram shows the timings with network on (in the above diagram it had been off): The black and green curves are 'unimpressed' by the background activity, the others obviously not. (I wonder if they become more stable, or even faster, when 'wrapped' into 'time critical' subVI) In conclusion, I would say that it is possible to have a fast floating point meth in LV which nearly reaches a DLL implemetation. Inline code is not necessary, IMO, since the 'time critical' subVI method can be used. BTW: I obtained my results with a beta version of LV 8.2, since I had all older LVs uninstalled. I attach a copy of my VIs which is saved for LV 8.0: Download File:post-833-1148831147.zip
  15. Hi bsvingen, LV complains about a missing 'salflibc.dll'. Could you post that one, too?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.