Rolf Kalbermatter

QUOTE(PeterB @ Jan 27 2008, 06:34 PM)

Sorry to say Silmaril, but Stephen Mercer seems to think otherwise ! User Events don't require a context switch to the UI thread.

Refer to http://forums.lavag.org/Event-Structure-as-State-Machine-t9502.html&view=findpost&p=38468' target="_blank">this post.

regards

Peter

But they execute in a structure that also handles all the normal UI events that WILL switch to the UI thread for sure. And also might contain a timeout case that will also snoop some time for handling.

ONe extra point. Queues are very specifically optimized to NOT copy data at all but instead use the reference to the data instead. User events might not be able to use the same optimization in all cases or even at all, especially if you use multiple event structures to receive the same event.

Rolf Kalbermatter

QUOTE(ashwin @ Jan 26 2008, 09:32 AM)

Hi Jim,

I am trying to receive a DATAREADY message from a USB based DSO ASB3000 using its driver DLL.

Can u tell me how to use ur VIs for receiving a message from a Device?

You can't.

For a driver to inform you of something it must implement some kind of event notification. For DLLs there are two possible solutions, they can either allow you to install a callback function that will be called when an event occurres or they can use OS events to inform the caller about such an event. In any case these are things that are not directly translateable into LabVIEW events so you will basically have to write a wrapper DLL that calls your Device DLL with the event notification method that your driver uses and translates it into something more LabVIEW friendly such as a user event or occurrence.

C programming knowledge will be required for sure to do that.

Rolf Kalbermatter

QUOTE(Yen @ Jan 25 2008, 06:52 AM)

A zombie thread indeed, but it is a valid point.

The key phrase here is "when fired". The garbage collector is only called when the top level VI in the hierarchy is done executing. Until that point you can have memory leaks if you don't close the references, and since some people (me, for instance) have programs which run for months and years without being closed, closing references is a good practice.

Additionally, some .NET classes require calling dispose methods. My understanding is that if the disposed method is implemented using the IDisposable interface, then it will be called automatically when the reference is closed, but if it is not, then it must be called explicitly.

You can find some more specific details http://detritus.blogs.com/lycangeek/2006/05/how_to_say_good.html' target="_blank">here.

Yen you are right here, but there needs to be some extra clarification since a LabVIEW refnum is a memory resource too, and I have trouble to believe that .Net will have any influence on the life time of that refnum itself, even if .Net has a very smart Garbage Collector.

