Rolf Kalbermatter

QUOTE(RONIN10 @ Dec 12 2007, 11:03 AM) Hmm if it is still crashing then something is not right. What, I really can't tell you from what you show so far. Without more details about the last parameter or some short C code excerpt showing how it is normally called my possibilities to help are completely exhausted. Rolf Kalbermatter

QUOTE(frentzen @ Dec 12 2007, 08:24 AM) Are you sure this is not just your actual homework or assignment that you want us to do for you? Figuring out what this all does, shouldn't be to difficult if you know a little bit about LabVIEW, Java and XML. If you don't, I'm afraid you will fall through anyhow during your presentation, trying to explain some precooked explanations you don't understand yourself. Rolf Kalbermatter

QUOTE(george seifert @ Dec 12 2007, 08:36 AM) Sorry, I've never seen these errors and if a LabVIEW repair didn't help, hmmm! Maybe try to do a device driver repair too?The timed loop goes deep into the system and and could depend on some low level NI device drivers that might have gotten belly up. Rolf Kalbermatter

QUOTE(Karthick.v @ Dec 12 2007, 03:00 AM) It says you must have the IMAQ Vision library 7.1 or higher not LabVIEW! You have an IMAQ Vision Library and valid license? Rolf Kalbermatter

QUOTE(Val Brown @ Dec 11 2007, 10:23 PM) Specifically some of the components on the Driver CDs/DVD was updated and Upgrading them can mess up your MAX configuration and cause "bodily harm and death". I found this last one quite entertaining but I guess that is American cautioness. Otherwise someone installing this in a life support system (which you are strongly adviced to not do with any NI material in all NI manuals) could cause some serious casualties. Rolf Kalbermatter

QUOTE(Cool-LV @ Dec 11 2007, 10:57 PM) NI didn't do it. They just bought the Macrovision FlexLM source code license and use that one. I've had a look at that code at some time. It is not a piece of C code anyone would want to dig into and make modifications to. Very convoluted, complicated and all in all unmaintainable IMHO. Means you try to compile it and hope it works and once it does leave your fingers from it. It's also sad that around 1MB of the LabVIEW executable concists of this FlexLM code. LabVIEW itself does in 1MB assembly code a lot more and a lot more useful stuff. FlexLM supposedly takes some specific machine parameters such as the HD serial, CPU ID, MAC adress etc. etc. and using some hash algoritmes calculates such IDs. Rolf Kalbermatter

QUOTE(crelf @ Dec 11 2007, 04:06 PM) Could that be because of intervention by some other significant person? Rolf Kalbermatter

QUOTE(RONIN10 @ Dec 11 2007, 04:03 PM) If it is really just an integer that is returned it's very trivial. Configure the parameter to be an int32 or whatever integer you expect and also tell it to pass that parameter as Pointer to Value (contrary to as Value). That should take care of your problem. Rolf Kalbermatter

QUOTE(george seifert @ Dec 10 2007, 03:33 PM) When you have to calculate the weighted average of several pixels, the result will be much more smoothly when you have 8 bits per color to distribute your values in, than in 8 bits altogether. Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 10 2007, 05:32 PM) That is our resident http://forums.lavag.org/crelf-m181.html' target="_blank">LAVA champion in number of posts. He has for anything and everything here on LAVA an answer, but sometimes it is tongue in cheek. But he seems to slow down recently. Probably due to his preparations for a travel back home to down under. And his book on LabVIEW imaging is quite good. Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 10 2007, 01:31 PM) I've made quite a lot of responses to posts about external code in LabVIEW on LAVA, the NI Developer Exchange, Info-LabVIEW mailing list and the German cousin of LAVA, and also published some short articles about this topic on http://expressionflow.com/author/rolfk/' target="_blank">Expression Flow but I haven't written a book so far Rolf Kalbermatter

QUOTE(Norm Kirchner @ Dec 7 2007, 11:36 AM) The modern version of our childhood telephones But it's not clear if that is a network outlet or a power outlet. I sure hope for the first. Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 9 2007, 09:26 PM) Yes, http://msdn.microsoft.com/' target="_blank">MSDN (Microsoft Developer Networks) is your friend for any Windows API question. If it's not there it is undocumented and that means any other information you can find on the net might be right or completely off the tracks. As far as to your function prototype, where the heck did you get that from? It uses datatypes Microsoft never used so far and is also inherently wrong. The W suffix to the function indicates that it is a Widechar (16bit Unicode) function, but the third parameter is CStr, which is basically an 8 bit ANSI string. That simply can't be right. TIP: When searching for a WinAPI function on MSDN, never use the function name with the A or W suffix. While those functions are exported with the W or A suffix, Microsoft considers them equal as far as documentation is concerned. Which one is used and pulled in gets decided during compilation, based on preprocessor settings. For LabVIEW you always want to use the A version since LabVIEW strings are 8 bit MBC strings. For the general understanding of these things: Knowing a good bit of C will help very much. The DLL calling interface is inherently C based and so are all its terms and conventions. That means that the Call Library Node can't really make it in any other way either, as unfriendly that interface can look to a LabVIEW only programmer. And that means as tempting those API calls could seem to you, without learning some basic C knowledge first you are really in for a hard ride with lots of crashes when you go down that road. Rolf Kalbermatter

