Free space 0 bytes on CVS-1458RT

[Seyong]

software : LabVIEW 2014

hardware : CVS-1458RT (firmware 2.5), Embedded UI enabled.

--------------------------------

Hello,

I have a vision inspection application under LabVIEW 2014.

I deployed it about 100 CVS systems by the RAD 5.5.2.

The problem is that some systems do not start our application set as stratup.            

To solve this, I tried system format in MAX but I can't.

Because  MAX can not find the CVS under problem.             

And I detected some unusual conditions on system.

(1) Startup application is unexecuted - Linux on run-mode

(2) MAX can not find the CVS - Linux on run-mode

(3) Free space of file system indicate '0 bytes' (refer to pic1.png) - Linux on run-mode

(4) 'df' command on terminal indicates "/dev/root use% 100%"(refer to pic1.png) - Linux on run-mode

So, I tried following sequence.

After reboot(push reset button more 5sec), CVS goes to user-directed safe mode.

(5) MAX can find the CVS under safe mode.

(6) MAX can not do 'system format'  - Linux on safe-mode

(7) MAX can not upgrade firmware. error 80041CF0 occured. - Linux on safe-mode

     >> This error comes from 'not enough space', I guess.

(8) 'df command on safe mode terminal indicates /mnt/userfs  use% 100%(refer to pic2.png) - Linux on safe-mode

So, I deleted /mnt/userfs.  Please refer to pic3.png.

After reboot(push reset buttone more 5sec), CVS goes to user-directed safe mode.

(9) Now, I can do 'system format in MAX

After reboot automatically, CVS goes to software not installed safe mode.

(10) Now, I can use RAD again.

-------------

But, most serious problem is....

Sometimes(not everytime) the 'Clear CVS system' have same  phenomenon after reboot. just reboot(eletrically power supply off/on).

So, I make a image deploy VI using 'Set System Image.vi'  to deploy system image instead of RAD.(refer to deployImage.png)

And I creat new system image by a 'Create System Image.VI in LabVIEW.(refer to creatImage.png.  Sorry, It's Korean)

But, Problem is not solved.

Please some one tell me, How / Why this? 

Regards,

Seyong

[BradM]

It seems odd that a startup application, no matter how complex, would be taking up so much space on disk. Is the application saving actual images from the camera as part of the application? How large is the image that is created? Does the image (to apply) contain images (taken from the camera)?

There's something that's not adding up, even for the admittedly-tiny disk on these 1458RT's, but you bring up a good point: formatting from safemode should work, no matter what the state of the disk is in runmode. Issue has been reported, and we'll take a look into that

[Seyong]

This is 'df' result of 'Clear CVS system' .

And Startup application is fine on this system.

Yes, my application save actual images from camera not on root drive but on external USB SSD.

So, I can retain enough space (50% or more) on root.

The size of system image file is 207MB.

This system image file include default system files, startup application, some reference images and  addtional kernel for image viewer.

Regards,

Seyong

[BradM]

Thanks Seyong.

The only thing that I would expect could lead to this sort of a situation is if the controllers that were being imaged already had very full disks due to picture-images from previous applications, and this assumes that the image-application process doesn't format-and-reinstall. A simple reproducing case should probably be sent to the Vision R&D group.

[Seyong]

Thanks BradM.

I found the reason.

/var/local/kern.log file was too big, 1GB.

I think about USB connection problem maybe.

And original system image has big log file aleady

Regards,

Seyong

[BradM]

If you still have that logfile, can you send it my way? If there's a lot of repeating entries, just a snippet works.

[Seyong]

This is a part of log file, 7~8 lines per second.

I will edit /etc/syslog-ng/syslog-ng.conf  to disable kern log.

[BradM]

I PM'd you with a few other questions, but basically it seems like the error messages indicate some USB hardware issue. What's odd to me is that there should be a daemon called logrotate that watches over this logfile (as well as others) to prevent this sort of issue from happening, so something odd is going on there.