Jump to content

pete_dunham

Members
  • Posts

    56
  • Joined

  • Last visited

Everything posted by pete_dunham

  1. 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?
  2. 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!
  3. 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
  4. 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.
  5. 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.
  6. 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?
  7. subconsciously turning off "Automatic Tool Selection"

  8. 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.
  9. Yes, thank you, this was embarrassing.
  10. 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.
  11. Writing code is much more fun that reading it

  12. Writing code is much more fun that reading it

  13. Do you have any code you could upload? I am working with LV and TestStand.
  14. 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?
  15. This is a late reply..but THANK YOU! The NI Modus Library was exactly what I needed to solve this problem. And the attached snippets are what made this a clear solution. For anyone else using Watlow .dll, downloaded from the NI Instrument Driver Network, this .dll (what Watlow refers to as "standard bus") seems to be the culprit. IE, the communication across this standard bus seems to be what is locking up my system. The Watlow PM EZ-Zone I am working with has an optional RS232 Modbus module (determined by the controller’s serial number). I switched from communicating from Watlow's standard bus to the Modbus and now my communications and LabVIEW seem stable. Thanks again!
  16. I do agree with the above statement; this would be a preferred architecture. Nonetheless, this behavior was driving me crazy. But it turns out I was missing something pretty fundamental. I have attached some VERY SIMPLE code to demonstrate my error. Everything will go okay if you change the Start Profile control once. If so, the state machine loop (here just a simple case-inside a loop) will execute and the Front Panel is unlocked. I was running into a problem if I clicked on the Start Profile control <event> in rapid succession. If this happened, the loop would stop but the Event Structure would still have more events in it's "queue" to process. Thus, my Front Panel would lock up. Changing this option in each event, per: fixes the issue. Again, this is a poor architecture to begin with, but at least I have re-educated myself on some Event Structure fundamentals. Thanks for the input! Event Structure Behavior.vi
  17. ...temperature... <BR>...code coming...
  18. I just found a solution. For some reason it appears that my Event Structure was locking the Front Panel. This is confusing since, according to LV's dataflow, this Event Structure should be done executing. (Note that the loop containing the Event Structure had stopped and passed data to the next loop) By wiring a constant to the TimeOut terminal on the Event Strucutre fixed this problem. Is this a best practice that I missed?
  19. I mean I can't click on anything. Can't click on indicators or controls. Can't access Window's "File" "Tools" "View". Can't navigate to Block Diagram But......
  20. (LabVIEW 2010 in Windows 7) I have a relatively simple program (a temper chamber profiler) that I am losing control of the Front Panel. The program starts with an Event Structure in a loop where an event (Start Profile) will stop this loop and then data is passed to a state machine loop. It is in the state machine loop that I completely lose control of my front panel. The only option available to me is the Abort button. I have learned from past mistakes with this and have eliminated possible race conditions and have significant Wait (ms) vis in my state machine loop and subVI loops. The Performance and Memory tool is not shedding any light on my problem. Any ideas how to troubleshoot? Thanks in advance!
  21. oh man, turns out I needed to drag from IE to desktop then to LabVIEW. so simple! For some reason this never worked for me with Internet Explorer Version 8.0 (7600.16385). But dragging to desktop first fixes this issue.
  22. (In LabVIEW 2010) Maybe I am missing something simple -OR- I haven't found the right online resource or post, but.. I can't figure out how to drag and drop a snippet to my block diagram. I installed the Fetch Snippet files per this document/link: http://decibel.ni.co...t/docs/DOC-6229 I feel like I am missing out if others are having fun dragging and dropping....
  23. I downloaded a wrapper/.dll from NI’s Instrument Driver Network (uncertified). http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=16725 for a Watlow integrated controller (EZ-ZONE PM) . It works okay for the most part. However, every once and awhile, and seemingly for no reason, the calling VI crashes. Not only does it crash, it locks up LabVIEW 2010 and Windows 7. Nothing works to close LabVIEW except for a system reboot. (Sometimes it runs all day with no problems). I am scratching my head to troubleshoot at a lower level. And/or identifying an alternative path. I haven’t had much experience troubleshooting .dlls at this level from LabVIEW. I plan to install LabVIEW 2010 SP1 to see if that helps, but have a feeling it is the .dll causing the problem. Has anybody else worked through something similar?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.