Rolf Kalbermatter

QUOTE(AdamRofer @ Apr 12 2007, 12:51 PM) It's not very likely there is any method to do that. Rolf Kalbermatter

QUOTE(Ed Dickens @ Apr 12 2007, 11:18 AM) Well I checked and BOOLEAN is an alternative Windows SDK definition and equals BYTE which is basically an 8bit value. Some Windows APIs use that for boolean parameters and return values, although not the standard Win32 API, which normally uses BOOL (a 32bit integer boolean). Rolf Kalbermatter

Another way is this. It is however Windows only and uses the Windows GDI to print the text to any installed Windows printer. Strictly taken it is not sending the text to the printer at all, but instead renders the text through Windows GDI and sends the resulting image to the printer. It's a first attempt for some application I did recently where the Report Toolkit installation was no option. So I'm sure there are a few rough edges and optimizations which could still be improved. Rolf Kalbermatter

QUOTE(MartinD @ Apr 4 2007, 06:56 PM) This is a standard problem when dealing with paletted bitmaps. The easiest solution is to translate the paletted bitmap into a non-paletted one (24bits for instance), do the edits you want to do and then if you want to go back to a paletted one use a color reduction algorithme. Doing this all in LabVIEW is quite a lot of work and number crunching and I would recommend to use applications that where actually created to do just this sort of thing. Adobe Photoshop is one of them, Paintshop Pro can certainly do it too, and if you want to go for free Gimp is an incredible package. But expect to learn a few things an get acquinted with each of those applications in order to do any meaningful thing with them. But trying to do it in LabVIEW is certainly an even much more labour intense task. Rolf Kalbermatter

QUOTE(alukindo @ Apr 9 2007, 09:34 PM) I think you confuse some things here. A VI never needs to be set to reentrant in order to be able to call a CORRECTLY setup Call Library Node. If you need to do that you have a problem with the configuration of your Call Library Node not matching what the actual function needs. Calling ActiveX components in non single-threaded mode is an entirely different issue. An ActiveX component when installed is registered with the so called threading model it can work with. That is one of the reasons you should install an ActiveX component rather than trying to copy it to another system. Problems arise when this threading model does not match with what the ActiveX component actually is able to handle. If it says it is multithreading save LabVIEW will just assume that this is the case and not take any precautions to protect the ActiveX component in any way. This means the ActiveX component can be called from different threads in LabVIEW and if the component is not carefully written to handle this properly it will quite soon crash. Putting the VIs into UI thread will basically force LabVIEW to call the ActiveX component always from this single thread and solve the issue, but the problem is really in the registration of the component being bad. This might be not so apparent in other programming environments since it is quite a bit of work to actually make an application multithreading in them at all so it seldom happens and even if they use multiple threads the programmer tends to access a specific component usually always from the same thread. LabVIEW however simply has multiple threads and also uses them unless it is explicitedly informed not to do that for certain things. Rolf Kalbermatter QUOTE(Ed Dickens @ Apr 9 2007, 03:02 PM) I'm having problems getting a particular function ina dll to work. I'll try and provide all the needed documents and files hoping some one can point me in the right direction. Included in the attachment is the .dll, the VI I'm working on for this function, the documentation for the function, the header file for the dll and a sample C source file that uses this function. The problem I'm having is the function appears to return the data, but when it attempts to write the data to the indicator, LabVIEW crashes. The function is suppose to be run twice. On the first run you're suppose to have the "ProvidedBufferSze" parameter set to 0 and the "Buffer" = Null. After the run, "NeededBufferSize" will contain the needed bffer size that can be used on "ProvidedBufferSze" on the next call. The size of the structure containing the data is suppose to be 100 bytes according to the documentation. On the first run of the function, "ProvidedBufferSze" returns 194 with a two channel device in the PC. It seems to me this should be 200. On the second run with either 194 or 200 on "ProvidedBufferSze", the function (running with execution highlighting on), I can see the "Buffer" return a 2 element array. When this array is written to the indicator (or a probe), LabVIEW crashes and I get the Windows "Send Error Report" dialog. Mainly I just want to verify that I have the CLN setup correctly and my logic in the VI seems correct. After this, I'll probably end up calling the manufacturer to see what they have to say. Thanks Ed Well, you can't embed a string in a cluster and just pass that to the DLL. A LabVIEW string is something very different than what a C DLL would expect. Also the prototype clearly shows the string as a fixed size entity which means it is inlined in the structure and not even a C string pointer (which actually makes it easier for us to call it from LabVIEW if done right). So what you want to do is passing a flat buffer of bytes to the function with the needed size. Something like what is shown in the attachment. One afterthought. Your size numbers you mention indicate that the structure only uses 97 bytes for the structure. From what I can see in the header file the only thing I'm not sure about is the BOOLEAN datatype. The usual Windows type is BOOL which is a 32bit integer but BOOLEAN seems to be defined as a BYTE type. So obviously your structure would be only 97 bytes long and Softing seems not to use padding in their API which makes the buffer always a multiple of this value. This would mean you will have to adjust the attached VI slightly to get the right data from the buffer. Basically changing the 20 constant to 17 should already work although you may have to make sure that the embeed boolean gets interpreted right too. Rolf Kalbermatter

