Wim

Thanks Hooovahh, I'll check on the system as soon as I'm back at my customer.

I had to go to a customer for a very old project of theirs. They still use LV6.1 , tradiotional DAQ , ... After reboot of the PC and login by another user all configured DAQ tasks were gone. There is no documentation on the setup so recreating is not an option. They have an old image of the PC so .... where does MAX (version 2.2) store it's DAQ tasks, scales etc ? Thanks Wim

tests are running for about 30hours now... everything is working at the estimated speed. In this case it is definitly just a checkmark on a form.... This customer is a big, very known company... can't mention the name though. And the comment "We have to ask a worldwide exception for this." is just the same as "My checkmark is set, yours isn't...." Well, the people that are using the application, can live with it. Their comment on this was..."So if we want to use software that our company does not allow, we'll just name it LabVIEW or Word or .... Rather not LabVIEW, we want to keep that reputation clean"

The tests are running for 6 hours now. I talked to an IT guy. They confirm that it is McAfee that is causing the problem. But adding an exception is not possible.... They have to do a request to McAfee to add an exception worldwide They just don't want to put any effort in it. I'll just call my executable labview.exe

Hi guys, maybe a solution. So I build a new exe and tested it on different systems with the same configuration (simulation, exact the same experiments etc etc) The 2 systems at my customers location (the actual testsystem and the dev system) were both slow. The 3th system (a personal VM) was fast. With exact the same exe, installed runtimes etc etc So I'm thinking it is due to the PC's. They are on a big network where IT has very strict policies. One of my colleagues had a good idea.... If it works from the LabVIEW.exe (the dev env) then rename your exe to LabVIEW.exe. We think that LabVIEW is a known program which has more permissions on the system then my own build exe (SwitchablePS.exe) And for now it works. The dev env is fast in simulation, the actual test system is fast, even with the hardware connected. The test system is running a test now. It will end next week. Fingers crossed.

No. I tested with the same configuration (simulation) which just generates dummy data (random number).

I never use the option to separate compiled code. Now it's getting stranger and stranger by the minute. The original dev system can create exe's again with good performance (I can only check the file IO, don't have the powersupplies there) If i copy this exe (including aliases file and ini) to the actual test system, file IO is terrible. 6s for a file on my dev system vs 30 to 450s on the test system. I can't understand this one. OK, it is the same harddisk that files are written to... why the difference between dev env and runtime. Local settings: dev system: decimal point = point and on the test system decimal point = comma. But I have in the LabVIEW ini and application ini the 'UseLocalDecimalPoint=False' option.

No inlined VI's. I made a build on a different PC and that one is ok. I'll try the full compile tomorrow.

shoneill, I'm having the issue again. I made a few successful builds yesterday and have a good exe running on the test system. However, I wanted to know what solved it. So, I did a commit to svn, to be safe. I reverted to an older project file (code stays the same) and did a build. Again everything slow. Updated back to the latest project file. I was assuming this would be a succes but..... again a slow exe. I tried making a new project file from scratch.... slow exe To be continued.

Hooovahh, thanks for your input. The timig probe looks very usefull. However, the issue is already fixed. Can't tell how... I don't understand it. I was preparing the folders with the code for a service request to NI. I changed the build path for the exe to a folder next to the code and build it again. That exe works fine. I copied it to my test system and VISA is running fine too. Strange solution .... Was the build spec corrupt? I really can't tell but I'm glad my exe is running as expected now. I have a whole evening and night ahead to worry about what solved this issue

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.

Together wit NI we have found the problem. The GDS (Goop development suite) causes the conflicts. The problem is identified, solution is pending. Cheers, Wim

Hi Lava, I'm having an issue with a teststand deployment (Teststand 2013, LabVIEW 2013) I have a deployment which deploys my LabVIEW project containing all drivers (classes and lvlibs) for use in my sequences. In the deployment (LabVIEW options), I uncheck "exclude vi.lib", "exclude user.lib" and "exclude instr.lib" because the deployment should also work on an PC that only has runtimes and an operator interface. The build finishes without errors but I cannot open the deployed project... --> not on a development PC because it finds conflicts (XNodeSupport and some vi's in vi.lib picture.llb) --> not on a runtime PC (file not found) Did anyone else notice the same behaviour ? Thanks in advance for your help, tips and tricks :-) At first, i thought i had something to do with LabVIEW search paths (because I include vi.lib, it should not search for the vi's in the real vi.lib) but that didn't help... http://lavag.org/topic/18620-labview-search-paths/#entry111920

:-( A quick test with changing the search paths did not solve my project conflicts ... So... going further with specific INI files will not solve my issue. Thanks for your support.