hooovahh

Oh my, so I think I'm going to stop trying. I just went and used my linkedin profile picture, and it thought I was 24 years older than I was when the picture was taken. Of course I was wearing a hat, not that I know how that affects it. Seriously it thought I was in my 50s.

Well I went to my facebook and I could only find one face shot of me that was detected (not many pictures of me on my facebook I guess). In the photo was me and my wife. It thought I was 13 years older than I was when the photo was taken, and it thought my wife was 19 years older than she was.

Yes it sure does seem like a no brainer that you could use the Pre-build action with the set build specification. It was the first use case I had for the new 2014 feature. Too bad NI wasn't thinking it would be used in this way, and as a result, the version assigned to the build is read before the pre-build action is executed. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/In-building-executables-allow-Pre-Build-Action-to-modify-Version/idi-p/3056573

I do use build number to link back to source code control. So this still means manually updating it every time which is a bit of a pain. I've thought about ways of fixing this but I just live with it. So when I'm making a build I'll set the Major, Minor, and bugfix to what ever is appropriate incrementing from the last version. I'll then set the build to whatever the source commit number is. So for SVN I'll right click the project, go to properties, and then use the commit revision number. I have in the past taken the commit revision number and added one to it, because this would be the revision of the next commit but as long as there is a decent description in the commit I've never had a problem. What this does for me is help isolate an EXE to source. So years later we get a report saying this step failed. In the report is says the EXE version was 1.2.3.534. I then go to source code control, and find commit 534. Hopefully there is a comment in the commit saying "commit build version 1.2.3.534" and I can roll the source back to that and see what the source was that made the EXE, that was ran when the report was created that failed.

If you want to use an analog out for generating you setup you can. You'll have other limitations that might get in the way making that difficult. Like the fact that when a new buffer is put down, you'll either need to stop your task, which will drive the output to 0 while for some time, or you can replace the buffer values but you can't resize the buffer. So say you want to generate a waveform that is a PWM at 100hz and 50% duty cycle. Using an analog out you can generate a single cycle of this wave and tell it to repeat. But if you want to change to 50hz and 50% duty cycle you'll need to stop the current task, create the new buffer, put that buffer down, and start the new task. This will mean that for a few milliseconds your output will be 0v. A counter output gives you more some features that an analog out can't, and an analog out has some features a counter can't. Some tasks can use either. Your 9178 chassis has two BNC connectors on the front that can be used as counters. And my example was designed and the 9188 which I'm guessing has very similar features. If you can get my example working, then it shouldn't be too difficult to replace the array of frequency duty cycle pairs with your own and have it work.

I forgot about that place. I also used to checkout ClientsFromHell.com but they appear to be down.

What rolfk says is very true. There is little practical reason to have multiple applications, or installers in a project, for the same build if all you are doing is changing the version. Have one EXE and one installer. Some times I see another EXE for debug, which is the same as the normal but has debug enabled which includes block diagrams. And some times I see another installer which includes all run-time additional installers to have it work on a fresh clean machine. But with these exceptions there is no reason to have multiple versions. Are you trying to have it so that a new version, goes into a new folder? This could be changed but I thought I remember hearing about a feature in the application builder that allowed for this, I never used it so I'll need to search for it. So with your one EXE and one installer, just up the revision of each, and then build the EXE, then build the installer. LabVIEW calls it an Upgrade code, which is where the term comes from. EDIT: Found it, on this page under Destination Path http://zone.ni.com/reference/en-XX/help/371361K-01/lvdialog/destination_settings_db/ There it states you can use [VersionNumber] in the Destination Directory path in the build. So you can have C:\My Application [VersionNumber]. Then all you need to do is up the revision of the software, and build it and a new folder will be made and the old ones you may have on disk won't be overwritten. Double Edit: Looks like it was a new feature of 2013 http://zone.ni.com/reference/en-XX/help/371361K-01/lvupgrade/labview_features/

