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.
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
I'm connecting to a Rigol DZ1000 Oscilloscope via USB and using the :DISP:DATA? ON,0,PNG command to grab a screenshot. Reading out the data in blocks of 65535 bytes until there is no more (see attached vi).
This normally works fine but yesterday I was getting a timeout error. I fired up IO Trace and got this:
> 783. viRead (USB0::0x1AB1::0x04CE::DS1ZA201305475::INSTR (0x00000001), "#9000045852‰PNG.......", 65536 (0x10000), 45864 (0xB328)) > Process ID: 0x000039C8 Thread ID: 0x00001760 > Start Time: 13:13:54.1169 Call Duration 00:00:10.4323 > Status: 0xBFFF0015 (VI_ERROR_TMO) You can see that 45864 bytes were received, which is exactly what was specified by the binary data header (45852 data bytes + 11 header bytes + 1 termination char)
I dumped the reply string into a binary file and set the scope to run so it show something else on the screen. Sure enough the error went away. I also dumped a good result into a file. Then I tried to figure out what the problem may have been but I didn't get anywhere. Any ideas? Sure looks like a bug in VISA read or perhaps an incorrectly escaped reply from the scope?
It's very easy to "convert" the reply into the screenshot - just remove the leading 15 bytes (4 bytes from WriteBinayFile and 11 bytes from the scope header). And yes, both data files display just fine as PNG. I don't think PNG does internal checksum so byte errors would be hard to spot.
Any ideas what could have caused that timeout?
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.
I am experiencing numerous VISA Lock Errors (-1073807345) on resources I haven't explicitly locked. This is happening on TCPIP connections to keysight N6700 power supplies and keysight N5242 PNA fairly regularly.
I have simultaneous loops in the application communicating to the different instruments, using a sequencer of sorts to pipe commands one at a time to each of my various loops.
Has anyone seen the locking error pop before while not actually using the Lock and Unlock VIs? This issue has gotten worse lately and it has come time to find the root cause. My only thoughts are that it may have something to do with having NI MAX and Keysight Connection Expert both installed and possibly trying to "ping" these devices. Every once in a while me sending commands and these "pings" may clash and cause the locking error.
Error reads as follows:
"Specified type of lock cannot be obtained, or specified operation cannot be performed, because the resource is locked. VISA error code -1073807345 (0xBFFF000F)"
We are using LabVIEW 2013
Thanks in advance!