QUOTE(Norm Kirchner @ Dec 10 2007, 01:22 AM) Cool down! IMHO, MDI (Multiple Document Interface) is overrated and simply a pain in the ###### to work with. Saying that since you can't easily do it in LabVIEW, LabVIEW can not be seen as a general programming language is definitely more than stretching it. I do believe there is a reason why the Mac did not support SDI either and at least for me it is also because it is simply a useless UI concept. The reason that they do not want to have LabVIEW as a general programming language is because it would take the control out of their hands. It would need to be submittet to a standardization gremium and from that point on onwards NI would have much less to say of what the next direction in development would be. Also submitting it to a standardization gremium would mean lessening or even giving up the exclusive patent protection over some of the features as otherwise there wouldn't be any standardization gremium taking the submission serious at all. All in all lots of work, even more lobbying, as getting something accepted as standard requires lots and lots of lobbying, and all that for the doubtful benefit of loosing control over a very nice and interesting programming environment. I don't see TI doing anything like that very much either and from a business point of view it wouldn't make sense anyhow. Rolf Kalbermatter

QUOTE(Justin Goeres @ Dec 8 2007, 01:49 AM) Doesn't surprise me! They are two different processes that suddenly are tight together through Windows message queues. That's bound to create problems in newer Windows versions and most likely things will get even worse on Vista. I did that in the past with IMAQ Windows being embedded in a LabVIEW front panel. Works flawlessly at least up to Windows XP but here the IMAQ Windows are really LabVIEW Windows too, so no external process being suddenly forced into embedding in LabVIEW. Rolf Kalbermatter

QUOTE(RONIN10 @ Dec 7 2007, 04:34 PM) I had my local NI rep and another NI guy visiting from TX sit down with me and take a look at this together. It was beyond their certainty as to what was wrong, but they seemed to key in on the void pointer as being the likely culprit and (unfortunately) didn't have a solution in mind. So when I go to run this, the node execute succesfully in that I get a zero return value (specified in the source code as successful completion of the function), but the I32 I'm wiring to the void pointer doesn't get populated with information I'm requesting (number of parameters in teh data stream, in this case). It also causes an Error 15 code in LabVIEW and crashes the whole application after hanging for a few seconds. Any suggestions of ways to correct this and why it is behaving as it is? Thanks in advance! There are two things that could be wrong: datastream_t is not a standard C type so I'm not sure if treating it as an int32 is ok. If it is just a handle you get from some open function then it should be ok. The void pointer quite likely is the culprit here. Unfortunately C is not a language that describes parameters in itself sufficiently in terms of the exact meaning and context of their use. void pointers are especially bad in that respect as they can be really anything you can think of. What it is can only be decided by knowing the exact context of that function, which you didn't give in any way. It could be a byte buffer in which the function is supposed to write the data from the stream. In that case the caller (your LabVIEW diagram) needs to allocate that buffer. As the function has no parameter to tell the size of that buffer and therefore you would need to know that size before calling that function I can only think of a few possibilities: - The function works with a fixed size buffer always. - You can pass in a NULL pointer and get the needed size as return value of the func'tion to allocate that buffer and call the same function again. - There is another function that can tell you what size is required. These things can not be deducted from the function prototype you show but only from the source code, a possible code example or the function description in some programmer manual to the library. Another possibility is that the function allocates the buffer itself and returns a pointer to it in the void parameter. In that case you would need the exact structure of that buffer and hope it is a flat buffer. Retrieving non flat data (pointers inside that buffer) in such a way is a mature pain and for me ALWAYS a reason to write a wrapper DLL or in your case since you have the DLL source code an additional more LabVIEW friendly exported function. Also since the DLL allocated the buffer it should provide you with a function to deallocate it later on after you don't need it anymore as otherwise you are creating memory leaks. All in all there is way to little information available to tell you what exactly goes wrong and even less to give you detailed ideas about how to do it correctly. And that is not LabVIEWs fault but the nature of C which does not fully document the parameter datatypes of functions in general und the exact usage context in special. Rolf Kalbermatter

QUOTE(gammalight @ Dec 6 2007, 10:14 PM) Probably recompiling the low level support library of the Report Generation Toolkit for Office 2007 and installing that with your application instead of the default 2003 version would solve that issue. So MS most probably did it again and changed the ActiveX interface between Office versions enough, that LabVIEW gets trouble running it withoug recomiling its VIs. Rolf Kalbermatter

