Jump to content

Rolf Kalbermatter

Members
  • Posts

    3,772
  • Joined

  • Last visited

  • Days Won

    242

Posts posted by Rolf Kalbermatter

  1. QUOTE (Norm Kirchner @ Mar 20 2008, 01:22 AM)

    If you want a sneak peek at the code of the new native 3d graph and you're on the beta team drop a new 3d graph control down and right click go to advanced and open the Diagram of the XControl that is associated w/ the 3d object.

    VERY SCARY CODE, but still nice to see the guts every so often, even if there is some shit still in the colon.

    Jeez, this guy must have used a 30 inch screen.

    Rolf Kalbermatter

  2. QUOTE (tcplomp @ Mar 20 2008, 04:21 PM)

    Well that will be a nice experience when someone sits at your computer...

    It must be like sitting behind a german computer (entschüldigung) where I tried to type in my password, which contained a 'q' you know under the 1. Uhm, no that's where the 'a' is located...

    That must have been a Belgian (AZERTY) keyboard instead. German is QWERTZ

    And are you saying you use the Caps Lock at all? For me that is the most useless key on every keyboard and since I use LabVIEW (and have not adapted to auto tool selection) the one that causes probably the single most sh.. exclamations by far.

    Rolf Kalbermatter

  3. QUOTE (Darren @ Mar 19 2008, 07:48 PM)

    I agree with Stephen...the established method for creating new VIs from a template is the New... dialog. How many times in a LabVIEW editing session are you guys wanting to create a new VI based on a template that resides in the palettes?

    I never use the New... dialog for VI templates and very rarely for anything else. The way I open instantiated VI templates is simply by double clicking them in Explorer. I guess that is a remainder of pre LabVIEW project times where Explorer was part of my project management, together with a Top Level.vi that contained any and all main VIs and dynamically called VIs.

    Rolf Kalbermatter

  4. QUOTE (Michael_Aivaliotis @ Mar 19 2008, 04:13 PM)

    In 7.1 there is a feature called compare VI Hierarchies and works well. The key is to create a toplevel VI that contains all of the subVI's. You may already have one if you have a User interface that calls code. Otherwise create a blank VI and drop the subvi's onto the diagram and save it. Do this for both versions of code. Now open the tool under Tools>Compare>Compare VI Hierarchies. Where it asks you for the First Hierarchy and the Second Hieratchy you need to select the two toplevel VI's you just created. Notice that it states the second Hierarchy will be renamed. This is temporary. What this implies is that you probably want to make your edits on the First hierarchy since it stays intact (not renamed).

    Pease note that Compare VI Hierarchies, different than Compare VI is a Professional Development System feature and therefore not available in the Full Development System if I'm not mistaken.

    Rolf Kalbermatter

  5. QUOTE (7J1L1M @ Mar 11 2008, 10:03 PM)

    In LabVIEW < 8.0 this function was indeed called Seek but very seldom used, since the Read and Write File functions had an offset input that defaulted to the current offset.

    Rolf Kalbermatter

    QUOTE (7J1L1M @ Mar 12 2008, 01:30 PM)

    Thanks for all the suggestions! I'll see what I can do with the "append to end of file" technique, although I'm afraid that will be extremely hectic and complicated for me
    :(
    . One of my main goals with this format was to attain the smallest size possible (even at gigantic sizes! :laugh: ) for easy transfer, but still with the speed of commercial databases. I may have found something that will do what I've been wanting to do:

    Windows Kernel32.dll has some functions called file mapping like "CreateFileMapping", "Memmove_a", and other similar functions. It looks like it may be possible to use these to actually "move" parts of the file to "nothing" and thereby erase it. I believe there is also an insert function. Does anybody have any experience with file mapping? If so, it may be possible to use this idea. Here's a link to a situation similar to mine that uses this method:

    If anyone has an idea for this, it would be most welcome!

    File mapping simply maps a view of the file into memory. It is meant to quickly modify files but there is no way to map a part of the file to "nothing" and make that part magically disappear. You still have to move the remainder of the file view to the new position before closing the file mapping to make that part be go away.

    Writing a VI that goes to the offset where the modification starts and then in a loop reads in junks of data writing them back to the new desired offset will be not that difficult. If the part to insert will be bigger than the part it resizes you obviously will have to start the file junk read and write back at the end of the file if you do not want to write the changes into a new temorary file first and then deleting the original one moving the temporary file to its name. Of course this too would be done with a loop reading in junks at a time to avoid having to read in a 100MB file into memory.

    For security reasons I would recommend to do the temporary file anyhow as this operation will take some time (seconds) and there is always a chance that a crash in the middle of the data copying might leave the file in a completely corrupted state.

    Rolf Kalbermatter

  6. QUOTE (jlokanis @ Mar 13 2008, 08:33 PM)

    I have written a large test application that logs all data live to an SQL server. I am using the System.Data.SQLClient .NET assembly to interact with the database. This is working, but it seems to be a bit slow and I am wondering what the best method is out there. There are lower level drivers between this assembly and the transport layer. Has anyone written VIs to directly access those?

    One thing I did was write a little C#.NET code to move the record set data from .NET to LabVIEW in a single block move instead of an iterative process. This was a huge time saver, but I am wondering if there are more ways to speed things up.

    I realize that LabVIEW is not very speedy when calling .NET code. Would it be worthwhile to try an implementation using COM (ActiveX) instead?

    What about directly calling the lower level DLLs that the .NET code calls?

    Is there another solution entirely that I could try? All I need to be able to do is pass a SQL query to the DB and get back a record set.

    I'm using my own LabVIEW ODBC VI library to do database access. From a VI interface perspective it is closely related to the previous non ADO Databases Toolkit from NI, ex Ellipsis Medium SQL Toolkit. All these VIs do is calling into a DLL/shared library that interfaces to the actual ODBC API. While there have been claims that ODBC is slow this is not really my experience but the problem is similar to what you see in your ADO.NET access. The most simple ODBC access method is to query every row and column value independantly causing many server roundtrips. By using the right methods (multi row cursors the equivalent to rowsets in ActiveX ADO) you can avoid many server roundtrips and get quite impressive speeds. I implemented this in the DLL almost completely transparent to the calling LabVIEW application (almost because you can influence the rowset size by a parameter or disable it entirely). Doing the SQL datatype to LabVIEW datatype conversion in the DLL too, and making sure to use similar datatypes in LabVIEW that match closely to the SQL datatype instead of all strings will also help to speed up DB access.

    And before you ask, no I haven't made that VI library available to people outside of our company yet. I considered doing this but there are several reasons why this might be not such a good idea. One of them is that there are already many (albeit non ODBC) database access libraries out there for LabVIEW. Adding yet another one is not likely to help many people. Another one is that it was and is a lot of work to write and maintain such a library and even more to support it once it is public but there is no real market for VI libraries sold by someone else than NI.

    Rolf Kalbermatter

  7. QUOTE (neB @ Mar 17 2008, 01:59 PM)

    Talk about "oil and water" !

    I would be impressed if anyone has done that.

    Ben

    PS: If I had to guess anyone has done that, it would be Rolf.

    No I haven't done that yet. I have a fairly complete ODBC LabVIEW library here but that interfaces to the ODBC API and to my knowledge the ODBC API is not available on the RT OS. There is a little chance that you could get the Windows ODBC Manager running under the older Pharlap based RT OSes and that some ODBC drivers might work too. But it is a big if and that would definitely fail for the newer vxWorks RT Targets as that requires different object format libraries, so that there is absolutely no chance to get the Windows ODBC Manager working on them.

    To get that done one would have to port unixODBC (or libiODBC) to the RT target. However that still would leave the problem of the according ODBC driver open. So in principle this approoach is a dead end.

    Another approach would be to implement the actual database network protocol directly on the RT system. But that is really non trivial even when using existing open source libraries to create a shared library module for the RT OS. First porting those libraries to RT OS is tricky at least as RT OSes have simply a more limited OS API set than normal desktop systems. Second depending on the database used those libraries are fully fledged (Open Source databases like mySQL) or more or less limited or even antiquated (like for SQL Server). Reimplementing the protocol in LabVIEW while in principle possible is simply such a big project in itself that it is just not gonna happen.

    What I would do is creating some LabVIEW ODBC proxy running on a generic ODBC enabled plattform (Windows, MacOS, Linux) and then using VI Server or just a simple TCP/IP protocol, call it's methods from the RT application. This also would make sure that the actual ODBC execution is entirely isolated from the RT system itself.

    There are also commercial ODBC proxy applications that allow to be interfaced with more or less simple network protocols and/or easy to port API libraries.

    However putting the entire DB on the RT OS is a sure way to kill its RT capabilities.

    Rolf Kalbermatter

  8. QUOTE(Klaus Petersen @ Mar 4 2008, 04:06 PM)

    Hey.

    My problem is that i'm using the ADO-toolkit to connect to a database. But apperently this relies on the host having MS access installed to work. Is there a way around this? Can i include an installer that will make the target able to call access db's?

    If you install MDAC (already installed on recent Windows OSes like XP) you should be able to read Acess database files *.mdb) using a properly formatted DSN/UDN.

    Rolf Kalbermatter

  9. QUOTE(Justin Goeres @ Feb 25 2008, 03:44 PM)

    I think that's a vast overreach. "Dealing with strings" probably wouldn't make the Top 5 in my list of "Worst Things About LabVIEW."

    I agree that string handling can take up a lot of screen real estate, but this can be mitigated a great deal by encapsulating more of your code into subVIs to hide (or at least contain) the messy parts.

    I take LabVIEW's string handling at anytime instead of things like Perl's obscure and very compressed string manipulation operators. I do always get headaches trying to figure out what the result of such expressions would be whereas in LabVIEW I can fairly easily tell what the operators do.

    It's using real estate, but hey as you say we have subVIs and they should be used for sure.

    Rolf Kalbermatter

  10. QUOTE(TobyD @ Feb 25 2008, 02:31 PM)

    Based on many of your posts, it seems like you have not yet found the help files. If the "Context Help" window is not already opened, click on Help --> Show Context Help on the menu bar. Now when you hover over the SMTP Send Email.vi some details about the VI will show up in the context help window. If you need more help on the item, click the "Detailed Help" link at the bottom of the context help window and read all about the various connections of the vi you are examining.

    In this case, the detailed help tells you everything you need to know about the mail server input to this vi.

    I would really encourage you to try to find the answer on your own before posting here.

    Hmm, it doesn't really tell her the exact IP adress, but then that is also something the user of the application (meaning her) should know. She probably never had to configure her email account either in her email application, otherwise if she did she would know the adress of her SMTP server.

    Rolf Kalbermatter

  11. QUOTE(ned @ Feb 25 2008, 03:12 PM)

    It appears that you're trying to directly call a DLL that contains an Automation, OLE, or ActiveX component (no idea what the difference is between these, they may all be names for the same Microsoft technology).

    Lol! It's not all exactly the same but they are fairly related. ActiveX is based on OLE as it's component object model, but adds extra things such as persistent object registration and activation interfaces, standardized object embedding and such. Before ActiveX it was not really possible to embed other applications easily in a generic way.

    Rolf Kalbermatter

  12. QUOTE(crelf @ Feb 25 2008, 06:53 PM)

    You've missed my point entirely Rolf - I was trying to say that "just because you can, doesn't mean that you should". You shouldn't assume that everyone in your target user base has access to a broadband connection. At least, not yet :P

    But they didn't say they did it because they can. They said they did not think it was a bad thing since in nowadays days you do not use the same means to distribute applications as you did back in 1991. I'm sure the LabVIEW developers do not add software components to the runtime system just to bloat the whole thing. They do that because it adds some functionality somwhere and since modern distribution systems allow such sizes more easily they go rather for the added functionality than spending months and months to try to squezze another few MBs out of it or create a complicated and cumbersome user configurable component based runtime installer.

    Yes the components are actually there but the user interface to configure them would be a bit complicated for sure and many of the components not even we could decide if they are needed or not, until you happen to run the application on the target system in question and notice strange artefacts or errors somewhere.

    There were at least for 8.2 already two different runtime installers. One containing everything and wheigting in at around 89MB and the other containing only the actual runtime and weighting in at 24MB. And many users wondered why they can't run their application when using the smaller one only to find out that the bigger one worked. That little Mean function in there unfortunately wanted to see the MKL installed and that was one part among many others that was not installed by the smaller installer.

    NI specifically said the small one was for Web Browser use only (Front Panel inside a web browser) and that means anything the Front Panel needs is there but all the rest that a diagram function could use is not there if it isn't contained in the runtime engine DLL itself since the diagram is executed on the server anyhow. And many users got upset that there was a smaller installer.

    So I think we can ask for more fine grained selection of runtime engine components but it won't make things really easier and therefore won't be used much. Also as you can see from the 8.2 installer, much smaller than 20 MB won't be possible anyhow (you could still shave of the non-English or whatever you want language resources) and that is still not a size that you normally want to email. Even the most minimalistic LabVIEW 7.1 runtime engine that I sometimes copy together with my executable into the same directory was at least 10MB in size and then you couldn't do 3D controls, or Advanced Analysis Library or many more things. Good enough for a small Autostart executable on a CD but not really useful for a normal LabVIEW application.

    Rolf Kalbermatter

  13. QUOTE(Aristos Queue @ Feb 25 2008, 10:40 AM)

    No, you can't blame OO. The OO code isn't in the real time engine yet. That's still in development. Many people have made this assumption. For that matter, the project isn't compiled into the runtime or realtime engines, so it isn't that either.

    For reference, when the OO code does become part of realtime, we expect to add a couple of one or two K to the runtime engine size at most. This is still a ways in the future, but it is on the road map.

    Hmm, RTE can also be run-time engine. And there I would expect to have OO runtime support, otherwise you couldn't run executables that use OO. But I agree the runtime support for that won't be extereme in size.

    A lot of what the run-time engine adds to the system are in fact secondary things such as multi language support for it's dialogs and runtime texts, Intel Math Kernal Library, Service Locator, Logos Sybsystem, etc. etc. Most of them not strictly necessary but using some seemingly harmless functionality could already depend on one or more of these.

    Rolf Kalbermatter

  14. QUOTE(crelf @ Feb 24 2008, 06:47 PM)

    You're right - it's not *exactly* what he said, but I don't think it's a large nor unreasonable extrapolation.

    Not sure I can agree to that? When were you last able to put a Windows service pack or KB patch onto a Floppy disk? Or a Macintosh OS bugfix? Or Linux for that matter! Without a fast broadband access keeping up with the state of security fixes on all these systems is simply an impossible thing.

    Ok you could also say without broadband access those security fixes aren't that important. :D But then maybe going with let's say LabVIEW 6.1 instead of 8.5 wouldn't be either.

    Rolf Kalbermatter

  15. QUOTE(tcplomp @ Feb 24 2008, 02:54 AM)

    Why does (almost) everybody have such issues with IT?

    I think they should be serving not demanding... :headbang:

    Well, I guess managing IT infrastructure is a rather thankless job. If you do it right nobody notices, but every hickup is made into a big issue immediately. Add to that the extra difficulties that software manufactureres throw into the picture to protect their interests and it gets really difficult.

    As far as acessing the company database is concerned. Imagine someone doing something that shuts down the system somehow. That can be fatal for nowadays interconnected workflow processes so there are of course concerns. My experience in that is that often lower management has this nice idea about how to automate testing or production and asks the programmer if it is possible to connect to the database. Our first technical reaction is what for a system and then, oh well yes of course we just use ODBC, ADO or whatever. Now IT is as the dead about such things. It could potentionally disrupt the whole system and if it does they are the ones that get beaten first.

    So the solution is to get lower management to talk with higher management and convince them that this is a good thing and once they are convinced they will tell IT to make it happen and everything suddenly works smooth. It's politics yes, and we all are technical people for some reason among one of them probably that we don't like politics to much. But you can't beat the system you have to play along with it.

    Rolf Kalbermatter

  16. QUOTE(blueguard @ Feb 4 2008, 10:26 AM)

    I am in my last year in mechanical departement ,and my project is about machine vibration diagnostics and analysis , but i can not pay for an NI DAQ card ,so that i am planning to use the PC soundcard as a data acquisition card , and i do not no to what extend the soundcard is valid for this purpose, especially for multichannel measurements , and how i can interface the sound card to Labview? :question:

    Since you are doing vibration diagnostics one problem of sound cards is probably not that much of a problem for you. Sound card inputs are bascially always DC decoupled meaning they can't measure DC voltages and have a lower bandwith frequency of around 20 HZ.

    Multi channel is often not possible unless you get some more high end type card that sometimes happens to have two IO channels. But still you should be aware of that sound cards are using chips that are selected to produce fair results for audio applications. The human ear is all but an exact measurement device and therefore you can get away with rather bad hardware components without most people noticing to much of a quality degradation. In the PC component industry where every dollar not spent for a product is both a marketing advantage as well as a possibility to make a few cent more profit, this results normally in the cheapest components selected that will just about do for the task at hand (and for some products the quality degradation is definitely noticable even for the human ear).

    So using that hardware for measurements is not likely to produce accurate results. It will be more like guessing than actual measurement. If that is acceptable for your purpose will be something you have to decide for yourself.

    Rolf Kalbermatter

  17. QUOTE(aoshi @ Feb 22 2008, 04:46 PM)

    Hi guys,

    I'm new to LabVIEW. We have a labview 7.1 and the professor wants me to connect the OM-320 with LabVIEW. The OM-320 is a data logger with a Hyperware program to display probe values. Now, he wants me to use LabVIEW to display these probe values ( not the hyperware). Is this possible? The OM-320 uses a RS-232 connection to the computer. How can I use LabVIEW to communicate with the OM-320?

    Please, I really would appreciate your help.

    By using the VISA nodes to communicate over RS-232. Your problem will be probably twofold. First find the documentation for the command set of your device. I have no idea if you got a programmers Manual with your device. This information is usually in such a manual but for end user devices this is either not automatically shipped and sometimes not really available at all up to the point where the manufacturer treats that information as trade secret.

    Next step will be to get acquinted with VISA programming and possibly LabVIEW programming too.

    Rolf Kalbermatter

  18. QUOTE(tcplomp @ Feb 23 2008, 04:38 AM)

    The LabVIEW RTE installer is 32 MB not that bad, a typical app I would mail to a client would just a few MB.

    Yes! If I send an executable to a client I add everything that the executable needs to run, except the runtime engine. I just add a link to the appropriate NI download page for the RTE and tell the client to install that.

    That gives me usually ZIP archives of about 1MB up to 10MB depending on the project size.

    Rolf Kalbermatter

  19. QUOTE(brent99 @ Feb 22 2008, 05:06 PM)

    Yes, the "dead horse" posts are useful because its not just me, which was my question.

    The point isn't that there is an RTE, but that the RTE grew so dramatically from 7.0 to 8.0 with the main feature being a project manager. WTF? (Ok you could blame the new OO support, but then give us the ability to opt-out since its not a heavily used feature, I imagine)

    The project management is specifically not part of the RTE. Almost anything editor related is NOT part of the RTE. The LabVIEW RTE got big because of many new features and also support libraries which could or could not be important for a specific application. The problem is to chose between easo of use: you just create an installer and everything will work normally or requiring the user to have a very detailed knowledge of what he really needs to select as subparts in a build. Many users are already overwhelmed by the choices of extra components to add to an installation in the 8.x Builder. Subdividing the RTE in one dozen or more sub packages wouldn't make that simpler for sure.

    Whoever has created Windows Embedded projects knows probably what I'm talking about. There you have to decide what components you want to put in an installer and if you got it wrong the target system simply won't start, sometimes issuing a useful error message but quite often not.

    QUOTE

    Although, speaking of large RTE, uhmm, isn't Labview compiled to machine language? Its NOT Java running byte code. Is it?

    Well, the actual diagram (such as all the structures like loops, cases, etc as well as the actual wiring of data between nodes) is compiled into machine code of course but not every node is compiled into machine code on the fly and added into the VI itself.

    Most little yellow nodes are in fact function calls into the LabVIEW kernel or RTE. Also there is a lot of code necessary to draw the front panel, schedule execution of all the VIs and many more things like support for interfacing to VISA, Bluetooth, TCP/IP, etc. These things do not get added into the executable itself as that would be both a huge task to prepare a linker system that could link these together properly for the specific target system into an executable as well as a waste of storage space since each executable would contain the same code over and over again.

    Rolf Kalbermatter

  20. QUOTE(brent99 @ Feb 22 2008, 05:08 PM)

    I saw that, and just assumed that Labview IS written in QT (at least as of v6.0 or so). No?

    No definitely not! The entire UI widgets have been written for LabVIEW 3.0 from scratch based on the drect windowing API of the spcific platform (X11,Windows GDI and Mac OS QD) and that hasn't changed at all until now. The only real modification was with the adding of the 3D types of controls in LabVIEW 6, but they are based on the same proprietary object model that is used for the other built in LabVIEW widgets.

    QT appearently only is used for the Multiple Variable Editor that is part of the LabVIEW Data Logging and Supervisory Toolkit, but since the LabVIEW installations contains that anyhow (but the according license is necessary to enable that functionality) it comes with every standard LabVIEW installation and since it is in the executable directory, Windows will always prefer to load those libraries if some component such as the SCC API provider for said system needs to load those libraries with that specific same name.

    Rolf Kalbermatter

  21. QUOTE(orko @ Feb 21 2008, 01:00 PM)

    Or use that forgotten little icon in your National Instruments start menu: NI Spy (only works if your COMM port programs are written in LV)

    No! This really works for any program that uses VISA to communicate with the port (serial, GPIB, and whatever). NI Spy in fact simply intercepts all VISA API calls and monitors them. Of course standard Windows applciations using directly the Windows Comm API can't be monitored in that way.

    Rolf KAlbermatter

  22. QUOTE(Khodarev @ Feb 7 2008, 07:35 PM)

    I wonder what is Xmit and how to use it?

    Anyway for now i've settled down with software splitter (Serial Splitter from Eltima). It seems to do the trick. The only problem is that i have to reconfigure that "other" application so it will use virtual port that Serial Splitter creates. It's not such a big deal but still it is not flawless victory:)

    Xmit is sometimes the name of the transmit line on the serial port.

    Rolf Kalbermatter

  23. QUOTE(psufleish23 @ Feb 21 2008, 03:40 PM)

    I need to be able to communicate data between LabVIEW and another program. We need LV to write to a file (e.g. *.txt.) about 1x per second (only writing about 10-20 string controls) and the other software reads it at about 20x-60x per second. The data in this file will be read by the 3rd party software. The 3rd party software will only be reading, LV will be doing all of the writing. The method that the 3rd party software company proposed (since they had worked with it before) is memory mapping, or mapping the file to memory. Has anybody had any success in doing this before? I am trying to rework some code posted before @ NI Developer Forums. I am also using MSDN to get all of the function calls.

    The main problem I am having is how am I able to read back the data? I thought I was close, but based on the code attached, it didn't return anything. Also, does the filemapping update when the referenced file is changed? Or will I need to read and write through through the memory mapping?

    Here is the MSDN site for . I'm really stuck on implementing the code in this .

    -Aaron

    Note: I've been asked about using TCP/IP to send the data. The above method was suggested by the 3rd party company.

    File mapping should work for use as shared mamory in theory and did so in the past for me but: no, if you update the file instead of a mapped pointer to the file I don't think this is gonna work.

    Also you should not try to copy the name string for the MapFile but instead the returned pointer from MapViewToFile. Another suggestion would be to use UnmapViewFromFile and CloseHandle afterwards to properly close of all resources.

    Also as has been explained on the page you linked to access to mappedFiles can generate exceptions. LabVIEW has an exception handler around Call Library Nodes but that will popup an user error dialog. To handle those exceptions yourself you will have to create an external DLL as custom exception handling is not supported by LabVIEW.

    I would say go for UDP/TCP instead. Much more robust, remote capability built in and easy to do in LabVIEW.

    Rolf Kalbermatter

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.