Ohh another fun story time (need to write these down before I forget). So I'm on site at a place where we are deploying a tester that is designed to replace testers that were already there. They had 5 testers, and this first visit was to replace one of them with our new design which was faster better more scaleable etc. There were some things we couldn't test until we were on site and one of those things was the network authentication and logging. So we got onsite and went to replace the first system, and we asked for login credentials for their network. We were told we couldn't get any for a couple days. So I went over to one of the existing testers and looked at the credentials it was using since the source was on the old stand. It had something like User: Tester and Password:Tester1234 on all 5 testers. So I used those credentials and the new tester and 4 of the older ones were running just fine. I mentioned to the customer that this seems like a weak password and user name and that all systems were using the same credentials. At that moment out of the corner of my eye the IT guy ran off quickly. A few minutes later he came back and said he fixed it. By that he meant that the user name and password no longer worked. They didn't seem to care that the new system didn't work yet, until I went over to one of the older 4 systems that all of the sudden could no longer test parts and was holding up the line. I just thought it was comical that they fixed the loop hole which had apparently been running fine for years, without thinking that it would break everything using it.

I've done it both ways. Dedicated hardware, or software that finds the hardware usually using a known query like the serial number of the device. When "Software is free" managers would rather not spend more money for hardware, when all it takes is a few hours of your time to design, develop, integrate, test, verify, and document...

At times I believe it is less about protecting a PC from viruses, and more about a check box in some corporate form that says "All domain PCs will have anti-virus software installed".

I think you are confused, this discussion hasn't been about the hardware used, but instead an effective way of doing the software architecture. And for the record I hate having 5 USB to serial devices. They might get re-enumerated to the wrong ports, power can be an issue with many of them. The FTDI chipset can be slow especially if there is lots of data, etc. The plus side is they are cheap, but I'd prefer a single USB device that has 5 (or more) COM ports, over 5 single port devices. On the desktop and PXI there is also cards that add physical ports but these are usually more expensive than one USB device.

Yup uninstall the newer and install the older. Other software tools follow this same concept. Yesterday I had to install an older version of Adobe reader, and to do so I had to uninstall the one I had first manually.

Oh it was great because in this situation they were my customer, paying hourly for me to be there, I troubleshot the issue, and came up with a proposal to fix it. Turn off the bloody IT crippling software. I had no horse in the race. The customer could take my advice and have a test system that worked, or they could do nothing, and not have a working test system. When a manufacturing line goes down due to IT being too restrictive, things get done quickly. We were told that IT would not allow the software to be uninstalled. You actually needed a super secret password to uninstall it. But they did allow the PC to have an administrator account, where I could turn off services, and turn off startup applications. So the customer had me removed it from msconfig startup. The details are fuzzy, but I think their IT department ended up paying for my time to be there. Not that I think that is fair, they were just trying to do their job.

Oh man, anti-virus, firewall, or general IT policies broke my application many times. Often in ways that seemed unexplainable at the time. I had a vision system that when it was being deployed would some time have a half my image become green. Like the image was being grabbed and half way through it stopped. We looked into the capture card, and the PC, thinking it couldn't keep up, network settings a bunch of things. It was strange because before going onsite it worked just fine, which should have been a red flag. At the time I thought, well maybe the PC was just barely fast enough, and since IT added a few programs it now can't keep up. Nope it was corporate firewalls scanning all network traffic, causing slow downs on our ethernet controlled cameras. But hey, free trip to Alabama. Hope you figure it out, be sure and report back if you do.

Here's a fun little project I had. It was to make a frequency sweep on a counter. This particular project used the BNC connector on a cDAQ-9188, and no c-series cards, just the chassis. It does this by generating the array of frequency/duty cycle pair. It will output that frequency and duty cycle for one cycle of the wave, then do the next frequency duty cycle pair. At the time I had no idea that a counter could have a buffer of finite samples. In my mind this means it has two hardware timers, one for the frequency and duty cycle, the other to handle when the next frequency duty cycle needs to be. If your counter supports this type of buffered write of N samples this shouldn't be a problem. You just need to do a decent amount of math to come up with the array of frequency and duty cycles that you want the card to play. https://decibel.ni.com/content/docs/DOC-32352 This example isn't meant to be a drop in solution, but just a way of showing that it is possible to control the time at which a new frequency and duty cycle occur.

