Rolf Kalbermatter

QUOTE(klessm1 @ Oct 5 2007, 11:43 AM) LabVIEW 8.5 does use the QTLib for something in its user interface or whatever but I'm not sure for what. Look in your LabVIEW 8.5 directory to see those DLLs. The problem you are having is that your Surround SCC software uses that library too but not the same version as LabVIEW 8.5 uses. That gets you into the so called DLL hell. LabVIEW already has loaded it's own QTLib DLLs when the Surround SCC client gets loaded. This client also wants to load his QTLib for some functionality but since Windows sees that that DLL is already loaded into the current process it will simply attempt to have this client library link to LabVIEWs version of the DLL. And that goes wrong since those libraries are not binary compatible, something Unix shared library developers never usually worry to much about since they are used to versioning of the shared library name to resolve such issues. I'm afraid you run into a roadblock with Surround and LabVIEW 8.5. As I have no idea for what LabVIEW 8.5 brings its QTLib stuff with it I can also not help you with any ideas if and what would have to be disabled in LabVIEW in order to not have it load QTLib, if anything can be disabled. For its UI Widget stuff I can't really imagine that they replaced the entire existing windows manager code to use QTLib instead of continuing to use their own already implemented window management code, so what QTLib really is good for in LabVIEW 8.5 is really a secret to me. Rolf Kalbermatter

QUOTE(Aristos Queue @ Oct 6 2007, 06:32 PM) I would try to make a control required and then turn it into an indicator. But not sure if that could produce something. It certainly didn't in earlier versions. Rolf Kalbermatter

QUOTE(Yannick @ Oct 4 2007, 03:18 AM) Duplicate post, see http://forums.ni.com/ni/board/message?board.id=170&message.id=276066#M276066' target="_blank">here. The explanation in that post for string pointers inside a structure is wrong. It won't work like that without extra measures. Depending on the DLL it may crash immediately, corrupt some memory silently and crash later on, but something will go wrong sooner or later. Rolf Kalbermatter

QUOTE(BrokenArrow @ Oct 2 2007, 03:55 PM) Those box characters did even in DOS only show up if one didn't use some other codepage for displaying. Now caused codepages in DOS such a pain that they were not as often used so you could usually get away with this, but Windows 3.1 extended the codepage idea greatly and made serious use of it before they implemented 16bit Unicode support in Windows NT and ported it back for Windows 95. Only with Unicode was it possible to have support for displaying different languages at the same time without constantly having to switch codepages. Another means for that was MBCS (multibyte character encoding)which is what LabVIEW uses itself to support eastern languages in its localized versions but that is quite a painful standard as a character can have a varying number of bytes, with certain codes reserved to indicate the switch to a different "codepage". While the display of the lower half of ASCII characters is well defined, what is displayed for the higher half depends on the viewer and its interpretation. If displayed in a Windows (and LabVIEW) control you can also get away with setting them to certain fonts as every font has an implicit codepage for its first 256 characters. Rolf Kalbermatter

QUOTE(robijn @ Oct 3 2007, 03:49 AM) What I meant is that the WinAPI to deal with ini files has no clean means of dealing with comments. Adding them is impossible through the API and ignoring them is very limited. Only lines starting with a semicolon will be ignored at all by recent Windows versions. But for a line myToken=YES; This is a comment querying myToken will return "YES; This is a comment" Definitely not what the OP wanted! The same funcionality and more than what Windows has can be already done with the Configuration functions. The only drawback with those functions is that they disturb the layout of ini files sometimes (but not the functionality). And all I can say to that is that INI files are not really meant to be read by humans and definitely not by non-programmers. That is one reason why MS moved it into the registry where the presentation of data is left to an application (regedit) instead of having it embedded in the data. Rolf Kalbermatter

QUOTE(siva @ Oct 3 2007, 03:16 AM) OK I see you are using the InternetToolkit Web Server. The App Properties mentioned are only present for the built in Web Server in newer LabVIEW systems. Can't do everything the Internet Toolkit server can (such as CGI) but is quite capable for more static things. Rolf Kalbermatter