QUOTE(Vladimir Drzik @ Dec 6 2007, 06:33 AM) I was attending a presentation during the LV days all over the world that followed the NI week. The presenter, an active LabVIEW developer much into especially these areas of LabVIEW, only said that the number of executions systems was now more dynamical depending on the actual number of cores LabVIEW could find. He didn't say specific numbers because I think that is hard to do anyhow. There is most probably some heuristics involved that use to some point somewhat arbitrarily chosen values, with lots of tweaking, testing and such during the devlopment. And those heuristics will likely change again as different multi-core designs get available, different CPU architectures are introduced and different OS support is introduced. One possible starting point is above mentioned VI. It should give you an idea about what the currently used setup is for any particular machine. Interestingly on my system, an Intel Dual core machine it reports 4 CPUs Rolf Kalbermatter

QUOTE(gustav @ Dec 5 2007, 12:43 PM) The timed loop apparently calls into external DLLs. Somehow and somewhere that external code does not properly get informed about the shutdown so the process hangs on the exit callback of that external DLL, most probably. I haven't used the timed loop very much but I think this is one thing that has happened to me too in the past, including in the development environment. Asynchronous external code is tricky in LabVIEW, even for the creators of LabVIEW :-) Rolf Kalbermatter

QUOTE(Vladimir Drzik @ Dec 4 2007, 03:25 AM) Well the number of threads per execution system is a not so interesting detail, IMHO. LabVIEW initialy used as default 1 I think then increased to 2 and then 4 but in 8.5 this is actually more dynamic based on the number of CPU cores LabVIEW can find in the system. Even before that this number was not set in stone but could be user configured with a somewhat hidden VI in vi.lib/Utility/sysinfo.llb/threadConfig.vi. That configuration is written into the LabVIEW ini file and in such a way can be transfered to a built application too. Rolf Kalbermatter

QUOTE(prayami @ Dec 3 2007, 07:32 PM) Then you would have to look at the http://www.ni.com/embedded/' target="_blank">LabVIEW for Embedded Edition version, but that is not cheap. And you will have to have to add support for your hardware target to this LabVIEW version to integrate the GNU toolchain or whatever other C toolchain you will use to write software for your controller board. This integration work should not be underestimated. Provided you have someone with a good familiarity with both your toolchain and LabVIEW its still several weeks of work before it will work just right. QUOTE Can we have Real Time Operating System on our microcontroller and can we run LabVIEW web server inside that( i.e. I mean Embedded Web Server )? Yes but not through LabVIEW. You will have to provide your own realtime OS solution such as VxWorks, Pharlap or whatever you can find for your CPU target and then integrate its toolchain into LabVIEW Embedded by writing some support VIs and such. The LabVIEW embedded Web Server is part of the LabVIEW kernel in the Development Module/runtime system and will not be transfered to an external embedded target at all. QUOTE On this server root there will be VIs & html files which will call those VIs. Is this possible? As per your answer it is not possible to have LabVIEW web server without the PC? An embedded application is really LabVIEW code translated into C and then compiled through the target specific toolchain including its C compiler. As such it comes from LabVIEW code but does not know how to load and execute native LabVIEW VIs at all. There will be no way to make your embedded target to load and run LabVIEW VIs. The only way to do that is by creating a target platform that is able to run one of the standard supported LabVIEW platforms such as Win32/x86 or Linux/x86. On such a platform you can simply install a full LabVIEW runtime system that is able to load and execute LabVIEW VIs natively. Or you buy a NI hardware platform with integrated OS such as Compact Fieldpoint or such. NI ported their LabVIEW kernel to run on those systems so they can load an run VIs directly. You can't do that yourself since you would need the LabVIEW source code for that (and LabVIEW itself does as far as I know not directly support ARM at least officially, so that would be out of question). And no, the PDA versions of LabVIEW really do more something like what LabVIEW Embedded is doing by invoking the Visual C compiler for creating executables for the ARM based PDA devices. I'm not aware of any ARM based LabVIEW version sold, that could execute LabVIEW VIs directly, eventhough there probably is rudimentary support in the LabVIEW source code for ARM as indicated in the cintools headers, but I would guess that it is not really substantial and even if it would, it is most likely not very well tested (since only features that get actively used get enough test exposure to make sure they work at least halfway decently). Rolf Kalbermatter

QUOTE(ned @ Nov 20 2007, 03:17 PM) Another reason (except the N=0 issue which I think was changed at some point around 7.x) is that wiring the refnum out of the loop defaults to autoindexing for the for loop which is almost never what it should do. Using shift registers solves that too. Rolf Kalbermatter