QUOTE(TiT @ Mar 6 2007, 03:16 AM) Haha! 256MB is enough for XP if you run nothing else on it! Running and SQL Server and LabVIEW is definitely stretching the limit to an almost inacceptable point. Tell the customer that 512 MB memory is really not a lot for Windows XP and SQL Server alone and that LabVIEW also needs a bit of memory to work. Saving on memory nowadays with the prices being so low for hardware is simply stupid (But you better don't say that verbatim to your customer). Rolf Kalbermatter QUOTE(yen @ Mar 8 2007, 02:22 PM) 4 bytes = one I32 number = one reference. It sure sounds like you're opening a reference and not closing it. To check if this is a driver issue you can use the same driver and create a simple loop which runs many times and does the open-insert-close cycle. If there is a problem, you should see it even there. If not, can you upload the actual VI whose images you posted? A LabVIEW refnum typically takes more than 4 bytes. The refnum itself is a 32bit value but it points internally to a structure containing the actual management data associated with that refnum such as the OS handles and other necessary data for LabVIEW to manage that refnum. Rolf Kalbermatter

QUOTE(JFM @ Feb 15 2007, 02:24 PM) INI file paths are always normalized when you use the LabVIEW INI Read/Write Path VIs. And yes the normalized form is basically Unix annotation. Since VxWorks has most likely unix roots I think the actual path string syntax would be correct. One more reason to deal with paths as much as possible using the LabVIEW built in Path data type! That solves any problems with plattform differences. To assume that CRIO is always one plattform only would be to limitating for sure, and as LabVIEW will get expanded to include more and more distributed technologies this only gets more true in the future. Soon you might communicate from within your LabVIEW development environment with a LabVIEW programmed fridge on some RT Linux operated 32 bit embedded chip ;-) integrating it into your web service application that runs on another remote system under Apache or something. Rolf Kalbermatter

QUOTE(Val Brown @ Feb 16 2007, 02:27 AM) The CPU usage is an effect of the asynchronous operation of VISA nodes. It's a bit strange in fact since asynchronous is supposed to just safe CPU and in fact it does but in a strange way, due to LabVIEWs internal cooperative multithreading. Synchronous operation would lower CPU usage but block the diagram they are executing in until the operation is finished. The additional CPU usage is in so far not that bad as LabVIEW does relinquish the CPU to other tasks quite happily if they are there. If they aren't then yes it tends to grab quite a lot of the CPU to make sure to service the asynchronous call as fast as possible. Dropped connection errors such as -1073807194 certainly have to do with the driver somehow. It could be that the driver got reset by whatever reasons. Maybe an USB bus reset. -1073807343 is insufficient location error, meaning an invalid VISA resource. -1073807264 is a strange error for serial port as Controller in Charge is a GPIB term but as such also would point to a driver error. So yes from two of your errors I would conclude a serious serial port driver or hardware issue. The insufficient location error would point IMO to some wiring errors where you do not wire a valid serial port resource to the functions. The old serial functions were a bit more forgiving in this somtimes as they were just assuming a default number that pointed to the first serial port. But this was at the same time a serious software design flaw too. Rolf Kalbermatter Rolf Kalbermatter

