Terminal connection to cRIO target

[deepforge]

I'm new to LabView Real Time, and have not become familiar with all avaible tools in 2009.  I'm making improvements/modifications to an application developed by another engineer under 8.x.  As a consequence of the upgrade, our application no longer works correctly.  I've tried instrumenting the VI to manipulate the USER1 LED as an indicator, but nothing happening.  I'm used to having some mechanism for terminal connection into the target.  For example, in the past, I've used WindView with VxWorks for this same reason.  However, I don't have a license for Wind River developer tools now, and don't even know if this version of VxWorks (under LabView) support WindView.

My question: is there a combination of tools and target configuration to get a terminal connection to the target OS (not just the RS232 console output on the RIO)? 

[AdnanZ]

I am not sure about accessing the OS on VxWorks through terminal.

But, I am wondering why you are not able to manipulate the User LEDs on the cRIO. Have a look at the following KB article and let me know if you have followed the steps for the cRIO. Trying it on a separate application first would be best.

How Do I Access the User LEDs On My Compact FieldPoint or CompactRIO controller?

[deepforge]

Afternoon, Adnan.  Yes, the example given for the cRIO in the article is exactly what I did for the USER1 LED.  However, the application must have been loaded properly in order for it to turn the LED on.  My inquiry about the terminal tool was to determine what was to inspect the state of the target and determine if my app had actually been loaded in the absense of an LED.  I gather that this facility is not available for a LabView RT target, so I will try some other troubleshooting technique. 

[Tanya_V]

Good afternoon!

If we get a bit more information about the actual problem you are encountering we could try attacking it from a different angle.

1. What hardware are you using?

2. What version of LabVIEW do you have?

3. What version of NI-RIO do you have installed?

4. Can you see your cRIO in Measurement and Automation Explorer (MAX)?

5. Are you getting any errors building or deploying your application?

6. Or, are you deploying successfully and not seeing any activity or just unexpected behavior?

By knowing a bit more about the errors you are encountering, we can look into a way to debug the application.

Take care!

Tanya V

[deepforge]

I've attached a screen shot of MAX with my target software and hardware information.  I'm currently using LabView 2009 SP1 + FPGA and RT modules.  As you can see, MAX sees the cRIO fine.  I created a new project today with a very simple counter program to test the target, which builds and deploys.  However, despite the fact that my build spec should put the startup.rtexe in /c/ni-rt/startup, it puts in /ni-rt/startup, so the startup VI never runs.  Even if I move startup.rtexe and alias file to /c/ni-rt/startup manually using FTP client, it still won't start.  My ni-rt.ini file is also attached to demonstrate configuration.  Why is LabView deploying to the wrong destination anyway?

I have to say that I am getting a little fustrated.  My original request was simply to ask if there was a way to connect to the RTOS via some terminal program to inspect the environment, task stack, etc.  That should be a simple enough feature.  Even simple boot loaders have such capability.  But if that isn't the case on a VxWorks/LabView RT stack, than a simpler question is this:  what tool do I need to use to point the target's LabView runtime at an executable on the filesystem and simply command it to "load into memory and execute"?

[Tanya_V]

The differences you see in the paths should not be causing the problem since they are effectively equivalent. However, have you made any manual changes to the ini file? Or have you tried reformatting your controller?

You can use Console out on the cRIO to help diagnose errors. The following KnowledgeBase article (Usage of Console Out Switch on cRIO, sbRIO, cFP-21xx, and cFP-22xx Controllers) explains how to use this functionality.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YIMICA4&l=en-US

You can also debug the executable directly. The following help documentation explains how to do this.

https://www.ni.com/docs/en-US/bundle/labview-real-time-module/page/debugging-a-stand-alone-real-time...

Hope this helps!

Tanya V

[deepforge]