QUOTE(0815Jack @ Nov 29 2007, 05:41 AM) Do you know anything about C programming? If so you should be set fairly well and reading a bit in the External Code Reference Manual in the LabVIEW online help should get you enough to get started. Without at least some basic C programming knowledge you will be in for a good and most possibly steep learning experience before it does not crash anymore. And I just see that they export a C++ API. The Call Library Node can not call that directly. It can only access standard C exported functions, no C++ object interfaces. So you will have to create a wrapper DLL, wrapping the C++ method calls into standard C exported functions. All in all it does not seem to me to be a good project to start into the depths of the Call Library Node and C programming. Possibly the ActiveX wrapper or maybe the Visual Basic 5 and 6 example could help a bit. The ActiveX wrapper would allow you to access the Media Library through LabVIEWs ActiveX interface which would mean you do not have to directly deal with C datatypes, memory allocation issues and all such difficulties. Rolf Kalbermatter

QUOTE(hviewlabs @ Nov 28 2007, 03:27 PM) You can try to get NI to give you this for certain functionality under an NDA. Changes that you will get it are however very close to 0%. Reasons you could get that information basically boil down to this: 1) Show NI that they can sell several hundred extra LabVIEW licenses if they give you that information or that they will get a multi million hardware sale. Reasons why they don't want to do this: 1) Many of those APIs do nothing useful for any possible client other than LabVIEW itself. 2) Many depend on other functionality not exported directly at all. 3) Every documented API needs to remain fixed for the rest of LabVIEW's lifetime to avoid breaking existing apps outside of NI's control. 4) Some of the APIs could reveal sensitive information if fully documented. So go and figure your chances. QUOTE(Tomi Maila @ Nov 28 2007, 04:26 PM) Oh. I thought it will only work in all supported platforms but not in a build app unless you used labview runtime instead of the executable. Well I guess Rolf is right here. He's such a guru in these things There is no difference between using the runtime and a LabVIEW executable since about LabVIEW 4.0 or so. Before that a LabVIEW executable was self contained, with the entire LabVIEW runtime embedded in the executable itself. Since then every LabVIEW executable will always refer to lvrt.dll whenever wanting to do any LabVIEW specific operation. And yes using LabVIEW (case very important) instead of LaBvIeW.exe should since about LabVIEW 6.0 also work in an excutable/runtime environment. The Call Library Node contains specific code detecting that keyword and directly rediricting to whatever kernel is doing the LabVIEW nitty gritty work at that moment. (lvrt.dll or labview.exe) QUOTE(Tomi Maila @ Nov 23 2007, 12:08 PM) Hi,Have you ever wanted to know what's the pointer to a LabVIEW buffer? Well in LabVIEW 8.5 you can actually find it out. LabVIEW 8.5 supports calling a shared library with constant arguments. As the arguments passed to the shared library are considered constant, LabVIEW reuses an existing data buffer for the shared library call. It doesn't make a copy of the data to pass the copy to the shared library instead of the original data. This allows reading and modifying wires parallel to the shared library. If these wires share buffer with a constant, then the value of the constant can be read modified as well.So what's the trick? Well, to understand the trick we first need to understand how LabVIEW data is stored into memory. LabVIEW uses two kind of memory models for data. For fixed sized data such as numeric types, booleans, clusters and references LabVIEW users pointers to the data to pass the data around. Each buffer is therefore referenced with a pointer to the data. For variable sized data such as strings and arrays and apparently also LabVIEW classes, LabVIEW uses handles (pointers to pointers) to the data. I think this is enough of introduction. I don't want to spoil all the fun. Take a look by yourself how to find out the pointer to fixed sized buffers and the handle to variable sized buffers. http://lavag.org/old_files/monthly_11_2007/post-4014-1195837700.png' target="_blank"> A correctly configured MoveBlock call can do the same as your GetValueByPointer since LabVIEW 5.x already. Rolf Kalbermatter

QUOTE(TobyD @ Nov 28 2007, 02:59 PM) Could it be that your DLL calls indirectly other DLLs that are in the same directory? When LabVIEW asks Windows to load a library at a specific path Windows does attempt to load it, and when that library references other libraries it tries to load them too. If one of those referenced library loads fails the entire load fails and Windows tells LabVIEW: sorry! Now Windows will search for libraries in following order: 1) a library with the same name is already mapped in the process space 2) inside the directory where the executable for the current process is located (here the directory where LabVIEW.exe is) 3) in the System directory 4) in the Windows directory 5) in any directory mentioned in the current PATH environment variable and most possibly also in the "current directory". The current directory is a process specific global variable that gets manipulated by various Windows APIs. One of them is also the API that LabVIEW uses to display the System File Dialog. So if you browse to your DLL directory to tell LabVIEW which DLL to load and that DLL references other DLLs implicitedly that are in the same directory, Windows suddenly will find them, but not before. Solution would be either to move those DLLs all into a location that is properly searched by Windows, or add the location of that directory to the PATH environment variable. Rolf Kalbermatter