Rolf Kalbermatter

QUOTE (Neville D @ Dec 8 2008, 03:51 PM) Nothing against that. I just say betting in an application on CUDA limits the possible platforms you can deploy this application to. QUOTE BTW MACs use NVIDIA graphics (in addition to INTEL integrated graphics) so potentially this could increase performance on MAC machines in the near future as well. Anyway, I think its a good direction for processor hungry applications like Vision or control. Software still would need seemless support for processing everything on the host CPU to make this useful in most applications. This makes such a solution a bit hard to do through the call Library interface and IMO it is much better to integrate that on a much lower level such as on the graphics routine kernel in a Vision library. Or in the analysis library. However latter may be a little hard for the LabVIEW Advanced Analysis Library since it makes mostly use of the Intel Math Kernel library and I'm not sure Intel is going to integrate CUDA into it nor even facilitate it for others to do so. Rolf Kalbermatter

QUOTE (Michael_Aivaliotis @ Dec 8 2008, 01:05 AM) And that caused a lot of bitching in the past since it didn't always work optimal. For many versions Bundel/Unbundle by Name could get really badly confused and just randomly switch terminals (and not always was that causing broken wires). The situation was so bad that I had wished it would not rename at all but just leave invalid names in the Bundle/Unbundle instead and let me search it out manually. Rolf Kalbermatter

QUOTE (tushar @ Dec 5 2008, 04:00 AM) You should really read the release notes to the ZLIB library. There is a section in it that reads: 2) Adding of files into existing ZIP archive supportedZLIB Compress Directory.viZLIB Compress Files.viZLIB Open ZIP Archive.viThe boolean parameter to append or truncate has been replaced by anenumeration to support addition of files into an existing archive.The old append value meant that the ZIP file was tacked to the endof the existing file which might have been useful for a selfextractingexecutable only.Following table shows the old and new settingsold value new value remarksFalse create new truncates existing file to 0True append to end appends to end of existing fileNA append to archive appends new files into the archive Obviously you do not want to use "append to end" but "append to archive" instead. Rolf Kalbermatter

QUOTE (Luis Fernando @ Nov 27 2008, 10:45 AM) Unless you get them from the manufacturer of the device they probably don't exist. NI does write instrument drivers but most times includes only the functionality they: - can test - can understand - and believe is useful Even many instrument manufacturers do write instrument drivers for LabVIEW and do apply exactly the same rules in deciding what to support in such a driver! Many of the instrument drivers on NI's instrument driver download are actually from the instrument manufacturers and that are often not the most complete or well written drivers of them all. Rolf Kalbermatter

QUOTE (MJE @ Nov 23 2008, 08:18 AM) When you call DLL functions and configure the parameters right LabVIEW WILL pass the data pointer to the DLL and NOT copy all the memory before calling the function or returning from it. I haven't looked at CUDA and am not sure how it works but if what you mean by paralellisme is that you can call several fucntions in parallel to work on the same data then yes you would get a problem when calling that in LabVIEW. LabVIEW manages it's memory in its own and very dynamic way. It will make sure that a memory pointer passed to a DLL function will remain locked in place and valid for the duration of the function call but once the function returns that memory can be reallocated, moved, copied, overwritten, deallocated and whatever else you can think of at LabVIEW's will and at any time. So if you would need to call functions that will hold on to memory buffers beyond the function call itself you can't use LabVIEW's Call Library Node without some good LabVIEW-C voodoo power. All in all the perfect case to create a wrapper DLL to interface between LabVIEW and such libraries. However the biggest draw back I do see is the fact that I haven't owned an NVIDIA powered computer in all the time so far. Sort of makes such a solution very narrow scoped in terms of possible deployments as I'm sure I'm not the only person that does own a computer with a different graphics processor than from NVIDIA. Rolf Kalbermatter

QUOTE (crelf @ Oct 24 2008, 08:08 PM) It's what you get when using the newest MS compiler tools. They create DLLs and executable's that explicitly link to the newest and greatest MS C runtime libraries. Using older MS compiler versions has the benefit that all current MS OSes come with those runtime libraries already installed but I guess Vista wasn't compiled with MS VC 2008 and therefore does not come with its runtime libraries. Ok I admit, the LabVIEW RTE installer should have installed the redistributables of whatever runtime libraries for the compiler that was used for the delivered LabVIEW components . I prefer to compile my tools with Visual C 6.0 and so am sure they will work even on a Windows 98 or NT 4 out of box installation . It's really great to just have a VI library and a DLL and not have to worry about the correct runtime libraries being installed. Also makes life a lot easier if you don't have to tell someone to first install .Net 2.1.2.3.5 or higher before attempting to run your software. Rolf Kalbermatter

QUOTE (TobyD @ Oct 23 2008, 10:37 AM) This is OS independant. Works on all systems. If a valid DNS setup is configured you get the machine name otherwise the IP number. Rolf Kalbermatter

