Search the Community

We have a gage supplied by a company that shipped it with a *.exe application targeted for LVRTE 2009. I need to retarget it for 2017, but don't have the source code. The supplier had said they'd gladly supply me with a copy of the *.LV source, but they have looked and cannot find their own copy in-house. History of Need: Our global corporate mother ship's IT department, in their infinite wisdom, is mandating an upgrade from Win7 to Win10. That with yet even further constraints. They enforce a list of "approved versions" of "approved applications". And for LVRTE, they are insisting upon 2017, with 2009 being a red light. So, then, my query. Is converting an app without the source for a higher LVRTE doable at all? File is attached. If it is doable, instructions on how? Concentricity-Gage.exe

Hi, When I try to install LabVIEW 8.5.1 runtime or visa 4.1 on an Intel NUC with CPU i5 7260U I get: Microsoft Visual C++ Runtime Library Runtime Error! Program ........\LV RunTime 8.5.1\setup.exe This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Just in case I installed Visual C++ 2005 redistribution and checked under add remove programs that the Windows feature of allowing version under .net 3.5 to run was enabled. This is not an ARM based processor so why does LabVIEW has a problem installing on the NUC?

Hi, I’m having issues with a LabVIEW application that I made. Quick summary: The application is used for reliability tests. Users can configure profiles/experiments. These are translated to a voltage/current output. Experiments can be started to run parallel on a rack of power supplies. More Details: The application is OO-based. Each active experiment is an ‘experiment executor’ object which is a class with an active object. The process vi is a very simple statemachine which handles init of the hardware (VISA (Powersupplies connected via Ethernet, VISA TCP/IP)), iteration handling of the test, summary logfiles, UI and a few other things. Typical usage of the application is: 16 samples tested in parallel. Most of them run the same experiment (== same output) but on different powersupplies. These samples are tested simultaneously, and started at the same time. System details: LabVIEW2011 SP1 (32bit) // VISA 5.4.1 Observations: In development: I can simultaneously start 16 samples summary file of the experiment settings are written to disk (16times in parallel == 16 samples and all vi’s are set to reentrant) duration is about 10s for each file. (depends on the length of the experiment, different profile steps that are used etc) it is a simple ini format file, about 136KB size Experiments start execution. (== output and measurement on the power supplies) Parallel reentrant VISA communication with power supplies works perfect, internal looprate in the ‘avtive’state of the process is about 500ms (with 16 parallel samples) In runtime: When I start the samples, the parallel processes are started BUT: Writing if the ini summary file gets slower and slower each time a new clone/sample is launched. I see this, because for debug I open the FP of that vi. Writing of the file gets slower and slower… fastest file == 30s, slowest (== last sample started == 250s) Parallel reentrant VISA communication, looprate is 20-30 SECONDS (iso 500msec in development) Can someone help me with this ? 16 parallel process isn ‘t that much. I always thought that runtime would be faster than development env.

Hello everybody, I've got a situation where some controls change their position on the build application however only on the target system. This is not just limited to a specific type of control and it does not even effect all controls on the same FP. Up till now the behavior seems to be limited to controls inside a tab-control. My development machine is Win7 with LabVIEW 2011 installation and the target system operates on XP. I'm not to much bothered by it since it does not effect my main UI (which is build using classic controls btw), but it is a rather strange behaviour. Now for a solution: I had some good results by moving the controls in the dev-environment with space-right / space-left once, therefore the position is not altered, but the build application seems to run just fine for most of the controls. I might be able to post a screenshot next week. Does anybody had experienced a similar behavior with such a setup? This issue might be related to that topic: http://lavag.org/topic/16911-prevent-control-resize-when-changing-monitors/ However my controls change their actual position, where the related topic changes height & alignment (of the text inside).

Hello Everyone, I am a small-time application builder on Labview, I have tried to find answers to the following two questions a lot on the NI site but could not get any definite yes or no answer So here are the questions 1) I know that DSC module requires run-time license on the end-users computer, my question is, that if I use the datasocket binding on the controls/indicators property box and assign a couple of OPC tags (like 20-30 max) and not use the shared variable engine, do I still have to get a dsc runtime license, or is there anything like OPC tag-based license for the end-users PC? 2) Does database connectivity toolset and report generation toolkit also require runtime license on end-user PC's?