Jump to content

xtal

Members
  • Posts

    131
  • Joined

  • Last visited

Everything posted by xtal

  1. Yes, I can see how y'all can get confused by my avatar, but trust me, Happy Bunny is definitely NOT a jackrabbit. And you should also be relieved that I removed the caption that came with that glyph -- it probably wouldn't be allowed with the current guidelines.
  2. QUOTE(Michael_Aivaliotis @ Apr 30 2007, 02:40 AM) Ummm, thanks for the ummm...help. There are so many comments I would love to make, but I will refrain.
  3. Another option that the folks I work with do is to have the .NET forms open in a .NET container in LV and to pass the data through methods/properties or shared variables (depending upon how the data is acquired and published).
  4. QUOTE(REM1 @ Apr 4 2007, 04:24 PM) Cool, more things to look forward to when I return to Austin. And it looks like I've not gone completely senile yet. Thanks for validating my recollection.
  5. QUOTE(yen @ Apr 4 2007, 03:04 PM) I don't know for sure, but I'm guessing it's by design. When I inherited that toolkit, I was told it was finished and I just had to write the docs, release it, and support it. Of course, there were some things that I had to change here and there, but I tried not to change the fundamental design of the toolkit at the last minute. I figured I could always change the error handling a little when I updated the toolkit to the next version.
  6. I can only talk about the NI Days/Technical Symposia events in the US because those are the only ones I've attended. These events usually last all day ~8-4 and their content can vary quite a bit. Usually, these events are defined by the local sales force and they judge by the customers they invite the ratio between new and experienced users and choose topics and presenters accordingly. The seminars with the most technical content are the LabVIEW Developer Education Days where the presenters are mainly R&D folks giving NIWeek presentations or similar technical discussions. The NI Days/Technical Symposia usually contain a fair amount of marketing material on new products, new markets, or new application areas. Usually, there are generic keynote and wrap-up presentations that are more marketing focused but the sessions usually have at least two tracks - new users (hands-on) and technical. I recommend contacting your local NI sales people and discussing these events with them. They can either steer you to the events that better meet your needs or possibly tailor the content/presenter for the next event accordingly. Of course, I highly recommend attending NIWeek. Here is where you'll get the most technical content from NI, the best customers, and Alliance partners. There are usually 5-6 different tracks such as HW, SW, Adv Techniques, New Technologies, Hands-On, etc. This is where Jim and Michael are presenting (and many others) and it will be well worth the price.
  7. QUOTE(REM1 @ Apr 3 2007, 08:58 PM) I thought Citadel had an ODBC interface and any app that can communicate through ODBC (such as the Database Toolkit) could retrieve data from Citadel. Is this not true?
  8. Late March - early April is bluebonnet season. It's a lovely time to be in the Texas hill country and it should be warm but not hot yet.
  9. QUOTE(yen @ Mar 5 2007, 02:55 PM) Actually, I can answer the questions about the Insert Data VI because I was the owner of that toolkit when I was in LV R&D. It does handle it's own memory and does not leave references open. However, if you look at that VI, there is a Boolean input called create table. If you wire a True to that input, about 6 or so levels down in the resulting code lives a CIN that does have a memory leak. The solution is to make sure that input is False and you make sure the table is created ahead of time. I actually looked for this when I first saw your screen captures and it is indeed left as False. So that isn't the source of the memory leak. However, as I mentioned before, I do remember there being a leak in one of the drivers for SQL Server or in MDAC. That's why I recommended you use the ODBC driver temporarily to see if the driver has the leak; that's how I found/verified the leak originally. You shouldn't have to change your code other than to wire in a string DSN instead of the file path to the UDL in the Open Connection VI. And yes, sigh, I know the MS site is really difficult to navigate. The version of the service doesn't have any relationship to the version of the driver. I don't currently have my SQL Server installed or I'd tell you how to find it. Maybe some kind soul at NI will look in the CAR database and see what version of the driver had the leak and make a recommendation. {hint, hint}
  10. QUOTE(TiT @ Mar 2 2007, 05:04 PM) I knew the Database Connectivity Toolkit was current because there's only one version. {By the way, when you say SQL Toolkit, it makes me think you are using the old toolkit obsoleted 5 years ago; so I was confused until you included the screen captures.} In this case I do think there is a driver issue. Please keep me updated and I'd be happy to look into this further if you still have problems and can send me your code.
  11. QUOTE(TiT @ Mar 2 2007, 10:59 AM) Typically, that's how I write my database applications - open the connection at the beginning, write and read as needed, close once at the end. Another place to look is related to the driver you are using to communicate with the database. It appears you are using a UDL file to connect. For a quick check, you can change the drivers by using ODBC for the connection and see if that changes the memory usage. Normally, I don't recommend you use ODBC, but this is just a test to see if the driver has a memory leak. Otherwise, I'd make sure you had the most recent drivers for SQL Server. I remember an issue about a year or two ago where the MS driver had a memory leak and updating the version fixed the problem. You didn't mention what version of the drivers or MSSQL you are using. Otherwise, I don't see anything in your code that stands out as a problem.
  12. When I was at NI and responsible for the Database Connectivity Toolkit, I did test it with dBase and DBF files. Everything worked fine and if there were any problems connecting, they weren't significant enough for me to remember or write down. I actually used dBase in some of my presentations because all the shipping examples worked with Access and I liked showing other database management systems for contrast. I'm sorry I don't remember more, but you can be assured the toolkit works with dBase files. I know it's old technology and I usually don't recommend it, but try ODBC to connect instead of the Microsoft Data Link. This might bypass some of the MS drivers and possibly some of the ISAM business Herbert mentions.
  13. Why don't you use the Execute Query VI and create the tables with the sizes you want from the beginning? For example, if you input the following string into the Execute Query: create table mytable (field1 text(255), field2 datetime, field3 text(255), field4 byte); would create a table named mytable with four fields where both text fields are set to 255 characters. The top-level database VIs are meant for very easy storing and access of data. Once you start changing things like field sizes and other things, you should start using the advanced VIs.
  14. Yup, no worries. I do have a good sense of humor and since Mike and I know each other personally, I'd give him the benefit of the doubt even if he said something questionable BTW, you should still envy my job because it's even better now.
  15. I guess I should have had a qualifier on my statement that LabVIEW doesn't scale well to larger projects and more developers. That qualifier is that LabVIEW code written by people who aren't educated in LV development, don't understand software engineering principles, and only write ad-hoc programs doesn't scale well. Nor is it easy to start using those principles on LV code written that way once you've seen the error or your ways or once you start thinking more abstractly. No, it's not the environment's fault; and I would argue that I love LabVIEW as much as both Mike and Jim. However, even with all the design patterns, SCC integration, and the project, it's not inherently obvious how those tools can be used in LV if you've only ever programmed in C# or nothing at all. And, quite frankly, I've found that there are some serious compatibility issues between VSS and the LV SCC features that never existed when I used Perforce. This makes the LV environment look kludgy and inconsistent for the C# developers. And seriously, Jim and Mike, how can you say that scripting released as it is could really benefit all these people? I'm talking about the people who are the average software writers...not you who are not only LV enthusiasts, but are also the folks who "get it" when it comes to software engineering. I agree that if you are doing serious development work with LabVIEW and are writing utilities and applications that require flexibility and adaptability, you absolutely need many of the scripting features. However, I had full access to scripting for many years and there were just enough rusty nails or not-fully-functional or not-well-designed parts that I could't use a lot of it. I had to hack quite a bit of code to work around some of these limitations to the point where I probably shouldn't have even tried to use scripting. Scripting certainly didn't make me a better software engineer nor did it really help me understand LV any better, it just made it easier to crash in unexpected ways or otherwise get my LV into a very bad state. However, I'm not completely disagreeing with you. I think it's essential for NI to release LV scripting to power users such as yourselves (and me) in order to see what products/utilities can be made, what parts of scripting need enhancement, and how to properly package it when it is ready to be released to the general public. So I think the best way to solve some of the general problems discussed is to just try and educate people as much as possible. And just as I said, Jim, your book is prominently displayed in my office and available to all these people as a reference. It's just that they are now so negative about LV that they won't listen to me and only make fun of all the LV items I have. Nor will they believe that proper initial SW design saves time and makes for more robust code in the long run. I just need to set the example and let my code speak for itself just as y'all have done for many years.
  16. Well, this is certainly a good discussion that directly applies to my current situation. And it appears that I've inherited the worst of both worlds. I agree completely with DannyT that LV doesn't scale well when you start adding developers and complexity to a project. My current workplace started out as one guy building the SW and HW. He chose LV and was very successful. Then he retired and was replaced with a couple of new people. They didn't get formal training on LV and when they modified the code or wrote their own, things got out of control. Fast forward five more years to when I join the team. Now each project gets an EE, ME, and Process Engineer. I am one of eight EEs on the team. The EEs are responsible for all the electrical components and all the software. The existing LV code is similar to the 9-screen program that Stephen describes - and add thousands of locals, globals, and ...now in LV 8.x, shared variables. The LV code isn't modular, isn't able to be easily modified by groups of people, and as a result, the entire group has decided to get rid of LV as a development environment and move everyone to C#. Most of the new hires already know C# and are successful in their projects quicker than they are able to write LV code. I'd love to refactor all the existing LV code and show everyone that LV can be used as a proper SW Engineering tool. Unfortunately, all the existing code is FDA-regulated and revalidation is extremely slow and resource-intensive. I have no problems communicating with the other EEs when we talk about SW architecture and class organization and modular test and valiadation procedures, but we just have different preferred development environments. My opinion is that it doesn't matter what your educational background is (EE, CS, whatever) or your current job title (SW Engineer, EE, ME, etc.), some people understand the modularization of SW and its integration with the HW and others are more short-sighted. Some people *get* LabVIEW and how to use it modularly and others don't. In the end, it's just about different tools and who is more efficient with what. {back to reading my Learning C# book}
  17. NI also offers a LabVIEW Instrument Control course (you can buy just the manual/software separately for self-paced learning) that describes the different communication/driver types such as VISA, GPIB, IVI, etc. and has many exercises to get comfortable with each.
  18. Great post, Stephen! My next laptop is going to be a Mac, too. It might be a few years, but that's where I'm headed.
  19. I also thought my new 3200 x 1100 was the coolest until I saw this. I'm certainly not complaining, though. I have lots and lots of room for my diagrams and panels now...and the 10 other apps I might need to run.
  20. My current company recently just switched from Win2000 to WinXP and have absolutely no plans to switch to Vista for a long time. When I did some beta Vista testing at NI, there were lots of installer, registry, and permission problems. Enough issues that I'm happy I won't be using it anytime soon.
  21. xtal

    Hallo LAVA

    Hi, Herbert! It's nice to see you here at LAVA. Welcome! Crystal
  22. Also, I want to double-check what datatypes you are expecting in the database before I give any advice. Could you describe the tablename, fieldname, and field type? Thanks
  23. Congrats! Don't feel bad about just getting certified now. I've got to start from scratch and I've been using LV since version 1.2 and was even on the development team for 6 years. I'll have to see what my new job requires, but I'm hoping it will make sense for me to get the certifications. Crystal
  24. xtal

    Hello

    Be careful! Just because it's easy and fast to throw everything into a diagram, doesn't mean you can ignore all previous training in structured programming. Programs in LabVIEW have to be architected and designed in a modular way so they are maintainable and readable in the future. I've had to debug too many large applications that used no subVIs and were a giant mess of wires going everywhere (spaghetti code). Start thinking modularly now before you adopt any bad habits.
  25. Yes, the example Andy shows is exactly how we used the subpanel in the Preferences Dialog. We use the listbox/subpanel plug-in architecture for a number of things in LabVIEW. The Library Properties Dialog is similar and contains different pages whether you have a normal project library or are using a special type of library like a class. The VI Analyzer uses a similar method to load all tests and display the individual configuration parameteres for each test.
×
×
  • Create New...

Important Information

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