Karl Rony

Here is a demo vi in LabVIEW 8.2.1

I'll try and put something together this weekend for you.

One of the licensing options is one developer license and unlimited runtime licenses on any system anywhere in the world.

Check out this earlier forum entry and see if it helps.

http://forums.lavag.org/Store-a-blob-of-da...tml&p=12890

I am working on an application to simulate eight pieces of plant equipment. I've started down the path of traditional VIs and controls as I'm most comfortable with this approach. The simulated equipment has a simple user interface of number, enumerations, and Boolean lights. OOP could work, but I've haven't worked with LVOOP yet. An XControl could work and I've programmed one of these before.

If I were to experiment with another approach other than traditional VIs, should I learn more about XControls? Would I be better off learning LVOOP instead of XControls?

Thanks for your help,

Karl

I use Win2PDF (www.daneprairie.com). The $35 dollar program allows one to control the filename and other properties by writing to the registry.

I'm using Vista Home Premium with LabVIEW 8.2.1 and 8.5.1. I can get 8.5.1 to crash every once and a while, but I'm not sure who to blame - Microsoft or NI. I'm not thrilled with how fast Vista runs, but it has enough nice features to keep me from trying to downgrade to XP. I remember the days when I thought Win2000 was great and I wasn't sure about upgrading to XP.

I was also pleased to read the news. I've also helped a local school with First Lego League using the NXT. Using the NI hardware is something that I can get excited about for the High School.

I've also worked with XML before - very powerful, but not pleasant to work with. With your reputation and offering such a low introductory price, I couldn't resist buying it by simply looking at the page http://jkisoft.com/easyxml. I look forward to trying it out someday soon. Thanks for creating the product!

I use SnagIt for screen captures, it is probably the premier Windows product for capturing all or parts of a MS Windows screen. SnagIt allows you to create capture profiles tailored to your needs. You can then assign a hot key combination to trigger the capture. If you can figure out a way to send keystrokes to trigger the capture from LabVIEW, this might work for you.

QUOTE(i2dx @ Jan 11 2008, 05:09 AM)

I had the same problem almost a year ago. I also tried (hard) to get comfortable with Perforce but finally I decided that Perforce is not suitable for me and removed it from my disks .... that was the nice version: In fact I am convinced that Perforce is just crap. I've never used a piece of software that made me more headaches than this one! This "workspace and change-list stuff" really drove me crazy.

The sad thing is, that VSS has no trial version, so what I do now is: use some (self written scripts) which retrieve my LabVIEW work directory once a day, and make a backup. Maybe this solution is not that secure but it is comfortable and at least I have "some" security. I decided to write my own SCC for LV, but this project is idle until I have more time - which will probably happen not before 2056

Maybe you want to check out CVS/SVN but I - for my part - am to lazy to set up a linux server and get it running - sorry, but I have still to much work

I went with SourceGear's Vault at www.sourcegear.com. I tried Perforce but decided against it. It is far more powerful and complicated than I need. My brother switched from VSS to Vault for his company. I trust his judgement and he can help me when I have problems. I'm new to version control integrated in LabVIEW and I haven't worked too much with it yet.

Although Peforce offers a 2 user license for free, the product was $800 per user when I looked. SourceGear offers one user license for free and licenses is $250 per user. I also like the SourceGear owner's blog at software.ericsink.com.

Vault runs in the MS world with in a MS SQL database. It works with MS SQL Express or the MS SQL 2005. I prefer to stay in the Microsoft world as well.

If I recall, I think I had trouble integrating an earlier version of Vault with LabVIEW 8.2.1 on MS Vista. LabVIEW didn't recognize the SCC provider. I have no trouble with LabVIEW 8.5 on MS Vista with the latest Vault version.

The SQL Native Client ODBC driver for MS SQL Server/Express is extremely fast compared to the SQL Server ODBC driver. Perhaps the MySQL ODBC driver is not fast either.

QUOTE(eaolson @ Oct 16 2007, 01:36 PM)

I've seen a few people here and there talk about LabVIEW and how it could become a general purpose programming language. With some spare time on my hands, I was thinking about that the other day and started to wonder what LabVIEW would need to do to actually become such a language Similarly, but more importantly, what will it take for LabVIEW to be viewed by non-wireworkers as a "real" programming language?

