Rolf Kalbermatter

QUOTE(Jim Kring @ Sep 7 2007, 10:22 AM)

I don't think anyone has mentioned this yet, here...

In LabVIEW 8.5, you can implement a Functional Global without any loop:

• http://thinkinging.com/2007/09/07/functional-globals-in-labview-85-no-loop-no-joke/' target="_blank">Functional Globals in LabVIEW 8.5 - No Loop, No Joke
  

Just learned that yesterday at the local LabVIEW day here in the Netherlands, presented by Jeff Washington.

His example had a loop but was about pipelined execution and boy I can tell you that although I'm excited about this feature, it does need getting used too. Basically with this node you sort of have to forget a few things about data flow and wire dependancy.

And yes Jeff mentioned that the original Feedback node was implemented by an intern and they had thought he had chosen to implement it simply as a folded shift register but that seems to not have been the case and that is why it was much slower than a shift register. In 8.5 however Jeff claimed that the Feedback register should in all aspects we as user could possibly measure, behave exactly as a shift register.

Probably there is also already an NI patent pending for it :-)

Rolf Kalbermatter

QUOTE(wbiker @ Sep 7 2007, 04:02 AM)

It is really big application to show the code I would have to present ~200vi's.

Please give me just some ideas what it can be.

Most likely you either call some external code incorrectly when this event occurres or probably also possible you do not close properly some functionality contained in external code which makes it hang. Another possibility is that you have multiple loops in your application and one of them instead of exiting too, starts to run freely without any asynchronous delay function in it anymore.

But without seeing some of your code and preferably a seriously scaled down application that exhibits still this behaviour it is not possible to give you more specific advice.

Rolf Kalbermatter

QUOTE(TobyD @ Sep 6 2007, 10:32 AM)

Like This:

http://forums.lavag.org/index.php?act=attach&type=post&id=6859[

Or before there was VI server, like this:

http://forums.lavag.org/index.php?act=attach&type=post&id=6875

Rolf Kalbermatter

QUOTE(wbiker @ Sep 7 2007, 02:28 AM)

Hello,

I have a problem with quite complex VI. The problem is that when I'm trying to finish (by clicking STOP BUTTON in an event structure) VI gets suspended, CPU ussage goes to 100%. This state can last a few minutes or forever. This behaviour can be seen mainly after long time VI working.

Application was tested under LV 8.2 and 8.21 as .exe and .vi - behaviour is the same.

Thanks in advance for your help.

wbiker

By clicking the stop button on the toolbar you are not stopping the VI but really aborting it. If the program execution was at that point in an external code part you can end up with a locking situation since the external code may wait one some event message processing which will not happen anymore since the whol application was basically taken down brutally. Most NI drivers especially in newer LabVIEW versions are writting in such a way that they get informed by LabVIEW about aborts so that they can abort any waiting, but third party drivers usually don't have that, also because the means to be informed by LabVIEW about aborts are not really documented. But even NI drivers can still sometimes get stuck in such a way.

The toolbar stop button is really just a last measure to abort a program or for quick and dirty testing but should not be used as normal way of starting and especially stopping a LabVIEW program. The LabVIEW program should have some sort of event processing with an explicit quit button in which case the event processing loop (and any other parallel loop that might be running) gets properly terminated after which you can clean up any DAQ, Instrument, IO-Bus, etc operation properly by closing those resources and once the last item on the diagram has executed the program stops too, but this time cleanly.

Rolf Kalbermatter

QUOTE(Karissap @ Aug 31 2007, 01:38 AM)

You should be able to do it yourself though with windows dlls or active x.

Only if you are quite good at C and integrating that through a DLL into LabVIEW. The System Tray API in Windows uses callbacks and integrating that with LabVIEW is not trivial. ActiveX should be easier but I don't think there is a standard Windows ActiveX control that does System Tray.

QUOTE(MikaelH @ Aug 30 2007, 08:17 PM)

The .Net System tray API seems to have a problem somehow. I've seen several applications using that and they all seem to not remove the icon from the system tray when the application closes. Apparently there is no way to properly cause such an icon to disappear, especially when the application closed unexpectedly.

Rolf Kalbermatter

QUOTE(LV Punk @ Aug 29 2007, 06:26 AM)