Ahh yeah that wasn't clear. Still doable. Write each A and B clusters on their own, then iterate over all elements in the Cluster C writing them one at a time in a for loop, then do the reverse for the read. Write Read Cluster 2.vi

Yeah I have had a similar experience. If you have multiple panes I believe new controls are always place in Pane 1. The position of the control appears to be (0,0) if the origin of the pane is (0,0). But as you move it around, which can happen when setting controls to fit to pane, their position is less predictable. I usually create the control, double click it, then use Shift Arrows to bring it into the viewable area of Pane 1, then drag it to the pane I want. It is a pain working with panes. I know of no work arounds, and because of this I will usually work in reverse, making the control I want, placing it where I want, then go to the block diagram and move it where I want.

The standard links I use are the following for free training. NI Learning Center NI Getting Started -Hardware Basics -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required LabVIEW Wiki on Training There are lots of ways of doing your task, and much of it will depend on what the developer is comfortable with. Since you aren't comfortable with anything, I'm not sure what to suggest. An Access database seems a bit advanced for a new developer, but other options are quite custom, dealing with various text files for instance.

Not that I know of. It could be done with lots of extra work.

If I understand what you want, you are doing it the hard way. Attached is a VI that reads and writes clusters to INI files. I just write the whole Main cluster and read the whole Main cluster using OpenG. Write Read Cluster.vi

That's what I'm thinking. I realize the condition can be a string. But if the value currently is "TRUE", then I can guess with much certainty that the opposite is "FALSE". Same with 0 and 1, and other capitalization of True and False. Personally I haven't made any conditionals that aren't effectively boolean. I generally used them for things like when a system is designed to not have a piece of hardware. So I would have DMM==FALSE and then the code knows not to talk to the DMM and to not show DMM manual controls.

Very neat thanks for sharing. I wasn't sure that this would work as a pre-build, because I know that setting the version of the build in a Pre-build VI doesn't work. The version appears to be read when the build start (before pre-build) and then changing it in a pre-build VI just changes the version which will be used in the next build which isn't useful. Good to know the conditionals don't work this way. One thing I've wanted to do for a while now, but haven't had the ambition for, is to allow conditional items in a project to be toggled using a right click menu in the Project. Imagine if I could right click my project in the project window, and in it is a sub item like Conditional Symbols >> and then under the Conditional Symbols is all of the conditional symbols that are True or False (or TRUE or FALSE, or 0 or 1) and the items are checked or not checked based on the current value and clicking the item will toggle it. The good news is NI has provisions to augment the project explorer window, and this is theoretically possible using this. https://lavag.org/topic/18545-i-have-taken-the-first-step-towards-unofficially-opening-up-the-project-provider-framework/ The bad news is lack of documentation makes it difficult. I tried by taking an existing plugin and modifying it and I didn't get very far. Even so I think this could be a good tool for quickly turning settings on and off with a simple right click.

Attatched is some suggestions. We stop the DAQ task at the end, we stop on error, and we improve the reading by leaving it as an array of waveforms instead of dynamic data types. This allows is to write both channels with one TDMS write improving fragmentation. There are many ways to do this but I decided to keep track of the amount of time that has been logged, by multiplying the number of samples, by the amount of time that separates the samples. Then add those up and if the time is greater than 2 minutes stop. I'd still suggest using an event structure, and some how disable the user from stopping saving, once a save has started. Potentially a user could turn on the save, save for a few seconds then turn it off, and start it again. Now the log data will not be continuous.

Wow that does sound strange. I'd suggest enabling debugging on the built EXE, and then you can probe around. Using something like the simple sexy timing probe you should be able to see what steps in your process are slower than in the IDE. The unfortunate thing is it sounds like all processes are just generally slower. I could also suggest trying to see how it performs with only one worker loop (compared to source) but it sounds like the problem gets worst with more loops so this might not tell you much. Maybe you could do the divide and conquer method and start disabling, parts of the code and see when it starts to respond like the source. Very time consuming, but effective for isolating the problem.

I'd talk your local NI sales rep. Something that specific, and old might be hard to find on NI's FTP site. ftp://ftp.ni.com/