Did anyone used Execution trace toolkit ??

[KaBooOoom]

Hi all!

I try to debug an RT application using Execution trace toolkit, and i wanted to tell everybody this tool is unuseable !!! It's impossible to debug anything with such a tool, and i wander how it's possible to even sell this tool !!! I have a 3.2Ghz with 1Gb RAM and this program takes 100% CPU during 2mn to refresh the screen !!  Everytime you make a zoom, move the scrollbar...  it takes more than 2mn !!!! And no : I didn't parameter a buffer of 5 000 000 (but 200 000, so approximatively 3ms of trace) !

So my questions are the following:

1) Does anyone have the same problem ?

2) Is there an other tool able to read a .log file ?

3) Is NI working on a better version for this tool ???

Thanks !  

[boltzmann]

What version of LabVIEW are you using? If you are using 8 or 8.0.1 make sure you mass-compile the trace toolkit vis in the project and vi.lib\addons directory. If you haven't it takes forever to do anything. Otherwise I use the tool quite often and find it very useful for timing visualization.

[KaBooOoom]

Hi ! And thanks for your answer...

Effectively i use Labview 8.0 ! So i tryed to mass compile the vi.lib\addons  directory, but it didn't improve the performance of the tool (it always takes an hour to open a session and to move in this session). You wrote i should "mass-compile the trace toolkit vis in the project" ... hmm what do you mean exactly ??? Can you explain me the operations to follow ?

Thanks ! 

[Darren]

He was probably referring to mass compiling the [LabVIEW]\project\_tracetool folder.

-D

[KaBooOoom]

Hi Darren!

I mass compile the directory : National Instruments\LabVIEW 8.0\project\_tracetool as you wrote. And it works a lot better ! Thanks for your answer , NOW i can use this tool ! Finally its seems to work better than i expected, sorry for the bad words ... !

[insane$object]

Yes, I agree.  The trace execution toolkit is painfully slow.

For now; I've been grateful that such a tool exists as it did help identify a priority inversion issue caused by a resource contention while accessing different NI-CAN ports on the same card (but from different threads).

I understand that this tool is a 1.0 release and expect it to improve in future releases.

If the responsible NI developers do monitor this discussion board; I do have a few suggestions to improve this product:
- Improve the responsiveness of zooming, scrolling, etc.  It is extremely slow.
- Add the ability to find user events, and possibly any transition event; i.e. when a particular thread executed without having to scroll through the data.
    - Possibly a jump to next / previous transition.
- Add the ability to create "tags" for user events so I don't have to keep looking up what event XX means in my code.
- Add the ability to intelligently "inspect" the timing to highlight potential issues; high processor usage; unexpected thread delays, etc.

[KaBooOoom]

Hi insane !!!

Hum, I agree, a lot of things could be done in order to ameliorate this tool !

 I know it's not the subject of this message, but what you wrote interrest me a lot ! Your problem with priority inversion while accessing NI CAN port on the same card (in parrallel thread)... It's exactly what i do, and i do have the same problem.... right now i don't know exactly from where it comes (cause i also use AI, DI, AO, DO...) but if you can tell me your solution, maybe it could help me... thanks in advance... !

[insane$object]

Hi KaBooOoom.

Though this is getting off topic; the issue with NI-CAN priority inversion was resolved by using multiple CAN cards.  According to the developers at NI a two channel CAN card (I use the PXI-8464) has the same onboard embedded processor (386) and shared memory resources as a single channel card.  Though the series2 cards were redesigned to improve throughput there are still some issues such as accessing the drivers from multiple threads.

I used the trace execution toolkit to identify the problem, but had to use internal resources within the NI-CAN group to find a resolution.  Their proposal was to use multiple cards, and use only 1 channel on each.  Yes; this can be an expensive proposal; particularly if you have to get a larger chassis as was my case.  To get all of the cards working together "properly" (as their timebases are not sync'ed to RT); I had to use a pair of timers on a DAQ board which I happen to have in my system.  DAQmx was used to route a shared clock across the RTSI backplane and also act as a synchronized time source for a few timed loops that I use to service CAN.  You can PM me directly if you would like to discuss this further.

Thanks