QUOTE (labviewRTS @ Nov 14 2008, 05:22 PM) Actually the most challenging and time consuming part is to create the requirements specifications together with the functional specifications. Certainly with a system like what you have in mind! Once these have been created and verified the actual implementation is still a lot of work but in fact simple in comparison. So you probably shouldn't hold your breath for someone to create for you the grunt work of your system. Those that know what would be involved and know how to write such specifications, likely would write such a software themselves if they haven't already done so. Rolf Kalbermatter

QUOTE (Justin Goeres @ Dec 1 2008, 02:55 PM) The reason is obvious. Transparent means whatever is behind has to show through. The only way to do that is by letting the parent redraw itself and then redraw its own contents on top of it. This by definition is redraw first at all times. There is no other way to achieve real transparency. You can see that issue also with other controls that are overlapping and set to have parts transparent. Transparency in any UI object is a very difficult thing to handle correctly AND with good performance. There is sort of a bug in here in the property node that COULD return an error when you try to change it but not in any other way. I guess the property node just ignores the change of the property though, since there wasn't a readily available error code to return. Rolf Kalbermatter

QUOTE (Shazlan @ Dec 4 2008, 04:12 AM) And how would you suppose would the data go from the PCI expansion box into your computer? Not that I would trust this to work even if the ExpressCard to connect it to your computer would not be damaged. PCI expansion slots have many troubles and if they have to go through ExpressCard slots even more. Many drivers are not written to allow transparent access through PCI hubs and even if they are, many PCI hubs (your ExpressCard is one too) are not implementing the PCI specs correct enough to allow particular bus transfers such as DMA or certain Interrupt operations to occur transparently. Rolf Kalbermatter

QUOTE (Neville D @ Nov 19 2008, 12:40 PM) Either that or Pharlap ETS (from Ardence, ähem I mean IntervalZero). My guess would be VxWorks though since it is usually a bit more compact and their support is supposedly good (as is their price , in this market you certainly get what you pay for). Yet another LabVIEW targettable embedded OS would really not make much sense at all. I don't think the Matrox cameras will have a big effect on the NI pricing. The strength of the NI cameras is that they can be easily targeted directly from within a LabVIEW project and their algorithme is simply programmed in LabVIEW too. It might be an issue for high volume projects though where the nice integration in LabVIEW is not as important as the total cost of the entire solution but I'm sure NI will certainly be open about volume discounts if you tell them you need 10000 of these nice gadgets :laugh: . Rolf Kalbermatter

QUOTE (Darren @ Dec 6 2008, 01:00 AM) Autorelinking is tricky. It is usually required when you change the connector pane and that can be not always unambiguously resolved. I wouldn't mind if there was a dialog that tells me something like: "There are currently XX instances of this VI in memory and they can all be relinked safely/not safely! Do you want this to be done automatically?" though. Rolf Kalbermatter

QUOTE (Lorenzo @ Dec 4 2008, 05:24 AM) ActiveX might work provided you find the right application but it is really overkill for that. Try to find a tool that provides a command line program and just call that using System Exec. Don't expect LabVIEW to do it for you. PDF is not a format LabVIEW is ever going to support natively. To complicated, in fact proprietary, and an ever moving target with every new release of Acrobat adding yet another 20 nifty feaatures to it. Rolf Kalbermatter

QUOTE (Rajeswari @ Nov 30 2008, 06:31 AM) First a DLL alone does not help much really! It seems to be a combined COM/standard DLL, meaning it exports both a COM/ActiveX interface and a standard C function interface. It even seems to contain the selfregistration for the ActiveX interface so that you can register the DLL using regsvr32 "<path to your DLL". It might possibly even include the necessary typelib, that allows you after registration of the DLL to use that ActiveX interface from LabVIEW using LabVIEW's ActiveX interface. The C interface however, that you are trying to access through Call Library Node does usually not have any information about the actual interface. It just exports the function name and leaves the rest up to the caller. You can use the External Library import wizard in LabVIEW 8.2 and higher if you have the header file for the DLL and in 8.5 this wizard is even able to import more complex function prototypes but all automatic translation has to end somewhere and the import wizard usually chokes on very involved function parameters. This means not necessarily that the function can't be imported in LabVIEW using the Call Library Node, but it usually means that it can't be done without some complicated vodoo techniques that are out of question for anyone without very good C understanding. And someone knowing C good enough to be able to apply those voddo tricks will almost always chose to write an intermediate DLL that translates between the complicated C function parameters and somewhat more LabVIEW friendly parameters. So a DLL alone is of absolutely no help without the according header file if you want to import the standard C functions from a DLL using Call Library Node. And often the header alone is not enough either since the C syntax is ambigious enough that the meaning of some parameters can be only determined by studying C example code or reading a thorough documentation about the function (with the latest being seldom available). My advice if you are not a seasoned C programmer: register the ActiveX interface of the DLL and try to use that instead, using the ActiveX interface in LabVIEW. Rolf Kalbermatter