I'm closing this request without solution.  I eventually fixed my problem by working under another SR and support person.  It should be noted that no solution was actually provided here as the originally question (how to connect to a cRIO via terminal connection) went unaswered.  Because NI 1st level support staff have limited breath of experience in real-time embedded development, it may not be obvious how important the ability to connect directly into a target is.  Many, many ROTS/micrOS - embedded Linux, VxWorks, even boot loaders like Red Boot - have this capability for a reason;  there are just some issues with application and system configuration debugging that require it no matter how advanced the host tools are.

Incidentally, your last response was wrong on both accounts.  First, the appears of the superfluous directory was significant, and a sign of a bigger issue around corruption during upgrade from 8.6.1 to 9.0.1.  The fix for this issue was to reformat the disk completely and reinstall target software stack.  Second, remote debugging was not an option as the system corruption prevented download of the FPGA vi and execution of stand-alone applications - even through remote debugging.  This goes back to my initial question as LabView tools on the host do no good whatsoever to troubleshoot a problem or even tell if an application is running on the target if no application can be executed on the target; it's a catch 22.

This is a fundamental difference between the original target market for LabView (data acquisition FROM a device TO a host computer) to the real-time embedded space of instrumentation and control ON the device itself.  NI has created a solution to do quick prototyping for RT and embedded systems when all is going well.  However, they need to provide some basic facilities for WHEN issues arise (and they will).  I suggest you open shell access to VxWorks and cross license WindShell, giving your developers the ability to terminal in, if you want to be competitive as a maintainable platform for commercial products.

[Spex · Accepted solution]

Hi deepforge,

The console out functionality on CompactRIO is not uni-directional.   Most National Instruments' customers are not familiar with the underlying VxWorks interfaces, but when using Hyperterminal or another serial terminal console, you can type commands into the VxWorks Console.  For example, if you think your application is not loading, you can use the "moduleShow" command to show loaded modules on the OS and the "ld" command to load your application manually.  It is helpful to turn on the "echo" feature on the terminal so you can "see" what you are sending to the console.

The console out feed should also indicate some status as your application attempts to load.  Are you getting any indication that the application is beginning to load and failing?  

Does your startup application use the serial port?  Small chance of this being your actual issue, but I'll throw it out there.  I have seen startup applications in the past that fail to appear to work because the Console Out functionality is enabled, but the application is tryting to write to the serial port.   Unless errors are handled correctly, an error from the serial port calls could be causing your application to behave unexpectedly.

Regards, 

[Spex]

Deepforge,

I apologize for the difficulty you've experienced today.  I opened your post earlier, but I had to go to a meeting before I could reply.  I then posted without refreshing the thread to see your latest post (that is why the post is dated after you "closed" the issue).

I'm happy to hear that you were able to resolve your issue.  Personally, I've never used WindTerm, so I can't be sure that the terminal connection I described is exactly what you need, but I hope you will still take a look at it.

National Instruments takes upgrade issues very seriously.  I encourage you to continue working with the Applications Engineer you called to document the issue you saw to see if we can reproduce and correct to eliminate the possibility of someone else running into it.

Regards,

[deepforge]

Spex,

Thank you for your informative reply!  This was exactly the information I was looking for when I posted this thread.  Yes, moduleShow is a VxWorks command, which indicates to me that the initShell was done in the kernel to turn on support.  The fact that I can simply connect via Hyperterminal is a huge benefit, but I didn't make the assumption outright as the cRIO-9014 RS232 is documented as being a "Console  Out" port that only posts IP address and firmware version of the device.  I'll give imput a shot.

I apologize if I seem fustrated, but this should be expected when questions like mine asked of multiple support technicians is only met with a response that basically asks the question "why do you need that"?  The answer may not be apparent without sufficient embedded development experience on multiple platforms to draw on, but there really is no good way to answer questions like yours (i.e., in what state is the application and system really, and why?) from host tools if the app to perform remote debugging on won't stay loaded.  As it turns out, my startup app wasn't loading because corruption in the LabView RT software stack, but the failure wasn't being reported in error log and remote execution wasn't working for the same reason. In addition, it took longer than it should of to identify the corruption because MAX reported target software and versions as "working properly", and I had no way of directly inspecting the system to confirm/deny that fact.

Thanks again for your answer.

Shawn