QUOTE(EdDeWitt @ Oct 1 2007, 03:09 PM) Not just LabVIEW for everyone!!! There isn't any standard at all and the only defacto standard is what Windows invented for ini files and as far as Windows is concerned there are no comments in an ini file. The fact that there are lines that contain some data that is never queried with a GetPrivateProfileString is all that makes them comments. Similarly SetPrivateProfileString does not really give you any functionality to add comments to an ini file. As per Windows a section is enclosed between brackets and what comes behind is not read and a ini token has a name that starts a line and a value that follows the equal sign. The value can be a quoted string if it must contain line breaks but otherwise it goes to the end of the line. One could of course devise various variants on this and restrict above limit to request double quoted strings for anything that contains line breaks AND spaces and stop reading a token value as soon as there is a non quoted space but that is not how Windows invented it. The Configuration functions already do some non-Windows stuff by escaping special characters and normalizing paths in order to be platform independant. If you want to change above behaviour it is fairly easy to modify the Configuration file VI's to do so as they are clearly structured and build up. They do the double quoting already for strings containing spaces but at least in 8.2.1 is a bug in that respect where the quoting is skipped if the section did not yet exist when adding a new key. Extending the configuration VIs to allow adding comments programmatically will however by a much more involved task. It's one thing to just ignore some data and a completely different one to add infrastructure to support it. Rolf Kalbermatter

QUOTE(Aristos Queue @ Sep 30 2007, 10:36 AM) Hmm, I have to say that the FP grid does not work like this for me. I tend to drop controls on a front panel and then nudge them with the cursors to where I want them (or use alignment and distribution) since the grid simply does not work well for me independent of what settings I have it. I recently resorted to disable the grid snapping for most VIs I'm working on after I found this by accident. For FPs that are meant to be visible to the end user the grid is to restrictive to get the look I want, since most of my FPs except the main screens usually really are application dialogs and use the system dialog style, and for other FPs I just put them so they are logically aligned in a similar manner than the connector pane is layed out. As far as I'm concerned a global "don't snap to the grid" option would be the best I could ask for. And yes my FPs usually adapt the background color to the system dialog background color too, so there goes your other argument :-) Rolf Kalbermatter

QUOTE(ryanlai @ Oct 1 2007, 03:01 AM) Traditionally the parallel port was an output only digital port. In order to make it get bidirectional various people came up with various solutions. 1) use one of the strobe lines as input and clock in data over that. Makes it really just a slow 1bit serial port!!!!! 2) Some hardware manufacturers made the hardware so that 4 of the 8 bits could be set as input. Better than 1 but not possible with every parallel port (the ones that only can drive the 8 digital data lines). 3) Some other manufacturers decided to go for the full bidirectional functionality of the entire port. 2) and 3) require extra register bits to setup the port in the desired manner and are of course exclusive of each other at any given time. Because of this variety and the many bugs in the actual hardware implementations VISA does not try to do anything on its own with the parallel port. Windows can be configured to operate the parallel port in one of these three modes provided the hardware chip supports that mode. But even when set that way none of above solutions will work with a 1 to 1 cable to transfer data between computers. You need to wire the handshake lines accordingly to the mode you have set the computers (and both are better set the same) to make this work at all. You can get some more detailed explanation for instance here http://www.thaiio.com/parallelportinfo.html So if VISA Read and Write will do the right thing on a parallel port depends on the actual wiring, the mode the parallel port is set in Windows and if the hardware supports that properly, which nowadays integrated chip-sets usually should. Who after this discurs still thinks connecting computers through a parallel port is a good idea, does this for a hobby and knows what side of a solder iron gets hot or can't be helped IMHO. Getting a serial port wired up correctly is in comparison almost trivial. Rolf Kalbermatter

QUOTE(Eugen Graf @ Oct 1 2007, 09:35 AM) For anyone looking for this information: Basically lvserial is meant to work similar to the VISA functions but without using VISA and instead going directly to the Windows COMM API. And I think Martin Henz did an amazing job and someone ELSE could put some time into it to help with documentation if they feel it is needed. Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Oct 1 2007, 10:31 AM) Personally I have resolved to copy my library VIs into the project directory itself whenever used in a project to avoid the mentioned troubles of changed behaviour between project developments. And one other thing I usually do for bigger projects is a unit test framework. It will not solve the problem of automatically detecting any dependencies in any project you ever programmed, but for projects where you have a well defined unit test framework in place you can easily run this unit test in every project you are interested in regularly to make sure there have been no regressions. This also helps greatly during development of a project itself where you can tend to make subtle changes to a seemingly unimportant function and suddenly other things fail in an amazing way. Rolf Kalbermatter