I also think it would be great if LabVIEW moved out of its niche. I find it interesting that LabVIEW is used at one end of the spectrum for industrial and technical applications and at the other, very non-technical end, for Mindstorms NXT. But there's not much in the middle. I was actually thinking LabVIEW might make a good to teach beginning programming; it's fairly intuitive, comprehensive GUI widgets are built right in, and the danger of obscure compiler errors is minimal to none.

1. Cost. I hate to be gauche, but this is an important issue. I'm looking for a job now and I've come to realize that, if my job doesn't require me to use LabVIEW, I probably will have to give it up. We have a site license, and I'll lose access to that when I leave. I might pick up the Student Edition or something, but $5000 for a programming language? I'll switch back to VC++ or Java for stuff I fiddle with at home.

2. By reference objects

There is just a lot you can do with obkect references that you just can't do with a by-value object. I know it's not exactly fair to be making this complaint when LabVIEW just got by-value objects not long ago. I just think it would go a long way toward LabVIEW being considered a "real" programming language.

3. Better bug support

Don't get me wrong, as these things go, NI's dedication to support is fantastic. I wish more companies did half as good a job. And the new Known Issues page and he listing of CARs in the release notes are great.

It just seems to me that a major version is released, we get a bugfix version a few months later, then all support for that version ends. I don't like feeling pressured to upgrade every six months or so, just to avoid bugs that crash LabVIEW to the desktop. Especially because each new version introduces bugs of its own. Right now, my main project is locked into 8.20 because I need to remain compatible with a colleague at a different location. I found a crash bug just the other day, reported it, but it's fixed in 8.5, so I'm out of luck.

It seems that NI favors the software-as-service paradigm and I understand why that's good for them. As a user, I disike it. It requires me to be dependent on an external factor I have little control over.

4. Executables. It's odd that the whole point of pretty much every other language out there is to create executables that run on non-development machines, but doing the same for LabVIEW requires a $1000 add-on. It makes it difficult to distribute what you've written to non-developers and I suspect that hampers the spread of LabVIEW.

Maybe none of this is important and the people that need to know about LabVIEW already know. Maybe NI is content with LabVIEW's niche-ness. Maybe I've just been drinking the LabVIEW Kool-Aid too much and need to get a life, but I'd like to hear what other people think.