QUOTE(Thang Nguyen @ Feb 15 2007, 07:31 PM) It depends a bit on the connection type. For serial there is not much more than sending a command and waiting for the answer. If that doesn't return anything you can retry once or twice but then you should consider the connection broken and close and reopen it. TCP/IP can give you a connection closed error which you also should handle but that is insofar not enough that a broken network link does not necessary mean that you get this error. So for that you do basically the same as with serial too. Whatever you do you should not just do the classical LabVIEW error cluster handling where you do not do anything anymore once any error occurres. Instead you have to detect errors and actually do some error depending retry or reconnection attempt to get a stable and robust communication. Rolf Kalbermatter

QUOTE(UserXXX @ Feb 15 2007, 03:00 AM) You have a serious problem with that structure. The variable sized array can not be flattened to a stream without adding extra information as to the length of it. And considering the complexity of your structure it seems a very bad idea to try to resemble that completely in a LabVIEW cluster. There will be little else to do for you than dissecting that cluster into its more manageble parts in a VI and stream it yourself int a byte array and to the format required by your remote side. Personally I think an application level protocol that uses such complicated structures is is more or less useless! Rolf Kalbermatter

QUOTE(Val Brown @ Feb 14 2007, 03:13 AM) No I haven't really used it for actual communciation. Just the serial port enumeration to display available serial ports in a user interface that communicates through XML with an external application that does the actual (proprietary) serial protocol. Seemed like overkill to have to install VISA for that functionality and the VISA Find Resources is also a bit slow. The fact that you get errors in Martins library too seems to point to flaky USB-serial adapter drivers. Have had them in the past too, with causing me all kinds of troubles such as working for hours and suddenly not doing so without a reboot. There are definitely USB adapters and USB adapters and finding the good ones is a trial an error operation. Possibly the old serial functions just didn't do proper error handling, masking those problems althogether. They are from a time when Windows was 3.1, 16bit and anything than multithreading so they probably got away with anything but a proper error handling. Win32 is a bit more demanding but the legacy serial driver has to my knowledge not been updated much since the initial development somewhere in 1991 and probably was a bit of a mess from the old 16bit to 32bit translation hacks that had been necessary for the Windows 3.1 version. For Win32 it was probably mostly recompiled but not much more. It definitely had its quirks and limitations but maybe your library just works around them somehow and now you face troubles with adapting these hacks and quirks to VISA proper. Rolf Kalbermatter

QUOTE(alnaimi @ Feb 12 2007, 04:43 AM) Since this seems to be using the Keithley driver they are the best ones to be contacted about this. They know what this error message means as I would assume they know their own software a bit. To me the error message sounds cryptic at least. Rolf Kalbermatter

QUOTE(UserXXX @ Feb 14 2007, 02:36 AM) You don't! A cluster with so many elements would be awkward to work with. One thing you can do if the entire cluster is still flat is treating it as a single array of U8. The difficulty with this is that you need to do your own Replace Array Subset into that array at the right offsets (you will have to calculate those offsets yourself) before passing the array to te CLN and also doing Array Subset or Index Array with the right offsets to get possible data out of the array afterwards. Still works but it is a major pita and the moment for me to start a C compiler and create an intermediate DLL for sure. Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Feb 13 2007, 12:36 PM) No! I haven't looked at it yet, but before they tacked the LLB to the end of the executable stub and then added a small header (I mean tail) behind that that told the loader where the LLB was. I have a suspicion that they now add the LLB as a custom resource to the resource directory of the executable. Not really to dwart anyone to see the LLB but instead to allow signing of executables in VISTA. They just used that change to purposfully "forget" updating the exported LLB routines to look for an LLB in that place. Gave them some easy way of minimal obfuscation. And I still think anyone worrying about his code being picked from an executable in this way has a lot of other problems to deal with frist, some psychological ones not to be among the least ones. Rolf Kalbermatter

QUOTE(prayami @ Feb 11 2007, 12:23 PM) Well recompiling VIs is always necessary when you go from an older version to a newer version. That is completely independant of CINs. Any VI will prompt the user having loaded it in a newer version than what it was created in, to save that VI. And as said I compiled regularly CINs in LabVIEW 4 or 5 and they still load and run in newer versions. Abandoned CINs at around LabVIEW 6 as they are now considered legacy technology and don't really provide anything above DLLs but have quite a few drawbacks as far as maintenance is concerned. Rolf Kalbermatter

