"write syslog.vi" reporting File Not Found error

[MichaelAivaliotis]

I'm trying to deploy the RT portion of my DECAF system and I can't get it to run because of a strange file missing error:

Error 7 occurred at Call Library Function Node in write syslog.vi:4110006->TBM module execution interface.lvclass:init wrapper.vi->Standard Engine Runtime.lvclass:Initialize Module.vi->Standard Engine Runtime.lvclass:Initialize From Config.vi->Standard Engine Runtime.lvclass:Initialize.vi->PL_Target Runtime.lvclass:open and initialize engine.vi->PL_Target Runtime.lvclass:initialize target with engines.vi->PL_Target Runtime.lvclass:load and intialize target with engines.vi

Possible reason(s):

LabVIEW:  File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.

I started digging and found that it's coming from the write syslog.vi. Any ideas why this is happening and how to fix it?

[MichaelAivaliotis · Accepted solution]

Wow, so many poorly documented things in DCAF. I figured this out. Apparently there's a Deply tool in the DCAF Editor Tools menu. This will deploy the needed startup log files. WTF doesn't the syslog API automatically create this file if it's missing? SMH.

[MattP]

The missing file is the Syslog .so (DLL equivalent on Linux) needed to generate logs.  We do not have a separately installed component for this, instead we rely on the DCAF deployment utility to move this and any other module-specific dependencies to the target.

We had a design alternative to create a separately installed CDF for each dependency, which would throw the exact same error but require a user to install software from MAXfor each dependency.  Would going that route have reduced the confusion?  Is there another alternative you would suggest?

[MattP]

Also, thanks for all of your feedback!  It is much appreciated.

[MichaelAivaliotis]

Sorry, I was confused about the solution. I thought the .so file was something that could be created on the fly instead of downloaded to the controller. it makes things a little more complicated. Can these .so files be included with the syslog deployment? I think there is a need to automate this so the user doesn't have to google the solution. Mainly because the syslog module is integrated into DCAF and is required for successful operation. If you don't deploy the required files, it will fail 100% of the time.

You have done a much better job of automating the includes file and pointing out the process for that in the Help. Something similar for this needs to be done. You could also add a button on the target configuration page for system deployment, similar to the Generate Includes button. This will force a user to review this and ask questions. As it stands, the menu option is pretty invisible. For me, I had to debug this down to the syslog package and then went to GitHub to file a bug report and noticed the message on the home page describing the deploy tool. 🙂

For myself, I decided to put the dcaf.pcfg file into my build spec so it gets deployed every time I do a build because I'm changing it often. Not the .so file since it just needs to be deployed once.

PS: I just noticed the Additional Files tab. I assume this is auto-populated? I think if you put all the deployed files on that tab in a table form with check-boxes next to each file it would be cleaner than the deploy dialog. Then a user could deploy right from that tab.

[RVallieu]

Is the NI Syslog Wrapper VI package (1.0.1.11) what is called by the DCAF?

The installed package makes NO mention of DCAF.  I was looking around for Syslog information and stumbled upon this package, but could find no way to interact with it, etc. or which code might leverage it, etc.

Also would be nice to include which .so file does it expect to be in the lib folder?

VIPM information on the NI Syslog Wrapper:

NI Syslog Wrapper v1.0.1.11 by National Instruments
Released On: Fri, 03 Nov 2017 11:03:17 -0500
Author: NI Systems Engineering
Copyright: Copyright (c) 2017, National Instruments
License: Apache 2.0
Compatible LabVIEW Versions: >= 2014.
Compatible OS Versions: ALL.
Repository Name: NI LabVIEW Tools Network

Description:
Simple, high-speed interface to syslog.
Approximately 10x faster than using RT Debug String method provided on palette, and opens all syslog options.
Expects .so file to be present in \usr\local\lib on cRIO target.
Syslog-ng can be configured using the /etc/syslog-ng/syslog-ng.conf file on the target.
Only works on NI Linux RT targets.  Will be a no-op on other targets.

[MattP]

Hi Ryan,

yes, DCAF uses this and it was written for the DCAF use case.  It has no dependencies on DCAF, so the package itself makes no mention of it.  It is intended to be generically usable for RT applications.

The source is here.