LabVIEW
XNET CAN EXE WILL NOT RUN AS STARTUP
My system is made up of a cDAQ 9135 running Real Time embedded Linux.
The Application is acquiring 15 analog input accelerometer channels and one sound channel divided into 1/3 octaves utilizing the Sound & Vibration toolkit.
Values are output through CAN to another cDAQ. Raw Sound values are also transmitted via TCP to the receiving cDAQ. The application runs fine (for days) through the project explorer either connected or disconnected from the cDAQ 9135 running Linux.
When an EXE is created and set as startup, the cDAQ display shows that the EXE is the startup application but does not run. Troubleshooting has determined that the XNET CAN portion of the application is at least one of the issues preventing the EXE to run.
I have confirmed that the XNET alias is loaded on the cDAQ 9135. I found information stating "You must also incorporate a delay mechanism so the driver gets loaded at the proper time". However the delay mechanism generates the error "Error 15 occurred at call library Function Node in nisyscfg.lvlib: Initialize Session.vi" Possible reasons: LabVIEW: Resource not found. It is the Initialize Session.vi which is generating the error!
The delay mechanism LabVIEW source code is located in a figure at
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8MLSA0 and is depicted below.
I was informed that instead of using the code depicted above, placing a delay before my application executes may solve the issue. I placed a 5 second delay in a sequence before my application starts and the CAN module is now recognized as indicated by the illuminated #1 LED on the 9862 CAN module. However, no data is being transmitted from the CAN module. My next step is to create a simple CAN XMTR/RCVR application to troubleshoot further to eliminate any other functions which may be disallowing the EXE to run. I had created a simple EXE to turn on the LEDs on the cDAQ 9135 and had it set as startup and run successfully with no issues.
There is also some confusion about creating the XNET data base when utilizing LabVIEW Real Time. I have created the database and alias utilizing the NI-XNET DATABASE EDITOR. I then deployed the alias to the RT Linux cDAQ 9135. I found information that states: "You have to configure the database with a VI before the rest of the application and then build the application and download to the cDAQ." Is this really required or can I use the XNET DATABASE EDITOR?
I'm hoping to find someone whom has created an EXE utilizing the cDAQ 9135 running embedded RT Linux and XNET CAN with a NI 9862 module and provide the steps required to successfully deploy and run an EXE utilizing the 9862 CAN module. 
This VI generates error 15 when run from LabVIEW project under realtime cDAQ 9135 with embedded Linux.
The target host with IP is listed in Target pulldown menu.
Doesn't work using IP by itself either! This is the first VI contained in the code above which is supposed to wait till the hardware is found before loading the driver.
I deployed the EXE with a 7 minute delay in a sequence statement creating a wait time so the CAN hardware could be detected before the Driver apparently gets loaded? I've done this several times in the past, however, this time I disabled the 1/3 octave band VI thinking maybe it is not compatible with a RT system? It still was not transmitting data. It was time for a break! When I got back, to my disbelief my app was transmitting data. I couldn't believe it, I thought maybe I had deployed the project VI by mistake. But after consideration I thought maybe it had started after a delay. I started the Linux RT system again with the EXE at startup and monitored the LEDs on the CAN module with a stop watch. The system started running, CAN lights flashing, after 1 1/2 minutes. I then enabled the 1/3 octave band VI, re-built, and monitored the system again. It starts and runs the EXE after a 7 minute delay before running the application to compensate for the CAN hardware/driver issue and then for whatever reason, it waits at least another 1 1/2 minutes and starts running the application as determined by the data transmission and flashing lights on the CAN module. After the 7 minute initial delay, the CAN 1 LED illuminates, after about 1 1/2 minutes the CAN 2 LED flashes and starts transmitting data. I'm now going to replace all the queues with RT FIFO's and monitor the results. I still need a mechanism for determining when the CAN hardware is detected as opposed to utilizing a delay 
Hello sfrosty,
Thank you for describing the problem you ran into, as well as your steps and the final behavior of the startup EXE.
I'll look into the document you mention in your first post to understand why it wasn't the solution. Out of curiosity, does the "Delay mechanism" generate an error even if it's the only code in the EXE?
Warm regards,
@sfrosty wrote:
I deployed the EXE with a 7 minute delay in a sequence statement creating a wait time so the CAN hardware could be detected before the Driver apparently gets loaded? I've done this several times in the past, however, this time I disabled the 1/3 octave band VI thinking maybe it is not compatible with a RT system? It still was not transmitting data. It was time for a break! When I got back, to my disbelief my app was transmitting data. I couldn't believe it, I thought maybe I had deployed the project VI by mistake. But after consideration I thought maybe it had started after a delay. I started the Linux RT system again with the EXE at startup and monitored the LEDs on the CAN module with a stop watch. The system started running, CAN lights flashing, after 1 1/2 minutes. I then enabled the 1/3 octave band VI, re-built, and monitored the system again. It starts and runs the EXE after a 7 minute delay before running the application to compensate for the CAN hardware/driver issue and then for whatever reason, it waits at least another 1 1/2 minutes and starts running the application as determined by the data transmission and flashing lights on the CAN module. After the 7 minute initial delay, the CAN 1 LED illuminates, after about 1 1/2 minutes the CAN 2 LED flashes and starts transmitting data. I'm now going to replace all the queues with RT FIFO's and monitor the results. I still need a mechanism for determining when the CAN hardware is detected as opposed to utilizing a delay
I've replaced the queues with RT FIFO's. The queues were causing the > 1 1/2 minute delay. It was a fluke that I discovered the time delay before the application started transmitting CAN data. Maybe there's a way to configure the queues so that they don't cause a delay in a RT system? I realize RT FIFO's are supposed to be more efficient.
With the RT FIFO's the application runs immediately after the initial 7 minute delay which allows for the CAN driver issue. However, now I have to examine my code in that with the RT FIFO's I'm experiencing data dropouts.
It's interesting to note that a simple program using queues runs immediately, which gave me the wrong conclusion in that I initially thought the queues were not an issue.
That's interesting. Do you happen to know after which 'size' of the program that uses queues does the problem start to happen? Can we perhaps have a reproducible code to test with, to further understand the problem?
Keep us posted!
@sfrosty wrote:
I deployed the EXE with a 7 minute delay in a sequence statement creating a wait time so the CAN hardware could be detected before the Driver apparently gets loaded? I've done this several times in the past, however, this time I disabled the 1/3 octave band VI thinking maybe it is not compatible with a RT system? It still was not transmitting data. It was time for a break! When I got back, to my disbelief my app was transmitting data. I couldn't believe it, I thought maybe I had deployed the project VI by mistake. But after consideration I thought maybe it had started after a delay. I started the Linux RT system again with the EXE at startup and monitored the LEDs on the CAN module with a stop watch. The system started running, CAN lights flashing, after 1 1/2 minutes. I then enabled the 1/3 octave band VI, re-built, and monitored the system again. It starts and runs the EXE after a 7 minute delay before running the application to compensate for the CAN hardware/driver issue and then for whatever reason, it waits at least another 1 1/2 minutes and starts running the application as determined by the data transmission and flashing lights on the CAN module. After the 7 minute initial delay, the CAN 1 LED illuminates, after about 1 1/2 minutes the CAN 2 LED flashes and starts transmitting data. I'm now going to replace all the queues with RT FIFO's and monitor the results. I still need a mechanism for determining when the CAN hardware is detected as opposed to utilizing a delay
CORRECTION: That should read "7 second" not "7 minute" 
@oscarfonseca wrote:
Hello sfrosty,
Thank you for describing the problem you ran into, as well as your steps and the final behavior of the startup EXE.
I'll look into the document you mention in your first post to understand why it wasn't the solution. Out of curiosity, does the "Delay mechanism" generate an error even if it's the only code in the EXE?
Warm regards,
The delay should have read "7 seconds" not "7 minutes"