QUOTE(Val Brown @ Feb 13 2007, 07:14 PM) First with the exception when starting with VISA I haven't met anything that could have been done with legacy serial but not with VISA. I'm using it quite often for all kinds of serial communication and haven't seen serious troubles in quite a while also with USB to serial adapters. If you really need to do it otherwise your best bet will be to use Martin Henz's serial port library that you can download from http://www.mhst.de/downloads.html. But the only real reason so far for using that was that it is independant of NI licensing which used to be complicated and difficult in the past (but they fixed that in the meantime) and it's installation is not requiring a 100MB download from NI. No functional reason to use that so far. Rolf Kalbermatter

Definitely feels faster. Thanks Mike for giving us LAVA. Rolf Kalbermatter

It really depends! If you want to make an executable anyhow just build in some timecheck after which the application will refuse to run. Will obligate you to regularly create new trial executables. If you want to distribute trial libraries do the same in some essential VI that one has to use and make it display a dialog too. Password protect that VI. Any other means is probably more hassle than worth to do. In any case be prepared that a few people will download your software but you probably won't sell much. It is already hard to get a lot of people to use free Open Source libraries! Rolf Kalbermatter

These are typical Windows SDK types. But your header file does not include any other header files so it is syntactically not right. A C compiler could not understand it either without additional includes defining those types. Bascially that whole header file looks like a big mess to me. I'm surprised that Microchip does release something like this. There have been various posts here on LAVA and the Developer Exchange showing the actual type definition of those Windows SDK types. Adding them to the top of your header file seems to be the most simple solution. I do not understand your question about defining your own data. I would say no but can't be sure. Rolf Kalbermatter

Yes but!!!!! As long as this call is the only one to this DLL in your entire application you are fine. But if you ever decide to add this VI or another one calling into that DLL somewhere else in your LabVIEW program you are creating something I call "peut-

This header file uses a very strange and unusal way to define the function prototypes in the DLL. In fact it does not define any prototypes but just function pointer types. That's definitely not a standard way to incorporate this DLL into once own code even in C. Try to change for all functions DWORD (*MPUSBGetDLLVersion)(void); to DWORD MPUSBGetDLLVersion(void); basically removing the brackets around the function names and also the * in front of the function name and then try to import this again with the DLL import tool. Now it should work. Rolf Kalbermatter

I know about this technique and have used it infrequently in the past. But basically in order to be able to do that you need to know a lot about how you would do that in C and then it gets almost always as easy or even easier to just write a wrapper DLL that does the correct translation. It's definitely not for anyone that has trouble to understand pointers and references. So instead of mentioning that this can be done and have people ask me to do it for them I just say it can't really be done. The people that know how to do it or at least know enough to be able to figure it out can easily find it themselves and usually agree after the first trial that it's very frustrating work to do. Doing alloc(), memcpy(), free() through LabVIEW CLNs is while possible, a bitch to do and the diagram basically looks very soon like someone had a very bad programming day. Rolf Kalbermatter

As long as those clusters to not contain variable sized elements (pointers, arrays with [] instead of [x]) you simply inline them into one big continous memory area. Actually you can keep the clusters in the clusters for better readability as LabVIEW does this same inlining too. The only problem you need to watch out here is possible byte padding. LabVIEW always uses byte packing without any padding but most external libraries nowadays use 8 byte padding. That means the offset of an element is always aligned to the smaller of the two values: 1) a multiple of the data type size 2) the alignment (here 8 byte) by adding extra filler bytes before that element to make it aligned. You can actually adjust for that too by simply adding the necessary amounts of uInt8 and uInt16 dummy elements before the aligned element since adapting to alignment with a packing compiler is possible but not otherwise. Rolf Kalbermatter

Hmm, you are right that property always returns 0. However defining 0 for the parent window for a dialog should make the dialog system modal. Hmm, hmmm??? Rolf Kalbermatter

I have nothing specific to add for the moment but I like the idea to get a more exception like mechanisme in LabVIEW error handling. That this would be possible with maintaining compatibility to the old cluster I hadn't even considered. At least NI has an internal way of mutating VIs automatically when upgrading them to a new version (the update specs are in binary format in Resources/vicnvrt somehow), but staying compatible would also allow to use such a mechanisme in older versions of LabVIEW. Rolf Kalbermatter