Your program can be split into two loops; one to capture the RS-232 data, and the other to post-process and display the results. I've attached a modified version of your program; the upper loop reads the RS-232 data as quickly as possible, and places it in a queue. The lower loop periodically flushes the queue, selects the last element and converts it to coordinate data as before.

Adjust the wait-next-multiple input in the lower loop to determine the display quality. If the VI still runs slowly, then you will need optimize other parts of your code. I'm curious to know if this alone will improve your performance (I'm guessing it will :thumbup: )

Since you plan on throwing away any but the last data anyhow a notifier may be better than a queue in this particular situation.

Rolf Kalbermatter

QUOTE(jlokanis @ Aug 29 2007, 12:43 PM)

Has anyone written a VI that will take a simple math formula in a string like:

1+2-3

4+(5*3)

3-(4+5)

And return the computed result?

I know that NI provides this function in the Eval Formula String.vi in the Gmath library but that is the problem. They put this in a lvlib file. I am trying to build an application with the OpenG builder that includes this function and discovered that the OpenG builder cannot deal with lvlib files properly. Since my application is dependent on the namespace feature of the OpenG builder, my only option is to reinvent this math function myself outside of a lvlib.

I have tried to find a way to extract this from the lvlib with no luck.

Well if you have a LabVIEW version before 8.0 somewhere you can copy the stuff from there. There was no lvlib before 8.0.

Alternatingly I wrote long ago a library that works similar to the NI Eval Formula function but is implemented a bit differently dividing the evaluation cleanly into a parser that creates UPN stack intermediate code and an evaluater that operates on that intermediate code. I needed that for speedy calculations where user entered formules would be needed but they didn't change all the time, so parsing the formula once and then evaluating it over and over again had some serious perfomance advantages. The parsing is not trivial but a lot more streamlined than the NI code and the entire thing is also faster.

It hasn't been updated for several years but worked fine for what I needed it.

LabVIEW 5.0 ExprEval.zip

Rolf Kalbermatter

QUOTE(adriaanrijllart @ Aug 29 2007, 11:41 AM)

To Rolf: I was expecting this would not be easy directly in LabVIEW due to the low-level stuff a secure protocol requires. Thanks for all the details. I also like to say "Hi" because I remember we have met in Geneva many years ago.

Hi also. I do remember having met you and yes it is quite some time. In the meantime I'm living for already 11 years in the Netherlands ;-)

Greetings

Rolf Kalbermatter

QUOTE(adriaanrijllart @ Aug 14 2007, 12:48 PM)

Hi,

Does anyone know whether there are Labview VIs to act as an HTTPS client? The Internet Toolkit only seems to support HTTP, but not HTTPS.

As far as I know it doesn't exist and the chance that it will is small. HTTPS requires a serious amount of encryption technology and writing encryption code in LabVIEW is not the most efficient thing to do. But the most critical aspect is the fact that writing encription routines is a tricky business that not many people know about, and unless you are an absolute pro in that area trying to do it is likely to not work or even worse pose serious security risks when using that code. Most people using LabVIEW are simply not professional encryption/security specialists.

Using existing C code has the problem that the actual HTTPS encryption actually is put at the lowest level just above the network protocol. So there would be only two possible ways:

1) inject an HTTPS encryption layer into the TCP/IP stack so that LabVIEW does not deal with that encryption at all. This is very difficult to do and would require some state aware encryption layer in a low point of the entire protocol stack that depends on the protocol state of a higher layer. Not really a good idea. Better idea in that context would be to use something like putty and just create a secure tunnel through which the normal HTTP protocol goes. This would require that you can influence the server side too, as you would have to setup an according VPN or similar connection.

2) using the C libraries implement the HTTPS protocol on top of the LabVIEW TCP/IP primitives. Technically the right way but so much work that I would not even consider doing it unless I can find a government sponsored project that would pay for that :-). In short forget it as it would be quite expensive already! Well cheaper and more secure than trying to implement the HTTPS security infrastructure entirely in LabVIEW, but still not practical.

Rolf Kalbermatter

QUOTE(paracha3 @ Aug 23 2007, 10:05 PM)

We are using Design Sync as our company wide SCC which LabVIEW 8.x does not support in project environment. Does anybody know

