Search the Community

Background: I've been using LabVIEW for a few years for automation testing tasks and until recently have been saving my data to "[DescriptorA]\[DescriptorB]\[test_info].csv" files. A few months ago, a friend turned me on to the concept of relational databases, I've been really impressed by their response times and am reworking my code and following the examples with the Database Connectivity Toolkit (DCT) to use "[test_info].mdb" with my provider being a Microsoft jet oldb database. However, I'm beginning to see the limitations of the DCT namely: No support for auto-incrementing primary keys No support for foreign keys Difficult to program stored procedures and I'm sure a few more that I don't know yet. Now I've switched over to architecting my database in MySQL Workbench. Suffice to say I'm a bit out of my depth and have a few questions that I haven't seen covered in tutorials Questions (General): Using Microsoft jet oldb I made a connection string "Data Source= C:\[Database]\[databasename.mdb]" in a .UDL file. However, the examples I've seen for connecting to MySQL databases use IP addresses and ports. Is a MySQL database still a file? If not, how do I put it on my networked server \\[servername\Database\[file]? If so, what file extensions exist for databases and what is the implication of each extension? I know of .mdb, but are there others I could/should be using (such as .csv's vs .txt's) My peers, who have more work experience than me but no experience with databases, espouse a 2GB limit on all files (I believe from the era of FAT16 disks). My current oldb database is about 200mB in size so 2GB will likely never happen, but I'm curious: Do file size limits still apply to database files? If so, how does one have the giant databases that support major websites? Questions (LabVIEW Specific): I can install my [MainTestingVi.exe], which accesses the jet oldb database, on a Windows 10 computer that is fresh out of the box. When I switch over to having a MySQL database, are there any additional tools that I'll need to install as well?

Bonjour, I use Labview 2015 32-bit on a 64-bit Win& pro computer. My application connects to Hardware using NI-VISA and NI-DAQmx only (Two RS232 communications via a VCOM port and one NI DIO card using DAQmx). Until today, I was building an executable which I was copying through the network on another win7 pro machine in the lab next to the hardware. It was working fine with Labview Runtime 2015 installed on this machine along with NI-VISA and NI-DAQmx. I never used an installer, I installed those 3 components seperatly. Yesterday I added some features to the application and the EXE won't start. I have an error msg saying "The VI is not executable. The full version of Labview is needed to fix errors". The machine in the lab can't run the EXE but the EXE won't even start on my development machine. My previous EXE from last week still works fine. The code works fine with all new features if I run the main VI from the development environment. I've double check all of my licences status. If I open another project and compile the EXE, I am able to run this EXE (I use a complex app containing almost all the same software components) If I build an EXE with a different UI source file part of the same project, that EXE works fine. If I build the EXE from my previous version again, it works fine too. I tried removing all the new features I had added in the project and build the EXE again and I still get the error. I tried creating a new project file and import the same librairies to try building an EXE from a fresh project file and I still get the error. I tried installing Labview 2015 on another computer and try to build an exe from a fresh labview install on this computer and I get the same error. The development machine can't execute the compiled EXE) It has to be related to the code but, I can't roll-back and get functionality of the EXE again unless I totally replace all of my files from a backup made last month. The most recent posts I read from a similar error are from 2013 and later. And the problem described is always that the EXE does not work on the deployment machine but works fine on the development machine. I must be at version 25 of this application to which I add improvements on a regular basis since almost 1 year. I am really puzzled. Is there a way to analyse or get more info about the broken EXE error? All the new features I added are using components that were already present in the project and in the main VI. The new features are important, I'd really like to use this working code with the hardware as soon as possible but I don't really want to install labview on the development machine. Any ideas? I don't know what to try next. What would be the best information to provide / look for for the next step? Thanks to all in advance Nien

Hi, I would like to associate icons with file types that are handled by a LabVIEW built application. To do so, "defaultIcon" key has to take a value of executable path with parameter "resource ID". The question is how to build in more than one icon with executable? Examples of LabVIEW keys: -library: ..\LabVIEW.exe,-8 -llb: ..\LabVIEW.exe,-3 Is it even possible with app builder? Any workaround?

Hi to all, I'm able to see a SubVI front panel in a Main front panel using a SubVI object and inserting it into the object. I have been wondering if I can do the same launching an executable file and looking its user interface inside a main executable, both built using the LabView application builder. Have you ever done a work like this? Have you an idea to advise me, that can help me? Thank you all

