Can the NI know its being debugged?

Jeff

So . . . run with me on a flight of fancy here. Is it possible for an NI master to know that it is being debugged? I'd love to set up my code so that if I'm in debug mode, it knows it, and it doesn't do my tp feedback, which would make stepping through code so much easier. I'm thinking something like

if (nDebug)
{
    tp_fb()
}

Any ideas? I thought maybe I coudl tie a variable to the online/offline events of the NS Studio application, but that wouldnt' just be debug mode, that would be any time the NS Studio app connects . . . . which might not be horrible.

J

DHawthorne

Interesting idea. You could trap the online event of the virtual device NS uses: 32001 (assuming it's trappable, but I don't see why it wouldn't be). NetLinx Diagnostics uses 32002.

Marc Scheibein

DHawthorne wrote: »

Interesting idea. You could trap the online event of the virtual device NS uses: 32001 (assuming it's trappable, but I don't see why it wouldn't be). NetLinx Diagnostics uses 32002.

Never observed in detail, but the nature of the range 32001...32767 is that "ungonfigured" devices will automatically set there with addresses assigned automatically by the master. This means if you have .i.e an unaddressed NXM-COM2, it may become address 32001 and Studio may get 32002 if it is launched as second. But after the next reboot, both may get new addresses. So if it WOULD be possible to detect Studio, it may become difficult to find it (because it is also possible to connect two or more Studios the same time).....

Jeff

The other option I figured would be to just set a variable nSkipFeedback that is always 0 and is never touched during the program. then you have

if (!nSkipFeedback)
{
    tp_fb() //My function for TP Feedback
}

And if you're debugging you can just set nSkipFeedback to 1 and it'll be much easier to step through code.

In case you're wondering why I'm trying to do all this, its because the primary objection to doing feedback in a timeline or in define_program that I'm getting from my coworkers (see the thread about device combines and arrays) is stepping through code gets harder, so if I can eliminate that problem maybe I can win the array fight.

J

Hedberg

Probably just having a flag variable you can set and unset is the better solution, but if, for some reason, you needed to have your code automatically identify when debug was running, I think you could do it. If you start a telnet session to your master and turn 'msg on' , when debug is started in Studio, a message appears in the Telnet window something like:

CIpDiag::OpenSession 32001:1:1

Likewise "CloseSession"

I have only been able to generate these messages by opening and closing debug.

So, if in your code you initiate an IP client to the localhost telnet server (127.0.0.1 port 23) and do 'msg on' in that IPclient session, you will get a string event when you open or close debug. You will also get a string event for that IPClient for all your strings to zero, which may be a killer in your case.

I just tried this, and it does work.

DHawthorne

I forgot the virtual device range was dynamic ... I would agree it's probably best to set a variable. That's what I typically do; one rather big advantage is that you can then turn on and off debugging messages by module instead of everything at once (which can be nuts on a big project). As I mentioned in another thread, I like to attach a vrtual device to my modules to interact with them; I always include a handler to turn such a debug variable on and off via telnet (which greatly facilitates remote debugging). I also put a virtual device in my main program, so I can query system status as well remotely, without having to do anything but make a telnet connection.

Dan Colegrove

Another option

In our code we usually have a virtual device for various devices or functions that we use and we like to setup a command event for the virtual device for turning on and off a debug variable. This way we can send a command to a virtual device and turn on debug for that device or code function. The person trouble shooting does not need to have the correctly compiled code because they are not trying to turn the variable on or off directly through studio. You don't even need studio to do the debugging. You can use telnet and that's it. All you need to do is turn on messages for the telnet session and you need to know is the virtual device you want debug info from.

DATA_EVENT[vdvSomeDevice]
{
  COMMAND:
  {
    IF(FIND_STRING(DATA.TEXT,'DEBUG 1',1))
    {
      nDebugThisDevice=1
    }
    IF(FIND_STRING(DATA.TEXT,'DEBUG 0',1))
    {
      nDebugThisDevice=0
    }
  }
}


BUTTON_EVENT[dvSomeTP,nSomeBttn]
{
  PUSH:
  {
    IF(nDebugThisDevice)SEND_STRING 0,'Your Debug Text here'
  }
}