1- If there is a way to write your own SCC plugin for LabVIEW project that would perform checkin/checkout etc operations on the files in project without users going through the command like interface of the SCC we use?

2- If there is a way, can somebody point me to right direction? How to get started on writing your own plugin?

Thanks

Abdullah R

Tomi has been right with all his recommendations. No need to use a Visual Source Safe compatible interface, unless you want to invoke the source code control actions directly from within LabVIEW. In my experience using SVN with Tortoise SVN however works actually better. Of course you need some discipline but that is in the nature of source code control anyhow.

One extra note, if you really want to access your source code control system directly from within LabVIEW you do need a Visual Source Safe compatible interface plugin. LabVIEW simply interfaces to that API and accepts any compatible source code provider that has been registered in the system. If you can't find a commercial interface for your SCC (but if it is popular at all in any means you probably can) you would have to write it yourself. From what I understand it is not to difficult to do that but the API is considered proprietary information by MS and you only get it by signing an NDA, or at least that was the situation last time I checked into this.

Rolf Kalbermatter

QUOTE(RiverdaleVIEW @ Aug 21 2007, 07:58 AM)

My C may be a litle rusty, but is "**A" the proper way to declare a 2D array? Won't that just declare a pointer to a pointer?

I'd try using an array format in the prototype, and pass in a 2d array initialized to the proper size in LabVIEW through the pointer in the Library call.

Well a 2D array in C is VERY ambigious. Without knowing more exactly what the programmer did intend and use you can generally not say for sure how it is implemented just from the prototype.

You can implement a 2D array as one single chunk of memory with allo rows (or for the kick colomns) put after each other). This is the way LabVIEW handles 2D arrays. It is as far as the memory layout is concerned just a single 1 dimensional array with all rows streamed (serialized). This is pretty efficient and cool with one single drawback. Since you only know the number of rows and columns for such an array each row will have to have the same length, resulting really into an array of rows * columns elements.

Another possibility is to create an array of pointers to 1D arrays. This results in the int **a syntax and is a bigger load for the memory manager. This array can NOT be created nor passed by LabVIEW directly to a DLL nor exported from a LabVIEW DLL. One of the reasons is that there is no way for LabVIEW (and any C compiler actually) to know if this is just a double referenced pointer to a single variable or if it is an array of pointers. int *a[] would be a bit clearer in that sense but traditionally C compilers make no difference between int *a[] and int **a.

So if you have an int *a[] or int **a parameter anywhere in your DLL functions, you are going to have to create a C wrapper function in this or a saparate DLL to translate between LabVIEW and your DLL.

Rolf Kalbermatter

QUOTE(Sarfaraz @ Aug 10 2007, 05:52 AM)

Hi,

I have a similar situation as mentioned above. In my case i am using a DLL made in VC++ 2005 and call it from an application made in Labview. I have tried the above method for debugging the DLL but i get the following message

"Debugging information for "LabVIEW.exe" cannot be found or does not match. Binary was not built with debug information. Do you want to continue debugging?"

Is there any other way to debug the DLL? Can someone help me out? Thanks in Advance.

This message is normal. LabVIEW has been compiled without debugging information for several reasons. One of them is the size it would take, another one the fact that debugging information can expose sensitive information in the executable that makes dissasembling it very easy.

You should be able to ignore that message and just continue. I have no experience with Visual C 2005 but in Visual C 6 it is just like that. As long as your DLL was compiled with debug information the Visual C debugger should show you source code debugging for your DLL. It could be that you get prompted for the project file at first launch so Visual C can locate the source files. Of course if you start to single step from your code into LabVIEW code you will only see assembly there.

Rolf Kalbermatter

QUOTE(Aristos Queue @ Jul 23 2007, 05:29 PM)

True. Which is why licensing got applied to scripting. You probably don't want to promote the publicity of this lest similar protections come to the callback.

This sentiment! Is that official NI policy now? Maybe it has come the time to consider for me if LabVIEW is still the tool I love to work with.

Rolf Kalbermatter

QUOTE(Yuri33 @ Jul 22 2007, 10:36 PM)

Is there a list of undocumented calls like this to the LV library?

It's not undocumented. It is all (except the Library:LabVIEW trick in the Call Library Node) there in the External Code Reference Manual.

Rolf Kalbermatter