I'm trying to find a way to communicate between two executable LabView app, because of several reasons I chose (associated with my application) Network Streams. Everything works fine so long as they are the VIs. When I build exe files there is no communication between apps. The apps waits forever for connection (because there is no timeout). Did anybody meet the same problem? I will be very grateful for any advices and comments. TestStream.vi TestStream2.vi

Hi all, I'd appreciate some advise or pointing in the right direction regarding building an EXE with class dependencies. I have a project built with actor framework and when I build it to exe, I get lots of dependencies which I think should be included in the EXE as seen below: On my Source files build properties page I currently have nothing under Always Included. I did try including all of the lvlibs and including them in the EXE but it didn't make a difference. In summary, I think the way my EXEs are building is not right. It is easy to see what VIs I'm using (although you can't open them) and it doesn't look very professional. What are the best practices for building dependencies into EXE? Thanks

Hi everyone, I posted this over in the NI forums as well, but maybe I'll have more luck over here. I just ran into an issue this morning after building an executable version of my program, which uses the Actor Framework. It contains a .NET control (version 3.5) on one of my front panels. There's a function that I call to pass some XML strings to the control, which then handles filling in the data. This works just as expected in the development environment, but when I build an executable and run that, the control just sits there without being properly filled in. I attached an error indicator to the invoke node, which is showing me this error: Error calling method InstrumentDataGridView.InstrumentDataGridView.LabVIEW_FillTableFromXML, (System.ArgumentNullException: Key cannot be null.Parameter name: key) <append><b>System.ArgumentNullException</b> in Experiment UI.lvlib:Experiment UI Panel.lvclass:Actor Core.vi:1->Actor Framework.lvlib:Actor.lvclass:Actor.vi:4->Actor Framework.lvlib:Actor.lvclass:Actor.vi.ACBRProxyCaller.D140000E I then ran DebugView to get some more detailed information on what was happening and here's the log that it spit out: 00000006 80.98936462 [3404] Created new AppDomain: ICAS-EPR.exe for Reflection 00000007 82.80818939 [3404] Created new AppDomain: ICAS-EPR.exe for Run 00000008 85.75064087 [3404] DNError: Error calling method InstrumentDataGridView.InstrumentDataGridView.LabVIEW_NotifyAcquisitionStopped (1172). System.ArgumentNullException: Key cannot be null. 00000009 85.75064087 [3404] Parameter name: key 00000010 85.75064087 [3404] at System.Collections.Hashtable.get_Item(Object key) 00000011 85.75064087 [3404] at NationalInstruments.LabVIEW.SyncInvokeTable.LookupControl(Object key) 00000012 85.75064087 [3404] at NationalInstruments.LabVIEW.DNRuntime.InvokeMethod(Int32 invokeType, Type type, ObjectId objectId, String methodName, Type[] parameterTypes, Int32[] parameterFlags, ObjectId[]& parameterIds) 00000013 85.75064087 [3404] 00000014 114.37963104 [3404] DNError: Error calling method InstrumentDataGridView.InstrumentDataGridView.LabVIEW_FillTableFromXML (1172). System.ArgumentNullException: Key cannot be null. 00000015 114.37963104 [3404] Parameter name: key 00000016 114.37963104 [3404] at System.Collections.Hashtable.get_Item(Object key) 00000017 114.37963104 [3404] at NationalInstruments.LabVIEW.SyncInvokeTable.LookupControl(Object key) 00000018 114.37963104 [3404] at NationalInstruments.LabVIEW.DNRuntime.InvokeMethod(Int32 invokeType, Type type, ObjectId objectId, String methodName, Type[] parameterTypes, Int32[] parameterFlags, ObjectId[]& parameterIds) 00000019 114.37963104 [3404] 00000020 133.64822388 [3404] Destroying AppDomain: ICAS-EPR.exe for Reflection 00000021 133.68054199 [3404] Destroying AppDomain: ICAS-EPR.exe for Run As you can see, I get a "System.ArgumentNullException: Key cannot be null." error when calling both LabVIEW_NotifyAcquisitionStopped and LabVIEW_FillTableFromXML. Neither of these functions throw that type of exception. I thought that maybe the constructor wasn't being called, but I added some code to the constructor to write to a file and that functioned as expected. Then I wrote a new function that wrote to a file and called that when the VI loaded. That function worked fine and didn't throw any errors. I am completely stumped as to why this is happening. Both the development environment and the executable use the exact same DLL code. I appreciate any help I can get!

