Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Debugging Pre-Launch-Init

Curious as to how others are debugging VIs like "Pre Launch Init". With this being a Shared Clone, I cannot set a break point inside the code. I can change the execution mode but that means I have to change it for the base class, etc. Am I missing something here?

Thanks,
Eldon

0 Kudos
Message 1 of 13
(5,157 Views)

If on a desktop target, you can drop in calls to the Desktop Execution Trace Toolkit (to add trace strings, for example), and use that tool to see what is happening inside calls to shared clones.

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 2 of 13
(4,025 Views)

Unfortunately, I am on a cRIO.

Thanks,

Eldon

0 Kudos
Message 3 of 13
(4,025 Views)

You can drop in calls to output trace strings to file, or a network protocol such as Syslog or UDP.  Same idea as DETT, just a little more manual.  I tend to use Syslog, since there are already some nice collector implementations out there, and we have a syslog library that's pretty simple to use (vipm://nise_syslog?repo_url=http://ftp.ni.com/evaluation/labview/lvtn/vipm).  YMMV.

You could try calling a non-reentrant subVI that you set a breakpoint on, and pass the data you want to probe through there.  (this will hurt if you have multiple instances of the actor, and thus are not sure which clone called your function).

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 4 of 13
(4,025 Views)

Eldon wrote:

With this being a Shared Clone, I cannot set a break point inside the code.

Sure you can.    Set a breakpoint on the master copy and when you run the breakpoint will be on the shared clone, pausing it and openning the diagram.  You can then enable "Retain wire values" and unpause. 

Another method is to pause in the caller and "Step" into the shared-clone subVI.  Or use "SubVI Node Setup.."

Added later: not sure you can on RT.

0 Kudos
Message 5 of 13
(4,025 Views)

You can not set break points because you are not given the option. The tool bar does not even present these options nor do the context sensitive menus. You cannot even step into these VIs.

Later,
Eldon

0 Kudos
Message 6 of 13
(4,025 Views)

My tactic for debugging Pre Launch Init is to launch a data logger and give the Enqueuer to my actors and have them right to the logger in Pre Launch Init. I usually logger the class name and the error status, code and text. I also put a message in about which VI the data is coming from.

I do this all over the place on my cRIO RTEXEs.

Good luck.

Casey

Casey Lamers


Phoenix, LLC


casey.lamers@phoenixwi.com


CLA, LabVIEW Champion


Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!

0 Kudos
Message 7 of 13
(4,025 Views)

If you don't mind your Pre-Launch code being non-reentrant, then you can have a parent actor class (below Actor.lvclass itself) have a "Pre Launch Init" that just calls "Pre Launch Init NR", a non-reentrant version.   Each child can then decide if it wants this method to be reentrant or not by overriding one or the other (and it is quick to switch, since you just rename the method).

0 Kudos
Message 8 of 13
(4,025 Views)

You could also try the RT ETT to give you similar info as you would have with DETT.

Kind Regards,
Thierry C - CLA, CTA - Senior R&D Engineer (Former Support Engineer) - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 9 of 13
(4,025 Views)

OK, I see everybody has good ideas but I do not see anything that lets you easly set break points or step through the flow of the code. I have come up this idea, take the code that would be in the Overriden VI and put it in it's own VI. Since the execution of this VI is not a clone then this will allow one to set break points, etc. Now when you are done debugging, switch the execution mode to "In-Line" and the over head of being a seperate VI disappears. Now, this does not stop blocking if you have multiple callers of the AF but if you are stopping execution of the code, you most likely are not worried about a RT problem.

Comments?

Later,

Eldon

Message 10 of 13
(4,025 Views)