Jump to content

LabVIEW hangs with logarithmic mapping on XY Graph (silver)


Recommended Posts

I can very repeatedly hang LabVIEW 2017 without even running a VI. It involves simply changing the y-scale mapping on a graph to be logarithmic. The best I can tell is that the initial (linear) scaling has the same max/min range values and this causes the problem somehow.

Does this happen in other versions of LabVIEW? (I'm using 17.0.1.f4, 64-bit.) And more importantly, how can I avoid this issue if I want to use log scaling and the data may start with a bunch of identical (positive-definite) values?

I'm using the "XY Graph (silver)" control. I haven't yet replicated the problem with the standard "XY Graph" control, either because I haven't created the right conditions or because that control doesn't have the issue. But I'd like to avoid switching out all my (many) graphs, in any case.

CrashDemo.vi

Link to comment

No hang seen in my LV2020 linux, only (after some manipulation) an X scale and label in a wrong place above the graph. But anyhow, I've seen across the years individual controls occasionally becoming corrupted and behaving foul. The easiest solution then is just to recreate the control anew.

My impression is that control themselves include their own callback code, to be responsive e.g. to appearance change, even at edit time. On occasions, this result in some insanity, like infinite loops.

Edited by ensegre
Link to comment

It does hang in LabVIEW 2019 SP1 f4 64 bit Windows 10. I am betting this one will never be fixed.

This being said, how did you create that graph? If I pick a new one and try to manually enter the same upper and lower bound, it will usually just swap their order and not let me change the second one. If I try programmatically to set the max and min range of the scale, I get the following displayed values:

0.000125173

0.000113794

Playing with increment or precision doesn't help...

Edited by X___
Link to comment
  • 1 month later...

Join the conversation

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

Guest
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
      I discovered a potential memory corruption when using Variant To Flattened String and Flattened String To Variant functions on Sets. Here is the test code:

      In this example, the set is serialized and de-serialized without changing any data. The code runs in a loop to increase the chance of crashing LabVIEW.
      Here is the type descriptor. If you are familiar with type descriptors, you'll notice that something is off:

      Here is the translation:
      0x0008 - Length of the type descriptor in bytes, including the length word (8 bytes) => OK 0x0073 - Data type (Set) => OK 0x0001 - Number of dimensions (a set is essentially an array with dimension size 1) => OK 0x0004 - Length of the type descriptor for the internal type in bytes, including the length word (4 bytes) => OK ???? - Type descriptor for the internal data type (should be 0x0008 for U64) => What is going on? It turns out that the last two bytes are truncated. The Flatten String To Variant function actually reports error 116, which makes sense because the type descriptor is incomplete, BUT it does not always return an error! In fact, half of the time, no error is reported and LabVIEW eventually crashes (most often after adding a label to the numeric type in the set constant). I believe that this corrupts memory, which eventually crashes LabVIEW. Here is a video that illustrates the behavior:

      2021-02-06_13-43-58.mp4 Can somebody please confirm this issue?
      LV2019SP1f3 (32-bit) Potential Memory Corruption when (de-)serializing Sets.vi
    • 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 0_o
      Hi,
      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 The Engineering Bear
      Hey y'all,
      Wanted to look for some feedback on some code I made for troubleshooting crashes and hangs for medium to large LabVIEW applications.  Wanted a way for a user experiencing a crash/hang to have a simple way of narrowing down where the problem is occurring.  The VI is named Crash Logger.vi and it only requires the VI itself to use.  No type def's, additional VI's, or other necessary parts.  The reason for this is so that a user can drop it in multiple parts of their application and have it log the current state and some information on system state to narrow down where a crash/hang is occurring.  I've gotten some feedback from friend's regarding making it a global variable that wrote to variables and had a separate VI to do the logging, but this takes away the "ease of use" I am going for for the user.  I've included an example application to show how it can be used for a simple state machine.
       
      I'd love getting more insight into what I could do better though which is why I'm coming here!  Let me know what y'all think!
       
      - Bear 


       
      Crash Logger Project and VI.zip
      Crash Logger.vi
       
       

    • By torekp
      Here is a graph I made recently, which shows particle number (symbol), material (broad color family), measurement location (exact color), amplitude (X axis) and phase (Y axis).  That's five dimensions in a 2D graph!  There are some obvious limitations.  For instance, there are only 16 symbols, so whatever you're representing by choice of symbol better not have more than 16 categories.  And there are only so many colors, especially if you want them all to be ordered in a spectrum from red to violet.  It gets worse when you try to have "broad color family" like I do here with reddish colors for aluminum and bluish for titanium, because the obvious logical thing to do is to skip over some shades in between the families, reducing the total number of available colors.

      What other options should I consider?  How do you do it?  I don't usually use 3D graphs because (a) they're harder to work with and (b) when I create a report for management, they like to have 2D images they can print out, or view without needing Labview on their computer.
      I'm attaching two VIs I use to create color spectra for my graphs.  I use colors_darken_lighten to darken plots for a white background.  To skip over colors, I obtained 6 colors in my spectrum and reshaped the array to two-by-three, then indexed by measurement location to get the first two colors from each broad color family.
       
      colors_darken_lighten.vi
      plot_color_spectrum.vi
×
×
  • Create New...

Important Information

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