pete_dunham

Wait, am I going crazy? http://forums.ni.com/t5/LabVIEW/How-to-change-the-labview-default-cursor/td-p/2476512 Have all the labview versions merged into one in my mind?

I am using LabVIEW 2013. At some point today my running VIs don't update the cursor to "the finger" over controls. When the VI is not running, the "finger" comes up over controls. Did some option get flipped? Is there such an option? I've restarted LabVIEW, my PC... Anyone else run across this? It is driving me crazy!

I don't own either. But in a similar case I was deciding between an iPhone and (Samsung) Droid Charge. (Upgrading from original Motorola Droid 1) After loving all my Samsung products (tvs and monitors) I took the plunge with the Samsung Droid Charge. I quickly came to regret this decision. Samsung has this phone stuck on Android 2.2.1 and I notice a lot of software bugs. Two of which drive me crazy: twitter and my voicemail programs with fail and only load again after a phone restart. Also my GPS locking, that was fantastic on Motorola Droid original, is finicky at best on this Samsung product. (This maybe not a problem for the Samsung Tab, but I also can't get rid of a ton of Verizon bloatware without rooting the phone and voiding my warranty). All my work and personal computer are MACs, which I love, and I paid the price by trying to diversify. Not sure if this is the input is valid for iPad versus Samsung Tab but, if not, at least I was able to rant

Not exactly sure if I am understanding exactly what you are trying to do. But, on an unrelated project with LabVIEW and Virtualbox, the only way I could get it to work was to have my Guest and Host operating system have the same version of MAX and DAQmx installed. Seemingly this was needed for the host OS to pass information needed to the VB guest.

Thanks for the replies. I believe we are writing to the TDMS many times a second. I had a hunch that this could be a problem, but figured it would show up pretty quickly (unrelated to the file size increasing). Changing our program to write maybe once a second or every 2 seconds is probably a robust change. We haven't tried this yet since it requires a change to our architecture. As far as the the 4GB barrier, I had the same reaction as you: "That 4GB barrier sounds vaguely like a FAT32 limitation" However, our HDs are NTFS. I wasn't involved in the programming at the point that the team was running into this issue. But I did some research on ni.com and found some related articles on this (and of course, I can't find them now). I eventually bought into this limitation since NI AEs verified this limitation and recommended using advanced TDMS (TDMS+ in palette). These VIs allow you to allocated the file sizes >4GB during setup. But, these TDMS+ seemingly have their own issues. Since you had the same feeling as me, I am going to setup a simple data program on an XP machine and see if duplicate this error. (By intentionally creating a TDMS >4GB). I will post the results.

Hello all, I thought someone else may have some insight on this error on a program that runs for an extended period of time. Thanks in advance! (summary: C++ error after 8+ hours) I am working with another LabVIEW programmer on a Data Acquisition Program that stores a significant amount of data over an extended period of time: 1000 samples/sec for 14+ hours. This development, because of an IT mandate, has been limited to Windows XP (32-bit) machines. We have tried various approaches to avoid file size limits of XP. We have also had to cleanup processes that were continuously allocating significant memory in LabVIEW. Our current approach is to save the data in multiple TDMS files of approximately 2.5 GB; as Windows XP was choking when a TDMS reached a size greater than 4GB. Basically when the current TDMS file we are writing to gets to 2.5 GB, we start a new one. Currently, after ~8 hours we get an error message "Microsoft Visual C++ runtime Library runtime error. R6016 not enough space for thread data" We verified that a reinstall the C++ runtime Library does not resolve this error. Has anyone had similar hurdles when saving a lot of data for a long period of time?

I ran across/saved this blog post regarding this. http://ryangordon.ne...labview-part-2/ but haven't had a chance to dig into it.

Yes, thank you, this was embarrassing.

All of a sudden I can NOT wire "through" my case statements in my state machine. I can wire controls that send data out of tunnel nodes. In the same case structure as soon as I try to wire in a error cluster or DAQmx task, then LabVIEW makes a feedback node. Pretty standard stuff; I feel like I have done many times. Do I have a weird option flipped? I have attached screen shots of what I am doing. A 1-2-3 Any help is greatly appreciated.

Do you have any code you could upload? I am working with LV and TestStand.

I was trying to get organized. 1) I moved a hierarchy that was uncontrolled into my Perforce workspace. 2) My main application VI loaded all the subVIs properly (saved in to SCC) 3) I created a Library and used Folder(Snapshot) to add all my dependent files to the Library (to prevent cross linking from a branched project where some of the TypeDefs and SubVIs might have the same name). 4) I went to save my Library into SCC but LabVIEW asked me to save all my SubVIs in memory. I happened to NOT have my entire directory checked out in Perforce (so I was denied and had to not save). 5) Now...when I try to open my VI I am prompted to select every dependent SubVI and TypeDef (a major pain). The strange part about this that the LabVIEW Prompt says "Loading.." and show the 100% correct absolute path of file that I have to go manually browse for and select. What is even stranger is that my inital VI that was checked-in in Perforce is acting the same. (Even though this VI is one revision before I created this Library). This behavior is driving me crazy. Any insight on how to avoid this in the future or how LabVIEW is handling this?