LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

real time negative memory

Hi

We have a real time system, host-target, desktop-desktop.

When I deploy the target code I am getting memory statistic that look something like that:

Free Memory: 18014398508184166 K of  3078012 K  Total (-2147483648%)

any idea?

Next there will be problems.

System Description:

Target is running LabVIEW Real-Time 13.0 (CPU cores found: 6)

Host is running widnows 7 Enterprise service pack 1, 32 bit.  LabVIEW 2013  32 bit.

Target Ethernet card is:  Intel(R) 82579LM. Communication is done  using NetStreams.

Devices on Target:

NI PCI-6221

NI PCIe-6321

NI PCIe-1429 camera link image acquisition 

 

 

Thanks,

Naama 

 

 

 

 

 

0 Kudos
Message 1 of 11
(6,101 Views)

Hello nzdr,

 

A few questions to help clarify the issue you are experiencing:

 

1. Try deploying a very small VI to your target. Does this give you the same issue you are experiencing?

 

2. What kind of problems do you run into after deploying to your target? Do you experience any errors?

 

3. From devices you listed, it is evident you are using a PXI system. Which PXI real-time controller are you attempting to deploy to?

 

Thanks!

 

 

Collin D.
Software Product Manager
Message 2 of 11
(6,035 Views)

Hello Colin D,

 

Thanks you for your reply.

 

I went to check my system on deployment of a small vi,
and I'm getting the same weird statistics.

 

The system will start smoothly  but will not be stable and will hang out with memory messages

like "There is not enough memory"  or "LabVIEW memory is full". It will not be on stable time.

 

My target is a desktop computer with ASUS MB  P9 X79 LE  and a CPU  i7-4930k.

 

I did extend the virtual memory that is available for LabVIEW 32 bit  from 2G to 3G

using the bcdedit command.

 

I have started to run system health loops to monitor memory contiguous  count and cpu usage,

which look busy (cpu 0 like 70%)  and contiguous memory is dropping but OK

 

but still why we start with this statistics.

 

best

Naama Rubin

LabVIEW Associate Dev

0 Kudos
Message 3 of 11
(6,001 Views)

Hello nzdr,

 

What Real-Time operating system are you deploying your code to?

 

Thanks,

Collin D.
Software Product Manager
0 Kudos
Message 4 of 11
(5,958 Views)

NI Real-Time Par Lap ETS 13.1

0 Kudos
Message 5 of 11
(5,931 Views)

Hello nzdr,

 

Are there any other targets you could deploy your code to? This would enable us to see if the error is caused by the allocation and deployment on the RT module side or if it is related to the target.

 

Thanks,

Collin D.
Software Product Manager
0 Kudos
Message 6 of 11
(5,877 Views)

Hello  Collin and thank  again for replying,

 

 I thought maybe  first to test my current system with a new LabVIEW project,  that has   a single  empty vi at target. On deployment the same weird statistic  was reported.

 

Looking at this URL (from a few years ago)

http://forums.ni.com/t5/Real-Time-Measurement-and/real-time-image-procession-problem-with-IMAQ-RT/m-...

I thought maybe the problem is with the PCIe-1429, so I had pulled out all  cards, both DAQ cards and PCIe-1429  and redeployed the empty vi,  but still got the same fault statistic.

 

I took the RTTarget (the desktop computer from above , MB ASUS, 6 cpus) and connected it to other Host desktop computer (MB DP45SG, Intel, OS win 7 Enterprise, service pack 1), again deploying empty vi in a new project, and again getting the  same fault dlg.

So I said last test, before replying is to take other old RT Target that I have here around, (OS:  NI Real Time PharLap 13.1) with a single cpu kernel,  MB:  GA-945GCM-S2C and  had connect it to the other host (from  a paragraph above) using  this time GT desktop adapter (PCI) at RT target, and again getting the same weird statistic.

 

So I’m not sure what’s going on???!!!   should I just ignore this weird statistic dlg gracefully,  or find what is the reason for that.

 

Hardware was replaced from target1-host1 to target1-host2 to target2-host2, and always weird statistic dlg was there,

so it can’t be ram slots or hardware, or code (empty vi  in a new project), and I don’t know how to eliminate confusion on this,  Does anyone else get such weird statistic on deployment?

 

 

thanks, Naama  

0 Kudos
Message 7 of 11
(5,844 Views)

Hello nzdr,

 

From the results of these tests, it seems the issue relates to the LabVIEW Real-Time module. Most likely, something about changing the virtual memory of the LabVIEW program caused something to effect the RT module that now reports the wrong memory usage for the device. I would try reverting the LabVIEW virtual memory back to the 2GB it had been installed with and seeing if your issue persists. Personally, I have never heard of this issue before and cannot find any documentation surrounding it and this is what makes me think it has to do with changing the virtual memory for LabVIEW which is rarely done. Let me know how that works for you.

 

Thanks!

Collin D.
Software Product Manager
0 Kudos
Message 8 of 11
(5,807 Views)

I get the same on a PXIe embedded controller - I just ignore the message.  My device is a PXIe-8133 RT with 2GB installed - so it's running LabVIEW RealTime, not Windows.  Using  LabVIEW 2012 on the desktop and RT 12.0.

 

DeployMemError.png

0 Kudos
Message 9 of 11
(5,791 Views)

OK, thanks

That's rejecting a few other things I had thought to check.
Weird that the negative percentage at the paranthesis, is exactly the same...

0 Kudos
Message 10 of 11
(5,766 Views)