QUOTE(Ben @ Oct 1 2007, 05:42 PM) There are also Application Properties for this but I'm not sure if they are visible in a standard LabVIEW installation. Rolf Kalbermatter

QUOTE(brianafischer @ Sep 28 2007, 01:01 PM) You can usually do that for digital outputs but not for analog outputs. It would anyhow only read the value written in the digital registers of the DA converter and not the actual value on the analog output. To read the analog value there needs to be an AD converter too and that would make the DA converters extra expensive. However most NI-DAQ boards do have a lot more analog inputs so wiring the analog output externally to an analog input will allow you to do what you want. On some boards you can even use internal signal routing lines but programming the according switches is a lot more complicated than a simple external wire. Rolf Kalbermatter

QUOTE(tnt @ Sep 28 2007, 04:41 AM) Making sure VISA is installed will of course help tremenduously! MAX is only the UI configuration tool for all NI driver software. As such it does NOT access any hardware at all directly but looks for installed NI software drivers such as NI-VISA, NI-DAQ, NI-DAQmx etc and queries them for known resources. I didn't consider that you could somehow end up with MAX on a computer without having installed VISA. Rolf Kalbermatter

QUOTE(Shoyurx @ Sep 27 2007, 12:37 PM) The serial port in your computer is entirely independant of your external device. If you can't see it in MAX it is either not there, not properly installed in your OS or disabled. MAX automatically shows the serial devices it can detect from the OS. It does not allow you create arbitrary devices for that class since that makes no sense. A port is either there and accessible or it isn't. Have you tried to do a Refresh of the MAX configuration (hitting F5 after starting it up)? That will rescan the system for built in devices and show any it can detect. If that does not give you a serial port then you have to start debugging there and see why MAX can't seem to find it. After you got your port you can start to deal with your device but until then it is completely irrevelant to this. Rolf Kalbermatter

