LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error code: 2 Possible reason(s): LabVIEW: (Hex 0x2) Memory is full. No Listeners on the GP

I am using Windows 10 PC (x64 based) with LabVIEW version 2023 Q1 (64-bit). I am using LabVIEW to control a oscilloscope from Siglent Technologies (Model: SDS1104X-U). I found the drivers for the oscilloscope in the NI Instrument driver finder. This installed driver with name (Siglent SDS 1000 2000 Series). I want to fetch the waveform from the oscillscope and for that I used the Fetch Waveform.VI (that is already given by the installed driver from NI). It is a low level VI and when I am trying to fetch the waveform, I am getting the following error:

 

Error 2 occurred at an unidentified location

Possible reason(s):

LabVIEW: (Hex 0x2) Memory is full.
=========================
No Listeners on the GPIB.

 

I did some test with other low level such as (read.VI, write.VI) to send basic queries and I was able to retreive the information. But, the above Fetch Waveform.VI does not work. Can you suggest me how to resolve this issue? I can also send screenshots to have more clarity. Looking forward to your help!

 

 

0 Kudos
Message 1 of 13
(607 Views)

Hi abani,

 

can you debug your VI and its subVIs to determine the exact location of the error?

Your error message only mentions an "unidentified location"…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 13
(600 Views)

@abani_nayak wrote:

I am using Windows 10 PC (x64 based) with LabVIEW version 2023 Q1 (64-bit). I am using LabVIEW to control a oscilloscope from Siglent Technologies (Model: SDS1104X-U). I found the drivers for the oscilloscope in the NI Instrument driver finder. This installed driver with name (Siglent SDS 1000 2000 Series). I want to fetch the waveform from the oscillscope and for that I used the Fetch Waveform.VI (that is already given by the installed driver from NI). It is a low level VI and when I am trying to fetch the waveform, I am getting the following error:

 

Error 2 occurred at an unidentified location

Possible reason(s):

LabVIEW: (Hex 0x2) Memory is full.
=========================
No Listeners on the GPIB.

 

I did some test with other low level such as (read.VI, write.VI) to send basic queries and I was able to retreive the information. But, the above Fetch Waveform.VI does not work. Can you suggest me how to resolve this issue? I can also send screenshots to have more clarity. Looking forward to your help!

 

 


If you are trying to download a huge data set, LabVIEW can run out memory.  If you can download the trace in chunks, that would probably help.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 13
(579 Views)

I tried debugging my VIs. But, I am not able to figure out where is the actual problem. Inside the Fetch waveform.VI, there exists three different sub VIs. I checked each of them to see the error flow. There is a sub VI by name: Get Waveform.VI which is producing this error. I am attaching the pics and a video to show the data flow. The video can be found in the following cloud link:

 

https://cloud.uni-jena.de/s/PoZ7fTARr7B54eb

 

 

pic1.PNGpuc2.PNG

 

 

 

0 Kudos
Message 4 of 13
(525 Views)

I have set the memory depth of the oscilloscope to be at lowest setting, which is 14000 samples in one display screen. 

Memory depth = (Samples/sec) x (No of Hoizontal divisons (in sec))

There are 14 Horizontal divisions in my oscilloscope. I used two settings at sampling of 500 samples/sec and at 5000 samples/sec. But, at both the settings, I am getting the same error.

 

In my above replies, I have attached the image and video link, where the error is happening. Please have a look!  

0 Kudos
Message 5 of 13
(521 Views)

This may help reduce some memory.

 

You are reading a "byte string" from the scope, at least that is what I can tell from the block diagram picture and True case. You can avoid some memory copies by changing some of the functions you are using. Type cast always makes a copy of the data; your true case has a coercion dot, what is in the false case, conversion to I16 I think. In that case you will have a buffer copy.  Below might reduce your buffer copies by 1, that may help for the Byte case, no Type cast needed. Convert to I16 or I8 if needed. (Use the numeric conversion functions, not Type cast.)

 

mcduff_0-1709235041124.png

 

 

 

0 Kudos
Message 6 of 13
(503 Views)

Looking at your screenshots I see this:

 

Kyle97330_0-1709235623101.png

 

I don't know why it would be requesting negative 1.3 billion data points but I'm pretty sure that number being wrong is the cause of it running out of memory.  Try tracing where that number comes from... it's probably also related to whatever generates this "Last valid point" as it's also a quite large negative number:

Kyle97330_1-1709235820679.png

 

0 Kudos
Message 7 of 13
(498 Views)

I think I found out a part of solution to fix this issue. At least with this method, I am able to get the waveform from the oscilloscope. Before the subVI (Get Waveform.VI), there is another subVI (Get Descriptor.VI), which reads the settings from the front panel of the oscilloscope. Since, the query is in Hexadecimal format, the Get Descriptor.VI is unable to parse/decode them into strings/numbers that Get Waveform.VI can understand. That's why it is not able to get the waveform. 

 

In the below Images, you can see what Get Descriptor.VI does. The number/strings that it reads does not make any sense. 

 

getdescriptor_fp.PNGgetdescriptor_be.PNG 

 

I changed the input parameters for Get Waveform.VI into some logical numbers that I can see in the front panel of the oscilloscope and it is able to retrieve the waveform. You can also see that the error message is gone, which was not the case in my previous post. 

 

getwaveform_fp.PNGgetwaveform_be.PNG

 

So, instead of using Fetch Waveform.VI, I plan to use Get Waveform.VI in my implementation. Please note that Get Waveform.VI inheritance was private and I changed it to public class.  At least with this VI, I am able to retreive the waveform. However, the waveform is not in the desired values. It is scaled by some factor and I have to work on converting them into meaningful values. 

 

I am also not an expert in LabVIEW. But, is there a way to convert Hexadecimal format into meaningful numbers through LabVIEW? It seems Get Descriptor.VI is not doing its job. 

What do you think? @GerdW, @billko, @mcduff, @Kyle97330

0 Kudos
Message 8 of 13
(481 Views)

Hi abani,

 


@abani_nayak wrote:

In the below Images, you can see what Get Descriptor.VI does. The number/strings that it reads does not make any sense. 

 

getdescriptor_fp.PNGgetdescriptor_be.PNG 

 

I am also not an expert in LabVIEW. But, is there a way to convert Hexadecimal format into meaningful numbers through LabVIEW? It seems Get Descriptor.VI is not doing its job. 

What do you think? @GerdW, @billko, @mcduff, @Kyle97330


Whoever wrote this VI did it in a complicated way. I recommend the UnflattenFromString function to get most of the data items (maybe except the 16 byte timestamp data)…

You can convert any kind of formatted string to any kind of numeric data in LabVIEW, you just need to know the source and sink format!

 

Can you please:

- place a string indicator right after the Read funciton inside the GetDescriptor VI to show the output string of the Read

- run the GetDescriptor VI

- set the string indicator content as default value

- save the VI and attach it (Maybe downconverted so more people can open it. I prefer LV2019.)

 

We need to know what the VI is reading from your device to be able the debug this VI…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 9 of 13
(472 Views)

What communication bus are you using? In my experience it is possible you are encountering an error that presents only when communicating over a bus that is different than the bus the driver development was performed under.

 

If there is an example VI that utilizes the same function calls, have you tried running that? Does it return errors? 

 

It's possible you found an instrument error in the firmware over the comm bus you are using. If you have tried to simplify your setup and run a very basic request of your instrument and it is still doing this, I would suggest reaching out to the manufacturer/developer to investigate.

 

0 Kudos
Message 10 of 13
(453 Views)