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.

How often are you writing to TDMS, or rather, how often is the TDMS committed to disk? Does the 8 hour marker correlate to a disk write?

That 4GB barrier sounds vaguely like a FAT32 limitation. Are you running NTFS as your filesystem?

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?

Hi all,

Do anyone know how to convert Microsoft Kinect SDK to LabVIEW ?

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.

Ummm, it's called dataflow Your subVI has the IO constant as an input (which is an output of the case structure), and the error out (which is an input of the case structure). The case can't execute until it has data at all of its input tunnels, and it can't satisfy that for the error cluster.

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?

Here are my get/set temperature vi's for a Watlow F4 controller. You also need the NI Modbus library.

And there seems to be an issue with the VI snippet. The clusters constants there can be remade and should have RTU and 1 as the values in them.

Hopefully this is of some help to you.

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!

You also may want to consider 2 state machines. One for user events and the other for the temp chamber. You need to devise a way to pass the events from one to the other (most people use queues).

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:

In the event structure, when you are editing an event, you may want to uncheck the "Lock front panel until the event case for this event completes" for most events (unless you want to disable any user action until the event is completed.

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

...temperature... <BR>...code coming...

Well, if the event structure is reached, it needs to either wait for an event, or timeout. I'm wondering if the loop you have isn't stopping, and it goes around again? Can you give us a screenshot? Or upload your code? I know a few people that could do with one of those

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?

What do you mean by losing control?

Have you tried watching the front panel with highlighted execution?

Tim

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......

(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!

oh man,

turns out I needed to drag from IE to desktop then to LabVIEW.

so simple!

(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....

Pete, what browser are you using?

Currently LabVIEW only supports drag and drop from IE directly into LabVIEW, to use the snippet in another browser you can use a 'IETab' plugin which basically is IE in an activeX frame, or drag the image to your desktop (or another folder) and drag-drop from that location.

ton

For some reason this never worked for me with Internet Explorer Version 8.0 (7600.16385). But dragging to desktop first fixes this issue.

(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....

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?

Thanks for the replies.

I'm not a Perforce guy, but setting your whole drive as your workspace sounds like a mistake to me. Why do you want to include <instr> and <vi.lib> as dependancies? Sounds like you need to take a look a VI Package Manager.

I am going to look into VI Package Manager and see how it fits into my system; maybe this will help solve my Perforce dilemma.

This does not mean that the entire D drive is held under Perforce, what we do is set the View to target folders in the Perforce Depot to our workspaces.

Yes, maybe this wasn't clear in my first post. While I can view my C: drive in Perforce, the only folder that are held under SCC (by Perforce) are folders that I have chosen to be under control.

I am starting up LabVIEW development at a client's site that uses Perforce SCC.

I have been debating on how to setup the workspace for a development machine and finally decided on having my workspace be the entire C:\.

This seemed to be the only solution to include <instr> and <vi> directory dependencies in the SCC.

I am struggling to understand how to include all my dependencies without moving files in and out of a smaller-scope workspace.

My gut feeling is that having my C:\ as a workspace will come back to bite me. Has anyone else done this?

I have used SVN in the past, so my hesitation comes from my SVN experience and now using a new SCC (Perforce).

Thanks!

Pete

Are you using Legacy DAQ somewhere else in your code?

I had code that mixed DAQ and DAQmx and saw a similar behavior to what you are seeing. NI confirmed this was caused by Legacy DAQ.

I'm running into a synchronization issue with an SCXI-1112 in an SCXI-1000 frame. Irregularly (every 10 to 15 reads), the read takes roughly 10x longer than the majority of the reads. This slows the rest of that case down, which drops data. I've tried various sample sizes, changing my loop delay, and adding "DAQ Control Task" in my initialization to set the task into "Commit". What else might I try to polish the edges so it doesn't stick any more? I've attached pictures of the relevant code.

Truly impressive.

Yes, I was just thinking about how sweet this was (post normal LabVIEW hours).

All I want to do is add a record (row) to the end of an MS Access database table. I know the path to the database and I know the table name.

I have some code that does just this. You need to "send in" the Field names as created in your table (ADO doesn't like spaces).

I usually use this subVI to add in one field at a time to see if I can write values.

Remember, that you have to use a different method to add/replace fields to a row thats already created (this is an UPDATE action).

I have attached the code.

LAVA woudln't let me upload sample database but included a screenshot. The created database in screenshot worked with the subVI included.

Good luck and let me know if I can help.

-Pete

Write Row Into Database example.vi