QUOTE(Aristos Queue @ Jul 22 2007, 11:38 PM)

Yea, I figured some of the password protected VIs might use this and similar tricks ;-)

But someone at NI must have forgotten that. There is or maybe used to be a code example on the Developer Exchange Site exactly with the MoveBlock function. So you hardly can call the Library:LabVIEW trick in the Call Library Node to be a well kept secret anymore.

Rolf Kalbermatter

QUOTE(eaolson @ Jul 19 2007, 09:31 AM)

After posting http://forums.openg.org/index.php?showtopic=619&hl=' target="_blank">this question on the OpenG forums, I was doing a little poking around and now seem to be stuck. Is there any way to open a VI programmatically (as with Open VI Reference) in the context of a particular application instance? I don't mean an application reference (from Open Application Reference), because that actually opens a TCP connection to a VI Server instance running on some other machine.

When I've got a LabVIEW project with an RT target defined, I can open one of the VIs designated for that target in an RT application instance. It pulls some target-specific subVIs from a different vi.lib than the standard. It doesn't actually form a connection to the target.

I can get refnums for the project itself, and the targets, but can't seem to do much with those refnums.

I haven't thinkered with projects and such in VI server yet but this is just some of the basic understanding I have about LabVIEW VI server.

The targets in a project should be more or less just like application references. And the way to open a VI in the context of an application reference is to pass that application reference to the Open VI Reference function. Have you tried to connect one of those target references to the Open VI Reference or maybe search for a property in the target reference that might return a real application reference?

Rolf Kalbermatter

QUOTE(Aristos Queue @ Jul 20 2007, 02:42 PM)

Does anyone have a standalone DLL that has a function which, given a memory address, returns the byte, word or int at that memory address? It would be useful for a hack I'm contemplating, and I don't feel like coding a DLL for a one-off project.

The way I do this is by calling the LabVIEW internal memory manager function MoveBlock through a Call Library Node.

If you set the source parameter to be an uInt32 by value and the target parameter to be an uInt(x) by reference, and then also adjust the size parameter accordingly you get what is required.

To call MoveBlock in LabVIEW you have to configure the Call Library Node as follows:

Library Name: LabVIEW

Calling Convention: Standard C

Function Name: MoveBlock

return value: void

1. param: source, uInt32 as Value

2. param: target, uIntxx as Pointer

3. param: size, int32 (number of bytes to copy)

Advantage is that you do not need any Toolkits or plattform specific external libraries.

Rolf Kalbermatter

QUOTE(Dirk J. @ Jul 20 2007, 09:03 AM)

If you allow for using a lot of Call Library Function Nodes, then this one is.

User inputs: owning VI, title of the dialog, root item of the dialog, browse options

Outputs: selected directory and it's display name.

PS: I didn't solve the 'image' issue, but on the other hand, that will only return an index for the system image list - which should be accessable in some mysterious way)

I think this has a memory leak. The IDList returned by SHBrowseForFolder is a memory buffer that should be freed with the (originally undocumented) ILFree function in shell32.dll. And for OSes before XP or 2000 this function was not exported by name, but only as ordinal number 155.

A little known feature of the Call Library Node is that you can also reference functions that are exported by ordinal by entering the ordinal number as function name. LabVIEW seems to attempt to convert function names that only consist of numbers into an ordinal and try to load the function as such.

Rolf Kalbermatter

QUOTE(Gary Rubin @ Jul 18 2007, 04:11 PM)

I assume that Ben was correct, as nobody has disagreed with him yet...

Yes, the rules if LabVIEW does a data copy are mostly tied to the functions the wire runs to and especially if a wire has branching built in. And here multithreading might get in the place sometimes. When a wire branches, LabVIEW tries to execute functions that only read the data but don't reuse them further or create a complete copy anyhow before functions that could reuse the buffer. In that context subVIs are always considered as a potential consumer of a buffer. And now if you have multithreading in place LabVIEW might get in a difficult sitution:

Serialize the code to execute non consuming nodes first or allow simultanous execution that requires a data copy in any case. I would opt myself for the first case as it should probably in most but the simplest cases where only skalars are involved be the more efficient solution.

Rolf Kalbermatter

QUOTE(tcplomp @ Jul 18 2007, 04:34 AM)

