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.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
debugging custom devices
KaBooOoom
Member
09-29-2009 10:07 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hi all!
I have a question concerning custom devices. If i developp a custom device, is it possible to debugg this vi while Veristand is runing ? Or the execution of the custom vi will stop veristand? When you deploy your system definition to an RT Target, is it an executable that is deployed ?
I f it is so, I guess it's not possible to depploy your custom vi without stopping the exectuion of veristand ... Am i wrong ?
Thanks for your future answers ...
Jarrod_S.
Active Participant
09-29-2009 11:01 AM - edited 09-29-2009 11:01 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
The VeriStand Engine is constantly running on your RT Target as a Startup Executable. When you deploy a System Definition File to the target, you are deploying settings in the form of configuration files, model DLLs, Custom Device VIs, and so on. You aren't actually deploying or changing the core VIs running on the RT Target. This is different from the standard LabVIEW RT paradigm.
One good way to debug a Custom Device running on an RT Target is to use Remote Front Panels. You set it up just like any other RT Target. When you have that enabled, you can connect to your RT Driver VI (or one of its subVIs) using the following name format: <library name>.lvlib:<RT Driver VI name>.vi:1. The ":1" at the end denotes the reentrant instance of the Custom Device Driver VI to connect to. It will standardly be one unless you are running multiple instances of a Custom Device in one System Definition File. In that case, it will likely be 1, 2, 3, etc.
Message Edited by Jarrod S. on 09-29-2009 11:01 AM
Jarrod S.
National Instruments
National Instruments
LDBM
Active Participant
11-01-2011 04:50 PM - edited 11-01-2011 04:53 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Is the above debugging technique still up to date please?
Thx.
L
PS: above link to Remote Panel is broken.
LDBM
Active Participant
11-03-2011 01:30 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
So after talking some more with NI, here is what it transpires:
- there is no way right to debug a custom device running on a RT target the same way you would do for a LV-RT VI... that is you can't see the code run.
- one mitigating option is to use this tool to send messages to the console.
Jarred, how does it jive with your proposed answers above? Do I understand that from what you are saying it is in fact possible to debug a custom device or not?
Thx.
L.
Devin_K
Active Participant
11-03-2011 05:38 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
As the name implies, Remote Front Panels are a way of viewing the front panel of a VI in a remote web browser. You will be able to see the front panel of a running VI, but won't be able to see the block diagram or use any of the LabVIEW debugging features with it. I have never used RFPs to debug custom devices as Jarrod described, but I suppose it's possible.
For most of my debugging, printing to the console or logging to disk has been sufficient. You can read more about debugging in the Custom Device Developers guide, starting on page 64.