QUOTE(Ben @ Sep 27 2007, 07:53 AM) Long ago I did look into this also in combination to interface to external script servers like Python for instance. One idea I came up is to use the LabVIEW TCP/IP VI server interface directly (instead of going through it's Active X interface which would limit the solution to Windows LabVIEW hosts only). I could access this interface through direct TCP/IP sockets in LabVIEW 6.1 but eventually run into some problems to access the Call by Reference interface (nothing that couldn't be overcome but the flattening of the typedescriptor and the different parameters is a real headache to get right and requires a lot of inside research into the LabVIEW datatype storage model (almost fully documented in an older App Note). I eventually stopped development on this because of several reasons. - My Library was for ease of testing and debugging written in LabVIEW. Not very useful really considering that you can much more easily use VI Server directly and converting this interface to another language like C, Python, etc would still be quite an undertaking. - NI obviously never documented that protocol for some reasons. One of them is that they change it between LabVIEW versions albeit not extremely. But the introduction of the 32bit safe typedescriptors in LabVIEW 8 certainly must have had a profound impact on that protocol although I never looked into that. Support of the entire (private) LabVIEW object hierarchy through this interface in LabVIEW 7 should probably also have made some impact here. In general I concluded this interface to have great potential but its undocumented nature and version dependant changes make it basically unsuitable to rely upon for any serious project. And for just some fiddling around it is way to much work to develop and maintain such a solution in any language I could imagine. But it would be quite feasable to create a LabVIEW DLL/shared lib that wraps the important VI Server methods and functions into exported functions and access that from any host that is capable to call into shared libraries. You would have one DLL/shared lib per platform you want to access LabVIEW from but since VI server is network TCP/IP based that would not have to be the machine that is running the actual LabVIEW target VI. Rolf Kalbermatter

QUOTE(Ben @ Sep 27 2007, 03:13 PM) I used this feature in older LabVIEW versions exactly to detect crosslinking! It allowed to see if a project was referencing somehow VIs outside of the project file hierarchy (and vi.lib, user.lib). Any such VIs I usually squashed immediately to avoid later problems with cross linked VIs referencing VIs from other projects (and even worse: other LabVIEW versions). Unfortunately LabVIEW 8.0/8.2 lost that capability and I didn't get around to try 8.5 yet for any real project. Rolf Kalbermatter

QUOTE(yen @ Sep 24 2007, 01:59 PM) Actually it seems not just to be the spam folder. I recently had to reset my password and did it three times before a mail showed up. And yes I did check the spam folder and yes I did wait about 10 minutes and even longer before reattempting. Rolf Kalbermatter

QUOTE(jbrohan @ Sep 23 2007, 09:10 AM) The problem with speech recognition is that it is a failry complicated technique to get to work in any useful way. I only played briefly with it in other applications, without trying to import it into LabVIEW and it did not feel up to what I would expect from such a tool. It is simply rather complicated to configure and train it appropriately since human perception of speech seems to be such an involved process and as probably anyone who knows more than one language can attest, is also very much depending on the environmental influences where the language is one parameter of it. There has been work in speech recognition for more than two decades now with speech recognition technology already available in the Windows 3.1 area and still it hasn't made it to a meaningful means of human interaction with the computer, not to talk about replacing human interface devices like a mouse or keyboard at all. This has been partly because of processing power and memory usage but that can't be the only problem, when you consider that computers have now already 1000 times as much memory as was common 15 years ago and the CPUs run at about 50 times the speed of then and are even more powerful, not to mention the availibility of multicore and multi CPU systems. Not having looked at the MS Speech recognition API in a long time I can't really say much about it but it has been already complicated years ago and probably got even more possibilities and features since then. Rolf Kalbermatter

QUOTE(siva @ Sep 20 2007, 03:33 AM) SVN really works the same. But the OP request was explicit intermediate commits to the server while away from the network, and here CVS will fail exactly the same as SVN. Only solution I see is to keep the CVS server on the local machine too and put it's repositry on an external harddrive or maybe make a regular backup copy of the entire local repository to some other location. I know that that will work with SVN since a repository is there completely self contained without any external information that could get lost when doing a simple file backup. Rolf Kalbermatter

QUOTE(manic @ Sep 19 2007, 03:39 AM) If I would be tasked with that my reaction would be simple. Don't even try to redesign it! It will cost at least double the time than doing it from scratch and still not be as clean and performent as it should be. Rolf Kalbermatter

QUOTE(Gabi1 @ Sep 19 2007, 04:04 PM) As Aristos already mentioned the extra memory used for a skalar notifier won't really kill your memory at all. The occurrences on the other hand are not producer/consumer oriented and while multiple places can wait on the same occurrence their mechanisme is not in such a way that you could easily do the opposite at all. On the other hand polling an occurrence with a small timeout, while not optimal, will not kill your CPU performance either. Rolf Kalbermatter

QUOTE(karthik @ Sep 19 2007, 02:08 AM) I would think Property Nodes to be the magical solution here. Rolf Kalbermatter

QUOTE(Louis Manfredi @ Sep 18 2007, 11:09 AM) Well, such is life. Most things I found by accident, searching actively for something or through user groups/mouth of word/LAVA/Info-LabVIEW etc. and when then looking for them they were eventually somewhere in the printed or online docs, but it is simply to much material to read through completely. I have long ago resorted to work with what I know and try to learn new things by various opportunities and simply not let myself be bothered that there are still many golden eggs out there that I do not know about. If I would have a photographic memory I would simply scan all the documents in a matter of flipping through them and rely on that, but alas, I'll have to do with what I can. Rolf Kalbermatter

QUOTE(Cherian @ Sep 12 2007, 01:58 PM) Wow, you mean you wrote a driver for the FPGA board to communicate with it from within LabVIEW? In that case I would assume you know more about how this could be done, than anyone else here on LAVA possibly could know. And probably also almost anyone else except those that work for NI and developed the FPGA product and maybe a system integrator or two under NDA. Rolf Kalbermatter