Does anyone have a GUID creator in LabVIEW?

I know this is a bit lazy, but hey?

Ton

The http://www.vartortech.com/visecurity/cryptg.html' target="_blank">CryptoG Toolkit contains amongst many encryption and hash algorithmes a Random Number Generator and based on that a VI to create GUIDs.

All these functions are fully native G code and tehrefore completely plattform independant. It's cost is nothing that should prevent you using it and I can really recommend it.

Rolf Kalbermatter

QUOTE(Neville D @ Jul 13 2007, 10:55 AM)

TCP communication should work regardless of platform. Have you tried running the code on the desktop? The TCP primitives themselves should handle any platform specific details invisible to you.

Like others mentioned there are a few functions (usually from the RT pallet) that won't work on the desktop platform (and vice versa for any ActiveX calls etc. for RT platform), but the large majority, I would say 99% of the code should work fine on the desktop.

The TCP functions will return errors if no network card or at least a TCP/IP adapter (modem, broadband or whatever) is present in the system to which the TCP/IP socket layer can bind to or if those adapters are all disabled. Though I wonder if there still exist PCs without a network interface.

Rolf Kalbermatter

QUOTE(Karissap @ Jul 12 2007, 11:39 PM)

That propery is private and can only be accessed by enabling VI scripting in LabVIEW 7.1 using the ini file (a lot harder to enable scripting in newer versions). See the http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">VI Scripting Readme for how to enable it.

And it is likely to not work as desired in an executable.

Rolf Kalbermatter

QUOTE(Tomi Maila @ Jul 11 2007, 02:11 PM)

What an excellent suggestion. I guess the following sequence needs to be executed for this particular task

1. Reserve a block of memory referenced by a pointer p
   
2. Copy content of a LabVIEW array excluding the size specifying bytes to the newly created block
   
3. Call first proprietary C function and pass the pointer to this function
   
4. Copy second proprietary C function and pass pointer p to this function as well
   
5. Create a new array handle and copy the content of the memory block referenced by p to the memory block of this handle after the size bytes
   
6. Set the size bytes of the array handle to the proper values
   

However I'm not sure if this task can be safely implemented within LabVIEW only. The set of memory manager functions is limited and pointer referencing and dereferencing is a challenging job within LabVIEW. Multiple calls to LabVIEW executable are not atomic in a sense that LabVIEW guarantees the memory buffers to remain the same for each call. As a result it's hard to properly manipulate LabVIEW array handles from within LabVIEW. Even when current version of LabVIEW doesn't make a buffer allocation in certain place, there is no guarantee that future version of LabvIEW will act the same way. I'm familiar with using LabVIEW memory manager functions in external C code and still this task seems challenging for me to complete using only calls to LabVIEW executable. On the other hand the task is relatively easy if one simply writes a few lines of C code and compiles that into a shared library (DLL).

While in theory your conerns could be right they don't have to be for two reasons.

1) As long as you do nothing with a wire (and data dependency can ensure a variable stays put in memory until after a certain point) LabVIEW does not deallocate or move it. In fact all diagram data (except paths) are stored as DS (Data Storage) memory contrary to AZ (Application Zone) memory. The distinctions (although I believe in practice this makes no difference on most modern platforms anymore as the memory virtualization of modern 32bit CPUs completely hides the physical memory management of the CPU from all applications) is that AZ memory handles can be locked but don't need to be while DS memory handles always are locked. A locked handle means that the memory manager will never move around your memory block while you do other things in LabVIEW, unless you explicitedly use memory manager functions to deallocate or resize such a handle. Pointers are by their nature non relocatable unless explicitedly reallocated.

2) The memory manager has some very powerful functions that can directly move between pointers and handles and that ensure that the operation is properly protected in the context of the LabVIEW execution system. But even without this, as long as you make sure that no other LabVIEW functions can concurrently operate on a handle whose pointer you treat with your direct DLL magic functions, you can be sure to be safe. And by the way this is why LabVIEW has to and does make data copies on branching wires when more than one function can possibly modify that data.

Rolf Kalbermatter

QUOTE(polyplay @ Jul 9 2007, 04:11 AM)

