Cluster wired to UDP Write Crashed LabVIEW

In the Windows version of LabVIEW 6.0, I am allowed to wire a cluster's output directly to the Data In of a UDP Write node. However, when it is executed, LabVIEW crashes. The Linux version 6.1 doesn't allow that connection. Is this a change between 6.0 and 6.1 or a bug in the Windows version?

No, it never behaved correctly. I am very inexperienced with LabVIEW. I was practicing building a front panel on a Windows 2000 machine with 6.0 eval. I wired the UDP Write as I described and tried to run it. Each time I clicked the button that activated the UDP "code", LabVIEW crashed. I copied the .VI to our Linux box with LabVIEW 6.1 Full Version and, when I brought it up, the line between the cluster and the UDP Write was dashed. I then changed the diagram so that all of the items in the cluster were converted to U8 using byte-swapping and word-splitting, converted it to a binary array, converted that to a string and sent the string to the UDP Write and cured the problem. I wanted the inputs into the cluster to have the exact data structure as defi
ned in the C header for readability.

Similar Messages

Can I read/write a LabVIEW DataSocket cluster in Lookout?

Can read/write DataSocket text, logical, and numerical arrays but how do I read/write a LabVIEW style cluster datatype (i.e. an array of clusters or a cluster of arrays)?
Thanks!
Tom
Thomas G. Duffey
Engineering and Research Consultants, Inc.
Air Force Research Laboratory
3 Antares Rd.
Edwards AFB, CA 93524
661.275.6172 FAX 661.275.5073
mailto:[email protected]
http://neverworld.net

You should be able to wire your cluster or array of clusters or cluster of arrays directly into the datasocket write/read primitives. They are polymorphic and should handle the data directly.
Marc Monroe
National Instruments

Passing control reference to subVI crashes labview

Hi,
using a image control (as indicator) provided by imaq Vision, I tried to pass the reference of the control to a subVI. On a computer it works and on a other (same labview version, same vision version, same os, same hardware and hardware drivers!), this crashes labview. I tried to close the control refnum at the end of the subVI, but that changed nothing to the issue. Now I use the reference as a global variable and it seems to work...nevertheless, I would like to understand what the issue and if I should remove any passing to subVI of control ref because this can potentially triggers an error. My correlated question is if this global passing is a "fake" workaround or have real chance of improving (this before going through the whole code for changing all passing of reference to subVI)
thanks a lot

Hi,
thank CoastalMaineBird for your answer
How do you know it's this issue which causes the crash?
When I remove this parameter from and the only property node in the subVi that write to it, I have no longer any problem. Moreover, to ensure that's really the "passing", and made a global variable containing the reference to this control and use my original SubVi that do access the control through its reference number
, and it works! In this last exemple, the only change is the way of transmitting the reference
What LabVIEW version?
8.0.1
up to date according Measurement & Automation update tool
Given that one computer works OK, and another crashes, I would say that
you are seeing the effect of something else, not the cause. If passing
a control ref via terminals was fatal, it would be fatal all the time.
You have some other sort of issue, perhaps timing of the different
machines triggers the bug, perhaps running out of memory, perhaps
LabVIEW is corrupted on one machine.... But I don't think changing all
your code to use globals would solve the real problem. Actually, saying that I wonder about problem of synchronisation. I know from Visual C++ that this kind of error happens if two process try to access the same control at the same time. This is typically an error changing from a computer to an other, and mutex or semaphore are the way to deal nicely with that. But does labview contains already such a securisation? If so, the global variable point on a single object and can "fell" the semaphore/mutex. But passing make a copy that will likely have two different semaphore/mutex but will point to a single control! Do someone know if I'm wrong in this idea or not?
Thanks

Crash LabVIEW in one click

The buggiest LabVIEW ever (8.6.1f1) keeps on giving:
WARNING: will crash LabVIEW and you will lose any unsaved work.
Open the INFO CLUSTER ctl in the attached LLB (28kB).
(Yes, I know it's ugly, I'm trying to work on it)
Right-click on the table.
Watch LabVIEW die.
Arrrgh.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks
Attachments:
Crash-o-matic.llb ‏28 KB

Yes, I know about the overlap stuff.
Like I said, I was working on it and re-arranging stuff on the page when I discovered the bug.
Actually, I worked around it like this:
Copied the MCListBox to a blank VI.
Created a generic property node.
Linked the property node to the MCListBox.
Set the AUTOSIZE ROW height false
Set all the row heights to 23 instead of 25.
Pasted the copy in place of the original in the control I was working on.
That's what I wanted to do via dialogs, but crashed instead.
Thanks for your offer, though.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

UDP Write

I am trying to send flattened data of images through UDP in a wireless network of sizes of around 8000 bytes. After sending around 50 frames , the UDP write gets stuck. It doesnt return error and it doesnt even time out (I have 10 sec time out time).
Is it because of the size of data?

