remote debugging is useless

[Paul_Knight_Lockheed_Mart]

I do not know what NI was expecting to accomplish from remote debugging, but from my point of view what is offered is useless.  I followed the white paper about getting started with LabWindows/CVI Remote debugger.  I got the application running on the debuggee and the debugger on my development computer says it is running on the debuggee ip address.

However, from the debugger you do not see any of the front panels, so no user events can be generated from the debugger.  I can't reach the code that I want to debug unless I go to the debuggee and press the front panel button.  If I have to walk back and forth between the debuggee and the debugger, I would be better off moving my development enviroment to the debuggee.

A better solution would be to get a debug license for the target computer, load pcAnywhere on both the target and my development system.  Then you can sit at your development system and debug directly in the LabWindows/CVI enviroment.

[menchar]

I sorta agree.  I have used remote debugging to solve the problem of not having a full development CVI installed on a target.  I have a CVI FDS on a laptop, and I walk up to the target system (a test station) and cable up directly then run remote debug.   I am able to manipulate the target app GUI directly 'cause I'm right next to it.  You can try to do it with remote terminal on Win32 machines, but I agree it's easier if I'm right there.   In fact, I've never used remote debugging except for the scenario I just described.  And it can be frustrating coordinating all the arcane stuff you've got to do to get it going - I usually wind up rebooting a lot, restarting CVI, etc.

Menchar

[scomack]

So all this time I've been using it to debug has been wasted?

When the debugee has no CVI on it, it comes in real handy.

But that's just from my point of view.

Thanks, NI.

[Paul_Knight_Lockheed_Mart]

As long as you are near the debuggee and can enter user events on the front panel, it works ok.  But if you are in another building or another country, then there are better solutions.

[OVR_CZ]

Hi,

    For my,remote debugging is very nice and useful feature.

    It is nice and easy to load debugee version of app, configure remote adres, and run debug.Without instalation of full    

    Development enviroment(withh liccense aktivation) always when i need find litle bug.

    Typical situation when i use remote debuging:

    1)When i need litle debuging, on target PC mashine with NI Cards +special HW

    2)When there is a problem specific for Win version(or settings), or PC hardware(specialy notebook)

       (on development system, all works ok, so i need debug on target PC)

   When i need remote control of app, i use something like UltraNC or Windows remote Desktop SW.

[mvr]

While I agree you would not want to do long sessions of extensive debugging using the remote setup, it is great when just hooking up for a quick look at something running on a target system that does not have the development environment installed. I don't use this feature a lot, but when I do it is a real life saver.  I would dislike not having it available when needed.

[Paul_Knight_Lockheed_Mart]

I am not in favor of removing it either, but I would like to see them improve on it.

[LuisG]

Hi Paul,

I agree that remote debugging is useless if your application has a UI and you cannot interact with the UI at your local station. The idea behind remote debugging is that you would also be using something like Windows Remote Desktop/Assistance to connect to the remote computer so that you can interact with the UI.

Of course, if you're able to install the CVI ADE in the remote computer, and you can still reproduce the problem that you're trying to debug when running the source code from the ADE (which is not assured, since some bugs can be very fickle) then you probably have no need for remote debugging.

Luis

[menchar]

The problem with installing the CVI IDE on every target is licensing.

When you have a large number of target systems, all running the CVI app, and all of which may produce unique problems requiring debugging, what do you do?  Buy a dozen copies of CVI FDS, one for each target?  While I'm sure NI thinks this is a fine idea, I don't.

Furthermore, having the IDE installed on every target can mask poorly prepared distribution kits.  Resources left out of the distribution may in fact be on the target due to the IDE's presence.  If you then ever need to distribute onto a target without the IDE, you'll discover the hard way that everything required wasn't in the distribution 😉  Then you realize that if the IDE versions weren't identical, your deployed application was depending upon multiple versions of supporting resources that may be generating version-dependent errors 😉  In short, you can wind up with a deployment nightmare.

I've had trouble getting the TCP link between the target and the debug host to fire up and/or restart properly .  I've had trouble when trying to restart the debug session on the host, I always seem to wind up having to restart everything on the target and the debug host.   And if you're also using remote terminal / PC anywhere or some such to see the target GUI from the debug host then it's even more complex.  It's flaky enough that I use remote debugging only when I absolutely have to. 

Menchar

[Paul_Knight_Lockheed_Mart]

I know it is expensive to put a license on every machine.  In previous lifes I had machines in Mexico and Taiwan, so I would use pcAnywhere and use the machines license to debug.  The problem is pcAnywhere can be a security risk from IT's point of view, so my IT group is not very supportive of loading pcAnywhere on machines here.  I was hoping that the LabWindows/CVI Remote debugger had some of the functions like pcAnywhere.