http://forums.lavag.org/index.php?act=attach&type=post&id=6328''>http://forums.lavag.org/index.php?act=attach&type=post&id=6328'>http://forums.lavag.org/index.php?act=attach&type=post&id=6328

Hello,

I am trying to access function "xlLinSetChannelParams" from vxlapi.dll (see the attached archive). For the parameter "statPar" I need to pass a structure and I use a cluster with the format specified in the function prototype. If Adapt to Type is selected as input type, there are to possibilities to pass data: by value and by pointer. No matter what data format I choose, the function prototype shows me that data will be passed by pointer (short int _xlLinSetChannelParams@28(long portHandle, unsigned long long accessMask, void *LinParam).

Any idea how to fix this or use other method to make this function work.

P.S. If you manage to make this work, you will receive an error code with values between 0 and 255. The inputs portHandle and accessMask are correct; the problem comes from the structure.

If your actual C code header file is really as you show in your text file you might have a serious problem here.

typedef struct {

unsigned int LINMode;

int baud rate; < this is definitely not valid C syntax.

unsigned int LINVersion;

unsigned int reserved;

} XLlinStatPar;

XLstatus xlLinSetChannelParams (XLportHandle portHandle, XLaccess accessMask, XLlinStatPar statPar);

What LabVIEW will assume for structure parameters is:

XLstatus xlLinSetChannelParams (XLportHandle portHandle, XLaccess accessMask, XLlinStatPar *statPar);

passing the structure by pointer. I'm not aware that this can be done otherwise so maybe the C compiler will automatically make this parameter passed by pointer but that is beyond my C detail knowledge.

Rolf Kalbermatter

QUOTE(Yuri33 @ Jul 8 2007, 11:46 PM)

I haven't tested if this will work, but there might be a possible (roundabout) way to do this if you have the Vision toolkit installed. There is a hidden subVI called "IMAQ Create&LockSpace.vi" in "Compatibility.llb" in the vi.llb -> Vision directory. From the description, it allows you to allocate an image with a fixed size in memory, ensuring that that memory space is always available. It's only supposed to be used in situations where memory constraints are tight, but I believe it may work for your situation. Just use this vi to create a memory space, typecast your data to a series of "pixels" that can be mapped to this place, and then use "IMAQ GetImagePixelPtr.vi" to obtain a pointer to that memory space for your dll call. As long as you can ensure that your data will never grow beyond the allocated size, I believe the memory location will stay constant.

A less costly and also platform independant way is to use a Call Library Node to allocate memory areas by calling into LabVIEW itself. Setting the library name to LabVIEW you can call all the exported LabVIEW manager functions that are documented in the External Code Reference Manual and that includes the LabVIEW memory manager that can do all this. Make sure to use C calling convention as that is what LabVIEW exports its manager functions as, and obviously configure the rest of the Call Library Node according to the documentation for the function you want to call.

Advantage is you don't need an (expensive) Toolkit installed and if you ever happen to have to move these functions to another LabVIEW platform this part will simply continue to work (the DLL part itself obviously not . Don't forget to deallocate the memory poiunters after use obviously as otherwise you create memory leaks.

Rolf Kalbermatter

QUOTE(Yuri33 @ Jul 5 2007, 10:52 PM)

The IMAQ AVI file reference has a lot of strange properties that make it rather inflexible and hard to use. Chief among these is the fact that the "Not a Reference" primitive in LV always returns false no matter if the AVI file reference is valid or not. Does anyone have a way to reproduce the proper functionality? I've tried a number of things, including typecasting to another reference type (including the a datalog reference, since it seems related to that) and trying to use AVI File Info and trap the error. Nonething works. Is there any test to see if an AVI file reference points to an open file (whether it's a write session or a read session?). I'd settle for a write session only version if that's the only thing possible.

IMAQ AVI file reference is not a proper LabVIEW refnum, but a private implementation to the IMAQ AVI library. So the Not A Refnum prmitive can't work there as it is strictly always not a valid LabVIEW refnum.

What you can do is either try to typecast the refnum into an int32 and if it is not 0 then assume it is valid or probably even more safe use the IMAQ AVI Get Info function. If it returns no error then it is definitely a valid refnum. Of course the issue about why you would need to find out after the fact if it is a valid refnum does hint that you probably do not do proper error handling of the Create or Open function.

Rolf Kalbermatter