Home > Labview Error > Labview Error 1122

Labview Error 1122

The LV-functions that causes the application to freeze are all inside a timed loop. This has happened to me countless time, and every single time this was a lifetime issue. Always ensure to close the reference only after all other functions needing it have executed. not only would you have to allocate millions of queues, you'd have to have them all continuously in play in order for the refnums to ever hit up against each other. weblink

The machine has 4GB of RAM and no other apps are running. Started by John Lokanis, August 30, 2008 41 posts in this topic Prev 1 2 Next Page 1 of 2 John Lokanis 76 The 500 club Members 76 786 Any other ideas? What it boils down to is LabVIEW is corrupting its own memory when running large parallel apps with a lot of shared clone Vis. http://digital.ni.com/public.nsf/allkb/10AE5BC4A92626058625780600749827

NI App support is trying to reproduce the issue. Egemen Producer-consumer to txt.png ‏106 KB 0 Kudos Message 3 of 5 (671 Views) Reply 0 Kudos Re: Why did I get error 1122? Site: NI Discussion Forums Forum: LabVIEW Total authors: 4 authors Total thread posts: 9 posts Thread activity: no new posts during last week Domain info for: ni.com Other posts in this The code relies on a continuous flow of data between an in-house SQL server and the application.

Sign in here. With your change, the error output from Dequeue stops at the case structure. The system returned: (22) Invalid argument The remote host or network may be down. Since it is impossible for these error to occur due to a coding issue, there must be a bug in LabVIEW causing it to destroy a queue reference outside this process.

I have been using this code for a very long time (5+ years) without having a memory overrun issue. In another whileloop I dequeue the elements.The vi works fine, but when I stop it appears two "zeros" in the Line indicator. Generated Wed, 30 Nov 2016 23:42:06 GMT by s_hp84 (squid/3.5.20) ERROR The requested URL could not be retrieved The following error was encountered while trying to retrieve the URL: Connection look at this site So, I really have no way to debug it with breakpoints or anything.

Please try the request again. Maybe you already released the queue and now it doesn't exist. Basic dataflow. At step 2 we wait for messages to appear.

Each of these functions is actually buried in several sub-VIs. great post to read Now if somewhere you're calling Obtain Queue and you're not calling Release Queue, you might be running your machine out of memory, and perhaps something strange is going on there (though In your previous code, that error travels all the way to the Simple Error Handler, which is the function that pops up the dialog box. They freeze during our long time tests.

The notifier was released with the Force Destroy input set to T. 2. have a peek at these guys The easiest way is probably to use the the General Error Handler function in the Dialog & Error palette. Showing results for  Search instead for  Did you mean:  Reply Topic Options Start Document Subscribe to RSS Feed Mark Topic as New Mark Topic as Read Float this Topic to the Share this post Link to post Share on other sites jdunham 30 Extremely Active Members 30 625 posts Location:San Francisco, CA Version:LabVIEW 2011 Since:1994 Posted August 31, 2008 QUOTE (jlokanis

Generated Wed, 30 Nov 2016 23:42:06 GMT by s_hp84 (squid/3.5.20) And then: Error 1 occurred at Release Queue in BIG-IP_TESTS_TM Get Scheduler Response.vi:21->BIG-IP_TESTS_TEST Call Scheduler.vi:9 Possible reason(s): LabVIEW: An input parameter is invalid. Your wait ... http://edsdefence.com/labview-error/labview-error-10.php Everything is tied together by wires, just as you see it here.

Wire the release queue function out of the loop where you generate the events instead of the consumer loop. And I use the Force Destroy feature to stop the background DAQ loops. one more questions - sometimes while running the same vi for the first time i got an error Error 1 occured at Enqueue element in Queue.vi Error code - 1 what

So, there are many many instances of this queue (all unique, supposedly) that exist within each tree of reentrant VIs.

Are you sure your CPU is fast enough to acquire and process the data simultaneously. The loop does not stop, because the stop button was read at the beginning. Ben Share this post Link to post Share on other sites John Lokanis 76 The 500 club Members 76 786 posts Location:Seattle, WA Version:LabVIEW 2015 Since:1993 Posted September 3, 2008 Without someone actually inspecting the code, there's no further recommendations that I can make, but those are two independent subsystems, so I would be very doubtful of a bug caused by

I have attached an image to see what is happening. When the spawned VI finishes execution, it will leave memory, as will all of its queues, notifiers, etc. What is the difference? this content That's going to be the best way to get NI to push further on this.

Here is the error: Error 1122 occurred at Dequeue Element in Process GUI Events.vi:34->Engine 422.vi Possible reason(s): LabVIEW: Refnum became invalid while node waited for it. It just seems strange that Labview throws this error only occasionally. You should use it to do error handling, but even if you wire it into a sequence structure, the error will stop popping.You can use a reference for your other request. Bob_Schor 2 user's latest post: why do i get error 1122 at...

Sometimes it takes hours and sometimes it takes only 50 minutes. I have had similar problems and was able to track the problem by monitoring the queue status while the vi is running. Use the get queue status vi to monitor the queue. Now, the launcher that spawns these VITs sets the spawned VI to Autoclose reference.

The bottom loop was waiting to dequeue from that queue, and suddenly the queue was destroyed. Top contributing authors: Name Posts matt198717 4 user's latest post: why do i get error 1122 at... newbieeng Active Participant ‎05-28-2013 12:29 PM Options Mark as New Bookmark Subscribe Subscribe to RSS Feed Highlight Print Email to a Friend Report to a Moderator Ok thanks. Here's an alternative approach. ___________________Try to take over the world!

So, there are many many instances of this queue (all unique, supposedly) that exist within each tree of reentrant VIs.