(What's the best forum for this? It's not really technical and just me bloviating, so I'm sticking it in the Lounge, even though it is LabVIEW related.)

I just created my first NI installer a week ago and I was also bothered by the frustrations of adding the additional install components. When it comes to building a product, one should have a controlled build environment in which the build environment can be reproduced at a later point in time for small revisions or upgrades. The discussions about unloading and reloading files then hoping the build works is risky.

My recommendation and the path I will take is to use a VMWare Workstation image to build the product. I'll load whatever software and drivers that are necessary to build the product and then I'll create a snapshot. As long as I keep the snapshot, I can come back in the future and start with the same environment as the original. I already use VMWare snapshots for install testing with different initial conditions.

I experimented with LabVIEW's OPC client capabilities with LabVIEW 7.1 using datasockets. My first concern was LabVIEW's recommendation to use the 6.x VIs for OPC client applications. I also had trouble with reliable communications without a 2 second delay between operations.

I wasn't performing the operations very efficiently and pondered the thought of spending a 2+ weeks rewriting and enhancing my code. Instead, I tried out OPCWare and had a nice solution in under 4 hours. I purchased the software that afternoon and never looked back. The OPCWare product has a nice COM runtime interface that allowed me to manipulate the tags in the LabVIEW application as I troubleshooted my development.

One of my LabVIEW / OPCWare application was a small application to open and close a Profibus-DP controlled actuator. A host computer had a Softing Profibus PCI master and the Softing OPC server. I configured tags on the server to support several actuators with a common name structure. By changing the OPCWare XML tag file, I easily ran the same LabVIEW test program independently on several computers controlling separate actuators through the Profibus OPC server.

I am the KR on the web site.

I went with opcware.com as well. I didn't and still don't have the time to spend weeks tweaking a custom built OPC client solution. With OPCWare, I was productive in under a day.

I wasn't pleased with the performance of LabVIEW's standard OPC client capabilities in version 7.1. I didn't want to use the DSC module either. I went with www.opcware.com. I haven't tested LabVIEW 8.2's standard OPC client capabilities yet.

I'm working on a trending application based on the LabVIEW 8.2 example Cont Acq&Graph Voltage - Write Data to File (TDMS).vi. I collect 6 analog channels of data at a rate of 100 samples/second for 45+ minutes. A loop updates the TDMS file to the hard disk every second. It works flawlessly.

Visual Paradigm does look nice (http://www.visual-paradigm.com/product/vpuml/demos/umlsupport/).

I found two Visio Stencils that may make drawing State Diagrams in Visio easier.

http://www.quantum-leaps.com/resources/goodies.htm

http://www.softwarestencils.com/uml/index.html

I'm looking at using the UML editor from www.myeclipseide.com. After briefly experimenting with MyEclipse and MS Visio 2003, I like MyEclipse much better. The price is much less as well. I'm also looking into using LabHSM.

PLCs are great. They don't do much, but they are very reliable. Some brands are inexpensive as well. NI hardware is expensive, but it works great.

Although I like to mix PLCs with NI DAQ cards, a local consultant for my company doesn't. He'll specify and use SCXI and $300 PCI serial cards (if necessary). I can't complain because they tend to be fixed bid jobs and he can't afford to fight with hardware incompatibilities. In the end, the solutions work very nicely.

LabVIEW is great. I really enjoy programming with the language. I can't say the same for some PLC programming languages. PLC programming tends to be much more limiting than LabVIEW programming.

The individual pieces don't tend to be the problem, the integration is the bear. Hardware companies in general don't do too good with software. Don't expect wonders from an OPC server from a PLC vendor. I'm not sure about LabVIEW 8.2, but in the past, the standard LabVIEW OPC client is not very good either.

I use a conservative $100/hour for development and testing labor costs. This will probably be your biggest expense. This number gets higher as you add more components, especially from different vendors.

I've started using the TDMS in version 8.2 for saving data during the run. Currently, I easily log 16 DAQ channels every millisecond for test runs of 45 minutes or more. I tried out the code with a run for over 6 hours.

In the past, my application would trend the data during the run then allow the test operator to analyze the data. Occasionally, something would go wrong and the test operator would loose the data at the end of the run. The UUT needed to cool for 3+ hours before running a test again.

Although I haven't experimented yet, I'm hoping the TDMS file is still usable even if the computer abruptly powered off or locked up during a test.

For USB to RS232 adapters, I've had good luck with Prolific based adapters. I've had terrible luck with FDDI based adapters. All my LabVIEW projects use at least one serial port.

My last laptop purchase was a Toshiba. I could turn the wireless Ethernet on and off with a switch on the side. When I reloaded the OS to start clean, the computer came with a support disk that allowed me to load only the applications that I wanted. I really like these two features.

Recently, two threads asked for assistance on how to store complicated data in a database. One person wanted to store images. Another person wanted to store an array of data. I keep waiting and hoping for a solution because I've tried to do both with the NI DB toolkit / ODBC / Microsoft Access, but I failed. I couldn't figure out how to get the NI DB toolkit to use a memo field as a blob and not a string. I started tinkering with Microsoft ADO, but I had to put it aside.

I don't care how big the database gets nor do I expect to search for values in an array or cluster. I'll have other fields that I can use to narrow my search.

I don't want data stored in files scattered in the Microsoft Windows file system. I'm afraid the data will get lost or moved in the central file server.

I want the information contained in a single database. Eventually, I hope to implement replication. When I want to retrieve data, I'll use the other fields for a query search. Once I find the record I want, I'll use a LabVIEW program to recreate the exact environment that I had when I saved the record.

I'm even more encouraged by the free, express databases such as

SQL Server Express 2005

Oracle 10g Express

IBM DB2 Express

Thanks in advance for any assistance in leading us in the right direction. Maybe one day, I'll solve the problem with ADO and post my solution here.

My company standardized on IBM desktops and laptops with one or no serial ports. The desktops only supply two standard PCI slots and I've filled them up. Thus, I've moved to USB serial adapters.

I stumbled upon www.byterunner.com as a supplier. I've had terrible experiences with the 2 port version based on the FDDI chipset. My LabVIEW application didn't work reliably and neither did my AutomationDirect PLC programming application. However, I am successful with the single port version using the Prolific chipset.

I have interfaced LabVIEW to OPC servers from Automation Direct (PLC) and Softing (Profibus-DP). The Automation Direct logic uses DataSockets. The Softing logic uses an OPC client toolkit from OPCWare (www.opcware.com).

My OPCWare solution is far superior to my DataSockets solution. The OPCWare solution is faster, can change links by loading an XML file, and I easily created a callback Vi that I use to update values on an indicator in another Vi.