From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
XNET CAN EXE WILL NOT RUN AS STARTUP
@sfrosty wrote:
@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.
Delay should read "7 seconds" not "7 minutes" 
It appears I jumped the gun? The RT FIFO's also cause the same approximate 1 1/2 minute delay before the CAN module starts transmitting data as did the queues. When I first configured the system using RT FIFO's in place of the Queues, created the EXE, and deployed the application as startup, the CAN channel indicated it was transmitting data immediately as witnessed by the blinking LEDs on the CAN module. It did start transmitting immediately, but there was no data being received by the receiving cDAQ, only timestamp, ID (not sure if sequenced correctly), Type & Echo, but no DBL data values; all zeros. I then experimented with setting the RT FIFO xmt & rcv VIS timing inputs. Setting the timeout inputs to -1 on the receiving RT FIFO's in the cDAQ 9135 Linux application now caused all the data values to be received as specified.
Conclusion: there is some type of initiation going on in the background of the cDAQ 9135 Linux chassis which causes a delay when streaming DBL values through CAN module 9862.
I am utilizing 4 read FIFO's and 5 write FIFO's in my program. Setting the timing inputs to zeros on all FIFO's causes the CAN module to transmit immediately, but there is no DBL data. Setting the 4 read FIFO's to -1 causes the approx. 1 1/2 minute delay with all DBL data received as expected.
I use two Boolean FIFO's to switch a case structure between the acceleration and sound data being transferred. It doesn't appear that I need to set the wait time on the Boolean inputs to -1, but I set them to -1 to increase confidence. I attached an EXCEL sheet that describes the FIFO timing input assignments.
I'm wondering if CRIO has this same issue? 
@sfrosty wrote:
@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.
CORRECTION: "7 minute" should read "7 seconds"
@sfrosty wrote:
@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"
The "Delay mechanism" does not generate an error if it's the only code in the EXE; reason being the debugger displays: "No debuggable applications or runtime libraries found"! I tried several times - rebooting and restarting. The debugger indicates exactly the same message when placed in a case statement before my code and the code does not run.
The error it generates when run from the project either alone or at the beginning of my code is: "Error -2147467261"
If I take the "Delay mechanism" out of my code and replace with a wait 7000 ms wait command, my code executes. Of course now having a 7 second delay and a 1 1/2 minute delate until the CAN module starts transferring data.
@oscarfonseca wrote:
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!
If I'm seeing correctly, it just happens when the program has more than 4 RT FIFOs, 2 DAQmx tasks, 1 XNET session, and 1 TCP connection?
Perhaps benchmarking everything that happens before the While Loop that contains the XNET VIs execute can give you more clues of how much time is the code taking to startup, once the RT application is called.
I believe that means that the RT FIFO is making this 'delay' because it's waiting for data to be enqueued. When you set the timeout to zero, it doesn't hold the while loop from executing, and sends the empty values you talk about. Therefore, I'm inclined to think one of the other loops is holding back the data for this delay period. Maybe the SVT Octaves Analysis? In which case I wouldn't be surprised with the behavior, as the processor is performing those operations, and it can't send the data but until after it's done computing them. I remember you enabled and disabled these functions before, with them affecting the response time.
@oscarfonseca wrote:
I believe that means that the RT FIFO is making this 'delay' because it's waiting for data to be enqueued. When you set the timeout to zero, it doesn't hold the while loop from executing, and sends the empty values you talk about. Therefore, I'm inclined to think one of the other loops is holding back the data for this delay period. Maybe the SVT Octaves Analysis? In which case I wouldn't be surprised with the behavior, as the processor is performing those operations, and it can't send the data but until after it's done computing them. I remember you enabled and disabled these functions before, with them affecting the response time.
I'll have to look back through my messages, but from what I remember, I was able to rule out the SVT Octave Analysis. Evidently, when running from the project, the processor performs the operations beforehand? The CAN module outputs the data seemingly immediately when running from the project. Oh, I went back to using the queues, for whatever reason the software couldn't keep up with the hardware using the RT FIFO's and would shut down my accelerometer data reading loop. The easy fix was to go back to the queue app. I read about the advantages of using RT FIFO's but can't see any in my case. Thanks again for all your help!!!! 