Hi aman,
I was actually looking for the how much of the processer LabVIEW is using not
how much memory. If you take a look at
the image below I need the number highlighted.
I need this information for while the VI is locked up and while your
computer is idle. This will help me know
if the VI is completely using your computers resources or if maybe it has stopped
executing. It would also be good to know
what version of LabVIEW you have and what you are trying to communicate with.
Is the communication going over a network or to another computer through a
crossover cable? How reliable is this
issue? In words does it happen every
time you run it or will it sometimes work and sometimes not?
Adam H
National Instruments
Applications Engineer

Save for previous version 8.5 to 8.2 generates code that crashes Labview (uses classes)

Hello,
I'm working on some java style interfaces for labview for hot swapping of instrumentation for design patterns. When I try to port this code, developed on Labview 8.5 back to labview 8.2, the code it generates crashes labview (both 8.5 and 8.2).
Included is a small snipet of the work that demonstrates this behavior.
It includes to classes:
untitledProject1 - the containing project (version 8.5)
FunctionGeneratorI - Similar to a Java style interface (A class with all Dynamic VI's with no useful functionality)
FunctionGenerator33220a - An intended implementation of Function generator (only a few functions implemented)
and a folder "labview8_2Distribution"
Which contains the port of the 8.5 code to 8.2.
To recreate the error:
A.
1. Open "labview8_2Distribution\Users\Laptop\Desktop\object\Untitled Project 1" (8.2 save)
2. Verify it crashes labview 8.5 and labview 8.2.
3. Watch labview crash?
B.
1. Open the "Untitled project 1" in the root directory. (Using labview 8.5)
2. Save the project as a labview 8.2 type.
3. Try to open the saved version with 8.5 and 8.2.
4. Watch labview crash?
Greg Sonnenfeld
Attachments:
error.zip ‏885 KB

Hello Karunya,
In regards to your questions:
>Can you post your code? Have you tested this by creating another project?
Do you have an xcontrols in your projects? Do you have typedefs? Do you
have a LVOOP constant on your block diagram? Are you also using Classes?
I cannot post the cost as it is way too big. Not really my code but a spaghetti code from a previous programmer. I think problems saving it to a previous version have to do with a few things:
1) Memory - I have 1 GB of RAM and I am running XP. I notice the available RAM dropping quickly as it is saving and then it blow up.
2) Long Filenames - The directory path of the original file is incorporated into the saved "previous version" of the code. While a good design, it does make the file/path a bit longer when saving
3) One of teh things it saves is the drivers and their menus. This is due to the drivers being in a subdirectory of the original code and not in the c:\program files\national instruments\labview 8.5\instr.lib directory. I saw this when I tried to save the file as an LLB.
4) If I work with smaller parts of the code without long paths, it saves fine.
There probably are xcontrols, definitely typedefs, no LVOOP's or Classes. Hope you can do something with all this. It just seems that converting to a later version of the code should be reversable. Thanks.
Michael

