Search the Community

I have been getting some hard crashes in my built application and I have some strange feeling (although it's just a guess) that it is related to a combination of using the database toolkit in a pool of workers that are launched by the start async call node. Their job is to sit there and monitor a directory then parse data files and throw their contents at the database through a stored procedure call. All my hardware comms (2 instruments) are using scpi commands through VISA GPIB and TCP so I think the risk that those are causing crashes is relatively low. Active X inside a bunch of parallel threads seems far more risky, even though as far as I can tell adodb should be thread safe, and each thread manages its own, unshared connection. These crashes are happening ~once a day on multiple test stations. I have sent the crash dumps to NI but am waiting to hear back. Right now I am grasping at straws because when I look at the dump file it's pointing me to function calls in the lvrt dll which does nothing for me. I am mostly just looking for any debugging suggestions or direction to getting this resolved more efficiently than just disabling code one loop at a time. I'm also curious if anyone has seen something similar. For the time being, I have reduced my number of workers to 1 in case it is a thread safety issue. I have also considered getting rid of that DB toolkit and leveraging .NET, even though I think that is just a wrapper around the same calls. Looking inside the database toolkit VIs alone scares me. FWIW I am using LabVIEW 2013 in this application. Thanks!

At JKI, we have found that a professional user interface design can make a huge difference for LabVIEW applications. That’s why we’re very proud to announce we have just released the JKI Flat UI Controls for LabVIEW, a beautiful, professionally-designed set of LabVIEW controls that we use on some of our own projects at JKI! We hope that by sharing these with the community, we can help make it easy for just about anyone to build their own beautiful and intuitive user interfaces in LabVIEW. Learn More & Download

https://m.youtube.com/watch?v=v6X4QkYQTZU&feature=youtu.be

LVA-Tools.Co.Uk is having a Post NI Week Bonanza with 40% off all commercial toolkits.. Offer is available for one week so grab the opportunity to secure your business data and websocket that application.

Hi everyone, I have developed over a couple of years my own interface between LabVIEW and Lua (MLua) much like the CIT's pioneering luaview http://luaview.esi-cit.com/index.html. The two key differences are: 1. MLua dynamicly links with the Lua binaries 5.2 distribution, ensuring compatibility and allowing the use of external Lua modules coded in C. 2. A much simpler interface, no need to understand the Lua stack based API. Example: Wondering if I should go through the effort of making it an addon on the tools network... and if so, what type of license and cost. Any input is welcome

Does anyone have any ideas as to why I would be getting the following message while trying to install the OpenG Toolkit through VIPM? I'm using LabVIEW 2014 SP1 (32-bit) and Windows 7 Enterprise SP1 (64-bit)

I see in VIPM that there is the OpenG Toolkit, then the individual packages as well. Is the intent to install the OpenG Toolkit (assuming you want all the modules) package, then update the individual modules as they are updated? I feel safe in assuming that *since I've already installed all the individual packages that there is nothing for me to be bothered about, if I am correct in assuming that the "OpenG Toolkit" package is just a snapshot of a major release or when the appropriate person feels like updating the snapshot. Ryan R.