It may invalidate (but probably won't since the LabVIEW refnum holds a reference to the .Net object) the .Net resource that was referenced by the refnum, (and possibly though not for sure, the Not A Refnum node may be able to detect that too), but it most likely will not dispose of the LabVIEW refnum before the Top Level hierarchy that created it goes idle.

So Your concerns are fully valid and Big Hanks claims are likely to be not the full story with using .Net in LabVIEW.

Rolf Kalbermatter

QUOTE(Jim Kring @ Jan 7 2008, 08:18 PM)

There are tools for extracting CHM files, although I haven't used any of them. Check out the Microsoft_Compiled_HTML_Help wikipedia page for information. And, if your looking to create your own reader/writer, then you can use the documentation, here, which somebody already reverse engineered.

Well that last link talks about IStorage file format. So this would mean it is basically an OLE structured document format just as the older MS Office file formats. The difficulty about this is of course that the OLE structured document format only defines the container structure but not the actual contents in the streams. It's much like XML without any schemata.

I'm not sure if chm is OLE structured document format but if it is, I think the description in that document is a bit limited. It may work most of the time but assuming that it will be always like this is going a bit to far. The actual layout concerning the different OLE streams could be changed by adding additional, non-standard streams to the document and suddenly the fixed offsets are not so fixed anymore.

Rolf Kalbermatter

QUOTE(mballa @ Jan 22 2008, 10:31 AM)

Hi Dan

Welcome

can you post the code or a link to the sql_LV.

Hi Dan, welcome too.

mbella: It's always so amazing what Google can do for you http://performancemicrowave.com/sql_LV.html' target="_blank">SQL LV

Rolf Kalbermatter

QUOTE(Jim Kring @ Jan 21 2008, 09:10 PM)

Probably for cross-platform windowing abstraction layer.

Not very likely for LabVIEW's UI widgets itself. Porting the existing widget code they build themselves since LabVIEW 2.5 on the various platforms to Trolltech would be a complete horror with many bugs, and functionality they simply can't implement on top of Trolltechs QT.

It seems to be related to some of the configuration utilities that got added recently. There is a http://forums.ni.com/ni/board/message?board.id=170&message.id=276416&requireLogin=False' target="_blank">thread on the dark side about it, where someone had troubles with it since his external code (Surround SCM) was using a different version of QT that clashed with the one LabVIEW was using. Apparently the Multi-Variable Editor is the whole story why QT is used and that is in essence a DSC feature only. However as that thread shows the QT libraries are loaded into the LabVIEW process independant if the DSC system is used or not. Why they wouldn't write the Multi-Variable Editor as LabVIEW Vi is a bit beyond me though. LabVIEWs widget tools are quite up to par with QTs.

Rolf Kalbermatter

QUOTE(sara @ Jan 21 2008, 04:43 PM)

Thanks alot for your help

but in my table i want to take the value of the first columns and first row and compare it with the date of the computer and when it equal the value of the second colums and first row extact out .

So can I make this by using table control or i need another way

How about reading the LabVIEW manuals concerning LabVIEw controls, datatypes and especially strings and arrays?

Rolf Kalbermatter

QUOTE(sara @ Jan 21 2008, 02:51 PM)

Thank you for your reply

but how i can make the table which have proper value VI is accepted?

Well you will have to store it somewhere. A poor mans choice would be a tab separated spreadsheet file to start with. Doing it more complicated would be nice but start out with something that you know you can do.

Rolf Kalbermatter

QUOTE(tcplomp @ Jan 16 2008, 01:53 PM)

Well first you should make sure it is possible to open an app reference from two computers to the same app (port) on a third computer, I doubt it.

This is no problem for the VI server. It can handle multiple client connections in parallel.There are some application properties (private I think) where you can monitor the connections and I think limit or even drop some of them yourself, but normally it can handle multiple connections.

As to the original request, I'm afraid there is no way you can retrieve the remote address and remote port from an existing Application Reference.

Injecting a VI into the remote side that you can then execute to retrieve the remote sides local parameters would be the only idea that I have. However I don't think any of the VI server stuff allowing to execute VI code that exists as a memory stream will be accessible remotely because of security concerns. So you would have to get that VI on to that computer in some way that requires physical access to it.

Rolf Kalbermatter

QUOTE(tcplomp @ Jan 15 2008, 12:10 AM)

If you call the VI dynamically and close the VI reference LabVIEW will also make the memory available.

Ton

That is a very good remark. As it seems to me Mikail has some sort of test application. This is in most cases the ideal application to use dynamic execution of the test steps as in some sort of plugin architecture.

Also what I suspect is that he maintains the data in a front panel control/indicator or something through locals. If he would use shift registers, Request Deallocation would not have any influence since the shift register needs to maintain its data between executions. On the other hand shift registers allow programmatic clearing whenever desired. This means that for using shift registers which among other modern constructs like queues is the way to store intermediate data, Request Deallocation is getting rather useless. I feel that Request Deallocation makes no sense in 99.99% of the cases for a properly designed application.

Rolf Kalbermatter

QUOTE(TiT @ Jan 14 2008, 04:18 AM)

Hello,

Does this actually works for you ? I have WIN XP Pro and for me the only information that is correctly read is the timezone, all the other information that are read do not correspond to the actual windows date and time ; and the write function does not seem to have any effect

Any idea ?

They do work but they do not return or modify the actual time in DST and non DST format but the current switch over time to start DST and end it.

Rolf Kalbermatter

QUOTE(NateO @ Jan 10 2008, 04:34 PM)

Sorry if this is in the wrong place, I'm new to LabView and even newer to this forum. Please go easy on me.

We're looking to build a real time data acquisition system that runs on an x86 based PC/104 single board computer. We'd like to use LabView to do the software development but I'm having a heck of a time finding any information about what would be required to make a LabView application run successfully on a PC/104 SBC. Specifically, what are my operating system options (I know VxWorks will work, but are there other RTOS's out there that will do?) and are there any minimum system requirements I need to worry about?