Auto cleanup crashes LabVIEW (and VI isn't even that large)

Hi,
I'm trying to cleanup a VI, and whenever I hit auto cleanup LabVIEW crashes and when retsrated it doesn't even say it previously crashed. I narrowed down the problem location to a for loop. The wierd thing is that I went through all the wires and objects within the loop and did auto cleanup on them but it doesn't crash. So why when I do it on all combined does it crash?
I wrote a comment in the loop that crashes to show which on it is.
I'm on Windows 7 LabVIEW 2010.0f2 32bit
I did see this posting http://digital.ni.com/public.nsf/allkb/599FB39777BDB12486257514005B7293, but even when doing it manually as suggested it still crashes.
Thanks,
Matt
Solved!
Go to Solution.
Attachments:
Score Videos temp.vi ‏126 KB

This crash corresponds to a known issue in LabVIEW (CAR #298911), which has been fixed in the forthcoming LabVIEW 2011 release. I have attached a copy of your cleaned up VI from 2011, saved for 2010. You might try to copy the block diagram into a new VI and see if that still crashes LabVIEW, but otherwise an upgrade to 2011 when it's available should clear up the problem. Hope that helps.
John B.
Embedded Networks R&D
National Instruments
Certified LabVIEW Developer
Attachments:
Score Videos temp-1.vi ‏104 KB

XYGraph Cursor legend bug instantly crashes LabView 2012

Hi!
I am just facing a very annoying bug.
Please find my example VI attached, I would like to know wheather you can confirm the bug? Run the VI if you wish to see some curve (actually the bug appears even if you do not put any data on the graph, if you do, just the same) and after that try to click on the cursor legend vertical scrollbar to scroll up or down to see the cursor names.
It instantly crashes my LabView 2012 Full version: 12.0.1f2 (32-bit). This XYGraph always crashes LabView... I cannot go on with my project, now I will just try to bypass the error, I will try to delete the cursors, and add them again...
Anyhow, very strange and annoying behaviour...
Anyone could repeat the same bug?
Thanks for support!
Solved!
Go to Solution.
Attachments:
XYGraph_bug_test1.vi ‏149 KB

hello,
please find attached my example VI, where I would like to programmatically set the label position of a cursor. Why my code does create at every run a new cursor with the same name?
thanks!
Attachments:
cursor_offset_label_via_propertynode.vi ‏12 KB

Internet Toolkit for G5.0 crashes Labview 8.2 during Mass Compile

I have just received my Labview 8.2 update and installed it my system along with all my toolkits. When I tried to Mass Compile Labview 8.2 directory I found that it would crash labview consistantly as shown in the attached image.
I traced this to the vi's supplied with the Internet Toolkit for G5.0.
The workaround is ...
1. Re-installed the Internet Toolkit for G5.0 into Labview 8.2
2. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.0
3. Mass Compiled ...\project\_config\authcfg.llb using Labview 8.2
and there wasn't any more Labview 8.2 crashes during mass compile. As Labview 8.0 was able to mass compile the internet toolkit vi's without crashing I am suspicious that Labview 8.2 might not be completely compatible with Labview 5.0.
I posted this just in case anyone else sees a similiar issue.
David
Attachments:
Labview 8.2 Mass Compile Crash with Internet Toolkit.png ‏34 KB

David,
I was able to reproduce the crash mass compiling authcfg.llb or just trying to open the VI named 'Directory Configuration'. That code is saved in LabVIEW 5.0.1 and must have something that LabVIEW 8.2 chokes on, I'll have to get someone to investigate it. Your workaround of saving that .llb or even that one VI in 8.0 first (or probably even 7.x) is the only way I see around it with 8.2.
I do want to mention that in Q1 2004 we released version 6.0 of the Internet Toolkit and it does not exhibit this behavior. So the official solution for this crash is to upgrade to the latest Internet Toolkit.
Kennon

Simple Math VI crashes LabVIEW 2009 SP1

Hi,
We previously filed a related issue, (ref #: 7302858). The last problem was resolved by
Andy Hertzka from NI re-compiled the VI and send it back to us. That re-compilation solved the LabVIEW crashing.
However, the interesting crash happens again.
I attached a working VI before the change and a non working VI after the change and save. All the change I applied to the VI is
1. Add the "Word bits" as a connector on the diagram
2. Save it Then the VI begin to crash LabVIEW 2009 SP1.
Before the change, the VI was functioning all right.
Any idea why this might be happening? Can you try to recompile the non_working version and send it back to me for a try?
Thanks,
Tian
Attachments:
Non_working_AfterChange_RECOMPILED LRSample_U32in_U32output.vi ‏110 KB
Working_B4Change_RECOMPILED LRSample_U32in_U32output.vi ‏110 KB

Tian,
Like Andy I was unable to see why this code is unstable on your machine. I am able to run the code fine on my computer without any problems. Looking at the code on the block diagram I do not see any major "crash worthy" issues with it.
I have resaved the VIs like Andy had in order to fix your issue. By the way what OS are you using, windows 7? It might be helpful to save the log file for the LabVIEW crash. You should get this option when LabVIEW is restarted.
<Joel Khan | Applications Engineering | National Instruments | Rice University BSEE>
Attachments:
Non_working_AfterChange_RECOMPILED LRSample_U32in_U32output1.vi ‏108 KB
Working_B4Change_RECOMPILED LRSample_U32in_U32output1.vi ‏108 KB

Bug: Windows 7 DLL call to turn off monitor message crashes LabVIEW 10.0f2

Hi,
I wanted to log this bug on the forum. I have already logged this with NI UK Support: CAR# 286873
I was trying to find a way to turn off a laptop lcd
monitor during measurements. I was trying to replicate this
http://codereflect.com/2009/04/03/how-to-programmatically-turn-onoff-your-monitor/
which uses windows messaging.
I found the attached Monitor-1.vi somewhere on the forum that seems to do the above.
However when I run the VI it crashes LabVIEW 10.f2 on Windows 7 32-bit.
cheers
David
Solved!
Go to Solution.
Attachments:
Monitor-1.vi ‏13 KB

Hi Cosmin,
That was it! Thank you so much!
I will let NI UK support that you identified the issue and get them to close the CAR.
cheers
David
Attachments:
Turn off Monitor.vi ‏12 KB

Crash LabVIEW

In the zip file are two vi's. The "Crash LabVIEW.vi" vi uses a subpanel to open the other vi "just a while loop.vi". When the stop button is pressed on "Crash LabVIEW.vi", it sends the data to the stop button on the "just a while loop.vi". It works fine, but read the comments in the "Crash LabVIEW.vi". It was a simple mistake, but still no error message, nothing, just LabVIEW disappearing off the screen and off the task manager... I guess you can't compare apples and oranges, even though LabVIEW will let you try.
Attachments:
Crash LabVIEW.zip ‏21 KB

Hi Dominick,
I was able to reproduce this crash. You are right in that LabVIEW shouldn't crash without an error. This was reported to R&D (# 101959) for further investigation. Thanks for the feedback.
Regards,
Stanley Hu
National Instruments
Applications Engineering
http://www.ni.com/support

Spectrogram Graph Curser Crashes Labview

I was wondering if anybody else have this happen to them. I'm trying to set the location of the cursor on a spectrogram (intensity graph) (the x value), and it crashes Labview. I tried compiling to a .exe, and it still does the same on another computer.
Message Edited by d1sturbanc3 on 02-19-2009 11:33 AM
Message Edited by d1sturbanc3 on 02-19-2009 11:33 AM

what version of LV? what OS? can you post a subset of your code that demonstrates the problem?
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

GetDefaultPrinters (WinAPI call) Crashes Labview

Hi all,
For several reasons I need to use the windows API to get the default printer. I know about labview's activex solutions but those are not universal.
See attached VI. This winapi call crashes labview rather consistently. It runs fine and returns correctly the default printer. However, some time later, a few seconds or a few operations later it will always crash labview. Why? I've tried changing it to "Run in UI thread" instead of any thread but neither seems to help...
To get it to crash immediately, try closing the VI. That seems to do it every time. Access violations...
Solved!
Go to Solution.
Attachments:
defaultprinters.vi ‏10 KB

No. You actually did NOT allocated memory in your VI.
Here is how to allocated memory, the old way:
George Zou
http://webspace.webring.com/people/og/gtoolbox

1D Array of Cluster of 2 Elements Write to Spreadsheet

Hi all, first time using LabView in many years. I am trying to write a VI that will acquire data from our cDAQ (right now just trying to get it to work with a single thermocouple in a NI 9211, but eventually will be 8 X thermocouple, 4 X pressure transducer), display it in realtime on a plot, and then when the acquisition is stopped, output the data to a file for later use. I am currently using the Base LabView package.
My problem (as I remember it was 7 years ago when I last used this) is with the data types not working together. This is my thought process currently on building this VI. Everything is inside a While Loop with the Wait function at 1000ms.
- Acquire a point of data using the DAQ assistant
- Send that point of data into a bundle
- Send the iteration count into the same bundle (as a timestamp)
- Send the resulting cluster of 2 elements into a Build Array function
- Send the resulting 1D array to a shift register in the While Loop, as well as to an XY graph for realtime plotting
- Wire the incoming point on the shift register back into the Build Array function
In my mind, this allows the XY graph to plot the complete array every iteration, giving a realtime view of the signal. Everything works fine up to this point. My problems are:
When I stop and restart the program, the shift register is not cleared, so the existing data in the array remains on the graph. I know I need to initialize the shift register to clear it, but I cannot figure out what to wire to it that will be compatible with the data type (I just get broken wires with everything I tried).
Similarly, I cannot figure out how to output this data to a spreadsheet after I Stop the While Loop. I think I should wire the "Write to Spreadsheet File" VI to the outgoing shift register, but again, I can't get compatibility with data types (source is a 1D array of cluster of 2 elements).
I have attached my current program "Production" to this post.
I look forward to the help!
Brad
Attachments:
Production.vi ‏46 KB

Hi Brad,
I would suggest you change your architecture. First, to answer your questions:
1.
In order to ensure that your shift register is not reading the last
value from it's memory location, you just need to create a constant for
the shift register. To do this, right-click at the input of the
'left-placed' shift register and create a constant.
2. The Write
to Spreadsheet is expecting a 1-d or 2-d array while you are wiring a
Dynamic Data Type. Use the Convert from Dynamic Data Type to convert
the data into the appropriate waveform after which you can get the
waveform attributes which includes the values and the timestamp data. Or, you can use the Write to Measurement File to write to a .lvm file which can be opened in Excel as well.
Changes to your architecture:
Since
you are using a lot of channels, I would advise you use a
producer/consumer architecture. You can have a look at this
architecture by navigating to File -> New.. and searching for the
Producer/Consumer template. You will notice that this architecture uses
queues. The way you will design your VI is to use DAQ to acquire the
data into your producer loop, convert this data into a waveform and
then send this data to the consumer loop via queues. In your consumer
loop, you can write this data to a file. At this point, I would
encourage you to write to a binary file instead of a spreadsheet file. The write will happen faster and you will be using less space on your hard disk when compared to ASCII writes.
I know this can be real confusing for a beginner, so be sure to post back if you have any questions.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

Cluster wired to UDP Write Crashed LabVIEW

Similar Messages

Maybe you are looking for