Jump to content

Linux cRIO Memory Usage


Neil Pate

Recommended Posts

Posted

As per this KB it is no longer possible to retrieve the memory usage using the System Session property nodes. Considering the Linux implementation is several years old already this seems like quite an oversight but not something NI seems terribly worried about. The solution proposed in the KB seems quite incomplete.

Strangely, NI do have a way to get this info as it is reported in MAX

image.png.2cdd012bbb98a8d10b041b99a83c16f3.png

 

Does anyone have a solution for this?

 

Posted (edited)
  On 1/12/2020 at 10:43 AM, ensegre said:

spitballing, having never worked on cRIO: standard linux ways like just parsing the output of free wouldn't help? Or reading /proc/meminfo?

Expand  

Yeah it seems this is the way to go, I was just hoping somebody had done this already ðŸ™„

I have tested both using an SSH console into a cRIO VM and they do seem to work.

image.png.315cc0794ab19120de00dba3cfac3094.png

Edited by Neil Pate
  • 2 weeks later...
Posted

Permissions might prevent the reading of the file.  If you do a Open File maybe even set to read only then read the file you might have better luck.  Also calling a system exec and reading the standard output might work as well.

Posted
  On 1/22/2020 at 7:32 PM, ShaunR said:

OK. Got hold of my Linux Box with LabVIEW. Wire a number of bytes to the "Count" (1024?). Ignore the error 4 if you demand too many.

Expand  

Oh yeah, just wire a -1 and you get the whole file.  I always forget that.

Posted
  On 1/22/2020 at 10:15 PM, hooovahh said:

Oh yeah, just wire a -1 and you get the whole file.  I always forget that.

Expand  

That doesn't work. I would say it is a bug but it's never worked. ¯\_(ツ)_/¯.

  On 1/23/2020 at 10:35 AM, Neil Pate said:

Tried that in my original test, still did not work.

Expand  

This is what I have on my Linux box (not a cRIO though) so if you don't get anything; that is definitely a bug.

image.png.e40727a45e05da28857b00425ae35b96.png

 

 

Posted

Okay I'm done guessing without actual testing in the environment.  In Windows -1 on the Read From Text File, and Read From Binary File both read the whole file.  I feel like there is a bug or two found in this thread.

Posted

Given that it's not an actual file perhaps it has no idea of how much to read without parsing the lines in the primitive? There is no "size" information but if it reads as lines it keeps going until the end using read operations. Regardless -1 does not work on my 9046.

Posted
  On 1/23/2020 at 1:56 PM, hooovahh said:

Okay I'm done guessing without actual testing in the environment.  In Windows -1 on the Read From Text File, and Read From Binary File both read the whole file.  I feel like there is a bug or two found in this thread.

Expand  

If you read a text file then it will work. However. as Jordan states; it is not an actual file. It's is a text output stream from the VFS.

  • Like 1
Posted
  On 1/23/2020 at 4:42 PM, ShaunR said:

If you read a text file then it will work. However. as Jordan states; it is not an actual file. It's is a text output stream from the VFS.

Expand  

Most likely when you pass in -1, it does a stat() (or possible the equivalent of the internal FSGetSize() function) to determine the size of the "file" and read that much bytes. Since it is a VFS it can't return a valid size for the "file" (most likely fills in 0) and LabVIEW concludes that it is an empty file and returns that. 

Join the conversation

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

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

×
×
  • Create New...

Important Information

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