Linux cRIO Memory Usage

[Neil Pate]

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

 

Does anyone have a solution for this?

 

[ensegre]

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

[Neil Pate]

29 minutes ago, 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?

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.

Edited January 12, 2020 by Neil Pate

[ShaunR]

I would suggest the "/proc/meminfo" because you can read it as if it was a text file with the LabVIEW file functions.

[Neil Pate]

Well that is not what I expected!

Any ideas why reading just a pure string did not work?

 

[Neil Pate]

This works fine for what I need, just a way of displaying the memory. I am too lazy to convert the string into a number (or rather I don't know if the units are always kB).

Linux RT Memory Usage.vi

[hooovahh]

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.

[Neil Pate]

The confusing thing is the file read does work, but only if I read it as lines instead of characters. 

[ShaunR]

1 hour ago, Neil Pate said:

The confusing thing is the file read does work, but only if I read it as lines instead of characters. 

I don't have a linux machine handy, right now, but try unchecking the "Convert EOL".

[Neil Pate]

2 hours ago, ShaunR said:

I don't have a linux machine handy, right now, but try unchecking the "Convert EOL".

Tried that, no dice. The file read returns an empty string.

[Jordan Kuehn]

1 hour ago, Neil Pate said:

Tried that, no dice. The file read returns an empty string.

FWIW I just checked on a 9046 and same behavior as Neil.

[ShaunR]

On 1/21/2020 at 5:53 PM, Neil Pate said:

Tried that, no dice. The file read returns an empty string.

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.

[hooovahh]

2 hours ago, 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.

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

[Neil Pate]

12 hours ago, hooovahh said:

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

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

Edited January 23, 2020 by Neil Pate

[ShaunR]

13 hours ago, hooovahh said:

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

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

1 hour ago, Neil Pate said:

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

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.

 

 

[hooovahh]

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.

[Jordan Kuehn]

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.

[ShaunR]

2 hours ago, 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.

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.

[Rolf Kalbermatter]

On 1/23/2020 at 5: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.

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.