QUOTE (Gary Rubin @ Nov 21 2008, 10:45 AM) Not sure why it shouldn't and I think some collegues did that in the past. LabVIEW 7 for sure does run on XP and so should run on XPE too, provided you install a little more than the most basic XPE modules. Rolf Kalbermatter

QUOTE (skof @ Nov 27 2008, 05:29 PM) Another possibility is that you target the wrong application instance. Since LabVIEW 8.0 a LabVIEW process can have many application instances with one main instance and then one additional instance for each possible target in every single project. Of course they don't always remain on the same host (RT target in a project) and consequently have different IP nummers to open first. But when I was deploying a project to a cFP controller recently and tried to access a VI through VI server that existed in this project I got this error too. Solution was to explicitedly configure VI server in the target of my project to use a different IP port and connect to that. This did kill my performance though so badly that I had to abandone this approach. I guess there is a default VI server on a RT target (as I could connect to it) but a directly deployed application from a project gets instantiated in its own application instance that has to be enabled first. Rolf Kalbermatter

QUOTE (Blackbyte @ Oct 25 2008, 09:12 AM) Most probably you need to set the "prepend array or string size?" on the Write To Binary File to false as it is by default true. What this does is prepending a 32bit integer indicating the number of array elements (bytes in the case of a string) that follows and that is very useful if you stream multiple blocks to a file but not necessary for a single block and in the case of fixed file formats even catastrophic to do. Rolf Kalbermatter

QUOTE (Pollux @ Nov 20 2008, 04:55 PM) You don't usually change the cell when the user hovers over the cell but only when he clicks in a cell. That is fairly easy to do with the event structure and a mouse click event. Calculate the cell number from the mouse click position, make a numeric control visible and place it there in the right size and then you are more or less set. Personally I have used the array of clusters in the past too for such cases though Rolf Kalbermatter

QUOTE (Thang Nguyen @ Oct 28 2008, 09:23 AM) It's simply a byte stream like a LabVIEW string with the only difference that there is a different color on the diagram for it. It's contents are bytes, numbers and arrays packed together and the according format (for at least the published operations) can be reverse egineered frorm the diagram of the variaous Picture Control VIs. This is what Norm talks about in the begin of this thread and what he has done (just as I had about 15 years ago at some point). There is no secret about that, it's just a tedious work to do and in my case I do not have real documentation about that format anymore. Rolf Kalbermatter

QUOTE (Pollux @ Nov 25 2008, 09:25 AM) How would that work? An application can only close itself without some explicit and dirty Windows kernel API calls. Rolf Kalbermatter

QUOTE (pikro @ Nov 12 2008, 09:39 AM) You're obviously using it wrong because it does for sure work here. But I'm not going to upload a 1000 VI project! I'm pretty sure there should be an example to this effect in the LabVIEW examples though. Rolf Kalbermatter

QUOTE (mesmith @ Nov 11 2008, 02:43 PM) Additionally there is the possibility that msvcrtd.dll or one of its versioned siblings msvcrXXd.dll relies on yet other DLLs that are in debug versions and get installed with MSVC only. Rolf Kalbermatter

QUOTE (caspar @ Nov 25 2008, 05:11 AM) Quite likely. This behaviour in 8.5 was not a bug that got introduced but instead a change to the behaviour to make the .Net Interface in LabVIEW behave the way Microsoft meant .Net to be used. In earlier versions LabVIEW tried to be smart and locate dependant .Net components itself but I'm sure that opened a whole can of worms that was remedied by simply relying on the .Net behaviour itself. Rolf Kalbermatter

QUOTE (mesmith @ Nov 24 2008, 07:14 PM) Mark is completely right in all he says. The debug versions of the MSVC runtime libraries only get installed when you install Visual C or maybe an application with MSVC runtime support compiled in debug mode, although I'm not sure the debug version of the runtime libraries really belong to the redistributable part of Visual C, so such an application if not from yourself may be not legal. It's most likely a somewhat misleading error message in the shared library loader. LabVIEW has had traditionally a certain number of well known error codes. When adding a new subsystem the developer always had two choices: Adding a new error code for every situation or trying to find an existing one that matches the situation fairly well. Adding new error codes used to be a major hassle since all the necessary information had to be entered into the resource files of LabVIEW too which is a completely different work flow chain than editing the C source code, so the choice was usually towards reusing an existing error code. When LabVIEW asks Windows to load a DLL on its behalf Windows will fail the loading if a dependency can't be satisfied. The returned error code is sort of generic and there is virtually no way to get the information about what dependency was missing unless one would walk the entire import tables of the DLL and its dependencies. Translating OS specific errors into Framework specific errors is always a tricky and lossy business. Nowadays the errors are not as tight into the LabVIEW Framework itself so the choice is more often made to add subsystem specific error code ranges but the Call Library Node shared library loader code dates back to LabVIEW 3 and at that time priorities and possibilities were quite different. Rolf Kalbermatter

QUOTE (Paulus @ Nov 24 2008, 01:12 PM) That obviously avoids the alignment problem. Rolf Kalbermatter