I appreciate any help or advice you can give me. Hopefully I won't be asking silly questions for long.

While VxWorks is used for the NI-RT targets such as newer Fieldpoint Modules or CRIO controllers I do not think you can just go and install any VxWorks OS and then use that from LabVIEW-RT. The RT OS on those targets definitely has been customized to allow LabVIEW RT to directly work with them. The other option that is more likely to work is the Pharlap OS. NI sells the LabVIEW Real-Time Deployment License for Standard PC's- ETS RTOS which is based on this OS. There you have official support to install a LabVIEW RT supported RTOS on your own computer hardware although there are some specific requirements such as for the network interface.

The only other solution I see if you want to use LabVIEW is LabVIEW Embedded. But there you have to customize the environment to interface to the tool chain for your target system, if you dont happen to use a target that is already supported and I'm not aware of an already existing PC104 target.

Rolf Kalbermatter

QUOTE(guruthilak@yahoo.com @ Jan 14 2008, 01:29 AM)

Hi there,

Could some one explain little more about "Request Deallocation " this function? (Apart from whats there in the NI Help )

Can i use this in all the subvi's thats been called by the "Main" vi ?

Is there any limitation for the same?

You can but it is not a magical wand that makes your programs go faster or work better just like that. In fact it is likely it will make them much much slower. Request Deallocation tells LabVIEW to deallocate all memory that is not currently in use. And that will deallocate memory that a VI that is currently idle may just need 1ms later again to do its work so it has to allocate it again instead of being able to reuse it.

Request Deallocation only makes sense when you have a VI that uses lots and lots of memory and only runs once or maybe every two weeks in the lifetime of your application. Doing a Request Deallocation right after executaion of that VI may (or may also not) improve the memory consumption of your application. Otherwise this function causes more trouble than it would solve, which is why it isn't very prominently made available.

Rolf Kalbermatter

QUOTE(guruthilak@yahoo.com @ Jan 7 2008, 11:16 PM)

NI INDIA is of no help. They dont know anything about it

Any other way of doing it other than importing from LV 7.X

By the way Chris, do u remember me ?

The only people really knowing about this are in the LabVIEw development team at NI corporate. And no that license is not for sale! You need to have a very strong case and good connections that anyone at NI will even acknowledge that there is something like such a possibility. I would expect maybe three or so Alliance members worldwide being allowed to use that feature. And no we are not one of them, I use the other methods mentioned elsewhere on this forum for the few times I happen to have time to dig deeper into this.

Rolf Kalbermatter

QUOTE(BrokenArrow @ Jan 7 2008, 07:49 PM)

Thanks for the test Ned. The speed might also have something to do with Windows running junk in the background, virus-this and nanny-that.

True regarding the Build Array in loop, but VI Analyzer said it was a no-no, whereas the attached VI had no issues. Seems like VI Analyzer would be smart enough to see that it's a set number of elements and not wag the finger at me.

If you had this VI running, say 50 times a second, would you use the "zero" timer or not?

Vi Analyzer is some LabVIEW versions old now and its analysis might have been correct when it was implemented. LabVIEW does make optimization improvements with every new version.

That said Build Array is not a complete no-no. Sometimes there is no way around it or it is in a loop that executes only a few times. But it should always be checked and double checked if you do not want an application that gives you way to much coffee time when it is run.

Rolf Kalbermatter

QUOTE(vituning @ Jan 4 2008, 11:45 AM)