I have a built *.exe which I wrote myself two years ago but for which I have since lost the source VI. Said original VI was small so that I could write it anew, but am hoping for a lazier way. I'd like (if that's possible) to just un-build that foo.exe so as to get the original foo.vi if that is possible. I was thinking to put it in the public domain once I do. How I losts the VI is that between then and now I'd got a PC upgrade at work and must have neglected to copy that over (it not being an official work project). What the little program does is only some math. I have attached it as a ZIP. It's a conveninece util for doing trig on bit map pictures. Say you know the size of one item in the picture, You enter that. You also enter the X,Y pairs, end-to-end for that item. Then to know the size of any other item in the same pic (only approximate because of ignoring the camera's parallax) you enter another set of X,Y pairs and violla, it does the trig. Very handy for guestimating proportions so as to create 3D models from photographs of real-world objects. I didn't have LabVIEW on my home PC so I built this up at work, but in a directory not where I keep my work-related LabVIEW projects. And hence I forgot to copy it over when I got the new PC. Virtual Calipers.zip

Have a look to this brand new toolkit for LabVIEW if you are interested to distribute LabVIEW executable with advanced licensing, automatic update capabilities and a lot more amazing features. BLT for LabVIEW (Building, Licensing and Tracking) http://sine.ni.com/nips/cds/view/p/lang/en/nid/211731 BLT for LabVIEW is a stand-alone program you can use to distribute LabVIEW applications for commercial use in a few clicks. License your own LabVIEW application in a few clicks - no coding required Automatically (and remotely) update your applications when you make changes in your LabVIEW code Automate the build process for your LabVIEW executables Get user activity reports and error logs so you can remotely debug your program Use BLT scripting to remotely execute actions on a deployed computer, e.g., update LabVIEW RT Engine Disable parts of your code with features definitions

Hi All, This is my first post on LAVA, so here it goes: I am creating an application that involves reading data on two RS-422 serial ports. Everything was going just dandy until it was time to build my application into an executable. I've spent time debugging my issue and have been able to narror down where the source of the error is coming from, but I can't figure out why it's happening or how to fixt it. I created a simple VI that clearly demonstrates the error. The VI first configures two serial ports using VISA. It then gets the number of bytes at the port and reads from VISA resource in a loop. Finally the resource refs are closed. Before building into an executable (development mode), everything works fine. When I build this single VI into an executable, there are errors anywhere there is an Instr Propert Node. The error code is -1073807246 (which I can't find anywhere). Does anyone know why I'm having this issue? Is this some sort of dependency issue? Maybe I'm not really including some VISA functions in my dependenices? Serial Read.vi

I have been asked to implement some sort of online/integrated help system into my executable. I have not done anything like this before. (In the past I have just written word docs and published them on the internal network) I was wondering what the best practices were for doing this. A few ideas I had were: Building .chm files and then linking them to controls and menus in my application. (not sure exactly how to do this). Using tip strips to supply documentation. Using a pane on the window to display help messages when requested or when hovering over certain controls. Linking to a Wiki on the corporate network. I would prefer a solution that was mainly 'on demand' so advanced users would not be bothered by obtrusive help messages. Have you implemented built-in help? What worked best for you? Thanks for your ideas! -John

I had a big long explanation typed up and accidentally it the back button. I don't fee like re-typing the whole thing so here's the shorter version. I have a reentrant VI that is launched multiple times. In development you can open a reference to the VI by full path, but in an EXE the path is unknown. So you open the VI reference by name, but for this to work the VI needs to be in memory. So attached is one technique I've seen to keep a VI in memory by putting it in a case that will never be executed. Just run the Main.vi click Make New Graph Window and stop when you are done. This code will work when built into an EXE because nothing is opened by path. Is this the right way, or are there other ways to force the compiler to add a VI as a dependency, so that a new reference can be opened by name? Reentrant Reference Test.zip

I have an application that has two nodes. One is a windows node and the other runs on a cRIO. There is alot of shared code but also code that will run base on the OS conditional disable. The customer now wants to create a training system so that they can train their employees on the system in the office. They do not want to have a a controller with every training system so we need to run both apps on a windows machine. The problem is we to build the rt code as a windows runnable executable with the OS==VxWorks condition. When I change the OS condition to VxWorks under the My Computer target it changes itself back to win. Does anyone have any suggestions on how to do this?

I want to make an exe application from a .vi to install on another non-labview-installed machine (I want to use the runtime engine). The only problem I can foresee is that I built the software on a version of Labview that has all the add-ons, and I don't know which ones I have used. I want to know if there's a way to identify which add-ons or national instruments programs have to be installed in order for my exe to work. I know I used IMAQ and IMAQdx, and many of the programmer functions such as case statements, but there's probably more I don't know about. Sorry I can't attach the vi, it's potentially going to be sold in the future. Thanks for any help you can offer, James