Jump to content

Feedback node crashing bug

Recommended Posts

I have posted on the NI forum (here) but didn't get any response sine 5 days.

I have came across a nasty bug that caused Labview 2010 SP1 (Running Win 7 Ultimate x64 bit) to crash without any warning.

To replicate the bug do the following:

  1. Add a numeric control and another indicator to the front panel
  2. Switch to block diagram and add a feed back node
  3. Connect the initializer terminal of the feed back node to the output of the control
  4. Now do ANY of the following to cause the bug:
    • Press the run button (which is broken due to not connecting the input of the feed back node) it will turn to a normal run without displaying the error
    • Do an extra action and undo it, the run button will turn from list error normal

  • So far the Vi can be saved normally. Now connect the output of the feed back node to the indicator and try any of the followings:
    • Save the VI
    • Close the VI
    • Create a new project and select to add the VI to the project

    This will cause Labview to crash without any notice!

When you are at step 4, the bug is there but harmless. Once you combine it with step 5 (connect to indicator), the bug is active and cause crashing. I have attached a snapshot of how the Front panel/block diagram look like before saving (since it can't be saved). Notice how the run button is enabled although the input of the feedback node is not connected.

I have tried to replicate the error on Labview 2009 but couldn't.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By LogMAN
      Here is another bug I discovered in LV2019+ which reliably crashes LV. Simply connect a set to the map input of the Map Get / Replace Value node on the IPE:

      This VI is executable in LV2019 SP1 f3, which means that you can actually build that into an executable without noticing.
      I have reported this, but there is no CAR yet.
    • By Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi

      Note that adding another element to the outer cluster causes the problem to go away.

    • By 0_o
      My LabVIEW 2016 32 bit is crashing a lot.
      I can guess it is related to:
      1. incompatibility with DAQmx 9.1.5 and the related device driver which I need for LabVIEW 8.5.1 which I also use (NI's support jumped on that issue yet I think it is not related)
      2. an addon that I use to access OpenCV leaving some references open in the dlls
      3. Controls with same label or with no label (I believe that this is the issue -LV can't recover correctly in such cases)
      However, I don't want to guess like NI's support that it is point 1 and do nothing to prove it.
      I expect to see the reason in a log file yet the support wasn't able to show me where to find it.
      Searching around I found the dmp file under documents\LabVIEWdata
      Is that the way to check those crashes or one of you know of a better way to check it beside elimination?
      Thanks in advance
    • By ShaunR
      Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it.
      The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further).
      The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed.
      The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event.
      To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement.
    • By A Scottish moose
      Hey everyone,
      I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
      As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
      Does anyone have any knowledge or experience with this? 

  • Create New...

Important Information

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