Thanks for the input! The byte array you see me using for that char * input was a futile attempt to get this to work. I also tried it with conventional strings there. I'm almost positive the problem lies with the cluster -> struct conversion. I wired 51, 51 and 21 to the array size for those strings in the struct to allow for the null character in the return string. Again, I'm shooting in the dark here, and think that this is basically impossible to do using the call library function node straight up like this.

You can't do that in LabVIEW like that. A Byte array (and a string) in LabVIEW is something very different from a C pointer. When you pass such an element to the Call Library Node and configure the parameter as C pointer, LabVIEW will do the translation for you but inside a cluster is something LabVIEW won't do (and in fact can't do without a configuration dialog that would intimidate anyone but the most diehard C freaks).

You would need to treat it as an uInt32 and then do the pointer to array data and vice versa in the LabVIEW diagram with the use of more CallLibraryNodes calling into external functions to copy data in and out. As to this function it is not clear if the caller is supposed to allocated the necessary pointers with the required size or if the function will allocate them. In the first case you would need to call even more external functions to be able to do that, in the second case there would need to be a driver provided function to deallocate those pointers again.

All in all a real pain and this particular API is very unfriendly to callers in general! It's even hard to call in C and simply a pain in any other environment.

Rolf Kalbermatter

QUOTE(crelf @ Jan 2 2008, 02:35 AM)

http://lavag.org/old_files/monthly_01_2008/post-181-1199259246.png' target="_blank">

Congrats Tomi, and thanks so much for all your wpmderful posts so far. ;beer; here's to another 1k!

Very nice Tomi! Congratulations to your insigthful and interesting posts here on LAVA. Looking forward to more of them!

Rolf Kalbermatter

QUOTE(Kyuubi™ @ Jan 2 2008, 01:46 AM)

Please help me on how to create toolbar in labview 8.2 :headbang:

How about searching through he examples under Help->Find Examples? Gives you a simple example using the Splitter bar!

Rolf Kalbermatter

QUOTE(aart-jan @ Jan 1 2008, 07:57 PM)

Hi all,

I am building an application that accumulates lots of data. There are also some microphones involved to add some context to the measurement while postprocessing. The measurement will run autonomously and therefore I need to save disk space where ever I can.

I am saving the sound information as WAV files, and I would like to compress them as much as I can. I will use a frugal format of 11025 kHz single channel 16 bit data.

I experimented a bit with compressing to zip, rar, OGG and MP3. A file size of 948 KB compressed as to the following sizes:

original 948 KB

zip 719 KB :thumbdown:

rar 577 KB

OGG 178 KB

mp3PRO 133 KB (86% compression!) :thumbup:

The difference between OGG and mp3PRO is circumstantial, since I tried hard to optimize the settings of the mp3 codec. The sound quality is not an issue and I really couldn't even hear the difference anyway.

Obviously I would like to encode the data to mp3, and there lies my challange: what utility to use to programmatically encode data to mp3?

Normally I would look for a tool with a good command line interface. But it would be awsome if I could somehow do inline encoding. Maybe via a pipe? Suggestions are very welcome.

Also I have this issue with the system exec.vi I normally use to make command line calls: The VI will only run the command correctly if I make the flag "run until completion" true. This is a real issue, because I really do not want to lock up my code while encoding wav files.

Your suggestions are much appreciated!

If you just want to encode the data after it has been acquired entirely the command line tool approach should work. For longer sound acquisition this may not be desirable and in that case I would simply create an interface to one of the existing open source compression libraries such as Lame, through the Call Library Node. But there is one issue with MP3 that OGG probably wouldn't have, and that is the fact that some companies try to squezze money out of every use of MP3 encoding software. So your application while working technically alright may have legal issues. probably not an issue for a home grown hobby application, but certainly a problem for a professional application.

I'm not sure about the "run until completion" true problem though. I haven't seen this yet and I do make use of the system exec regularly.

Rolf Kalbermatter

QUOTE(tcplomp @ Dec 29 2007, 01:09 PM)

Well LabVIEW has an ASCII table included: <ctrl-?>, search, ASCII Codes, and at #29 is a table.

But unfortunately it's incomplete, only the first 127 charactars are shown.

Ton

It's complete. ASCII doesn't define more than that. The rest are extended characters that depend on the currently set local, the font used etc, etc.

Rolf Kalbermatter

QUOTE(psi @ Dec 29 2007, 05:47 PM)

Desktop PC as LabVIEW Real-Time Target is interesting and not expensive solution using OS ETS.

Converting a Desktop PC to a LabVIEW Real-Time Target

Requirements for a Desktop PC as a Real-Time Target

Hmm, you will have to buy a runtime license per system, and that is about 500 Euro in single quantities.

Interesting yes, not expensive only if you are not planning to make an embedded device, although I'm sure you can negotiate volume license prices.

QUOTE

Yes for desktop PCs but not for arbitrary embedded development systems. For some reasons I was assuming that embedded was the route the OP wanted to go.

Rolf Kalbermatter

QUOTE(psi @ Dec 28 2007, 05:51 PM)

I think, that it is better to you to use LabVIEW Real-Time Module instead of Embedded. Operational system ETS supports Windows dll. Look http://labview.ilc.edu.ru/forum/showthread.php?t=434' target="_blank">here In more details

But LabVIEW realtime only supports NI hardware targets (some of them use Pharlap OS and other newer ones with PPC CPU use VxWorks) and somewhat specific x86 hardware with Pharlap (ETS). If the OP wants to use NI hardware targets or can live with a more or less standard PC hardware platform then LabVIEW realtime of course would be best.

Rolf Kalbermatter

QUOTE(Dr. Dmitrij Volkov @ Dec 28 2007, 09:07 AM)

I plan to develope embedded software for real-time system using LabVIEW (OS VxWorks).

Previous system was developed using C++.

For Windows platform I could use dll libraries with old code.

What is preferable way to reuse existing C++ code under VxWorks? As I understand dll libraries aren't supported with VxWorks

Thanks in advance.

Happy New 2008 Year

The equivalent of DLLs in VxWorks are .out files. They are basically shared libraries created with either the VxWorks development system or the free GCC compiler. I've only created one of them so far using the freely downloadable GCC version for VxWorks to create a shared library for NI's newer real time controllers.

But I'm not sure what you are trying to do here. LabVIEW for VxWorks is only available for the NI realtime target systems. For your own VxWorks based systems you would have to go the LabVIEW Embedded route. Not very cheap but maybe you are doing that already.

Rolf Kalbermatter

QUOTE(Yen @ Dec 21 2007, 07:59 AM)

As I was chasing myself in the game, I remembered what this really reminded me of - an old Heilein story called "And he built a crooked house". A quick search for links brought me to this Wikipedia article about tessarcats which has some nice animations:

A well Heinlein :thumbup: . Certainly an interesting author. Although I wouldn't share every of his visions and he seemed to have some militant ideas at time, he also had a very impressive way to describe environments and social interaction that were strange and bewildering, while at the same time still somehow believable. My first contact with him was by stumbling more by accident over "Stranger in a Strange Land" and it took me quite some time and writing an essay over this book for school to see the finer points of this book. And it changed the way I looked at many things remarkebly.

Rolf Kalbermatter

QUOTE(Yen @ Dec 19 2007, 03:15 PM)

Luckily, the new VI object ring holds the names for most primitives and the rest could be added by hand, but I would like a way to be able to easily parse palettes for VIs and unfortunately, the palette API can't be backsaved from 8.0. Does the resource manager API you mentioned work before 8.x? Can you provide some pointers (functions and their definition). The only thing I really need is to recursively list palettes and the titles of the VIs they call.

At the moment, I figured that as a workaround this could be done by parsing the actual directories, but that's a really bad solution.

Well, yen, I think you might be right that the built in nodes may not really have a string name in the palette menu, but only a resource identifier, that points back into LabVIEW (or one of the .rsc files in the resources directory). It's a long time since I looked into this. I'll see what I can do in terms of getting the resource information in a more user friendly way into LabVIEW. But I need to search that stuff and most probably clean it up a bit.

Rolf Kalbermatter