probe with timestamp

[psychomanu]

Hi,

I would like to have a probe with a timestamp to see when the data passes. Then I can evaluate what parts of my code take the most time. Now I'm always messing around with 'tick count.vi' before and after and have to delete it afterwards. Any ideas?

Thanks in advance,

Manu.

[Michael Aivaliotis]

OOh! This sound like a cool challenge. Anyone got this coded yet?

[didierj]

Not quite a code challenge, I'v already done something like that, with quite some statistics (haven't the code anymore present, must have lost when I last changed job )

You'll still have to wire them into your code, but less complicated than with sequences. If you make the icon footprint small (e.g. a small clock, 8x8pixel), it won't disturb your code too much.

Didier

[Michael Aivaliotis]

I was hoping more for a custom probe a la LV7.0...

[psychomanu]

I was hoping more for a custom probe a la LV7.0...

2255[/snapback]

Exactly, a custom probe would be great,altough the previous suggestion is already helpful, I will try to make such a small footprint icon. Already much more convenient then what I do now. Thanks for the suggestions.

Manu.

[proximableu]

It seems that LV makes a temporary copy of CustomProbe (which you create) when you place one, and than deletes when you remove a probe from diagram. So, if you place Probe tvice in the same diagram, there is tvo SEPARATED reentrant probes, but where them stores, i did not find.. Therefore, you cannot place SAME probe on tvo places in the same time, therefore simple "delay" vi would not work. So, probes must to share one resource, file or pipe. It is a tricky one. Or, when you place two probes, you need to "rename" (in memory? ) one of them, so both have same name.. (Talking about two instances with the same name )

Any ideas? /ProximaBleu

[didierj]

I was hoping more for a custom probe a la LV7.0...

2255[/snapback]

:worship: Sorry for being not up-to-date, I'm still using Lv6.1

[xseadog]

:worship: Sorry for being not up-to-date, I'm still using Lv6.1

2261[/snapback]

Hi All

using cut and paste (what else)

have strung a probe example together using Danny and Helen's previous coding.

It provides a sound when probe recieves data and also recordes actual time to text log.

It is necessary to generate you own text log before hand for it to function.

Have funny & modify to suit your own appls.

:thumbup:

chow

xseadog

[xseadog]

Hi All

using cut and paste (what else) 

have strung a probe example together using Danny and Helen's previous coding.

It provides a sound when probe recieves data and also recordes actual time to text log.

It is necessary to generate you own text log before hand for it to function.

Have funny & modify to suit your own appls.

:thumbup:

chow

xseadog

2264[/snapback]

Soory all it appears had time out on upload.

Will try again

Download File:post-577-1097584426.zip

[proximableu]

BTW, I have did some probes project, for debugging applications, using Queries. It is working fine, have "console" debuging window, and works in DevSys as well in RunTime.. i had posted it in OpenG, but nobody was interested. Does someone will want to look at it? Works in LV6.1 too.

/PB

[proximableu]

here it is..

Download File:post-744-1097756016.zip

[Mark Balla]

Here is a custom time probe I created to help me see how much time a vi used up.
the first one attaches to an error cluster and the second uses a variant to attach to any data
type.

The probe has a enum selector with 3 choices Start, Time and Cycle
Start: starts the timer
Time: takes a time reading
Cycle: takes a time reading and restarts the timer

The probe will use a different timer for every ID number used.
(see demo.png).

Download File:post-584-1098000659.zip

[Mike Ashe]

The Probes contributed above are great. :worship:

I think it would be good to combine some of this with the Universal Probe that Jim Kring developed:

http://www.openg.org/tiki/tiki-index.php?p...iversal%20Probe

Combining timestamping with universality and a queued logging mechanism would be very useful.

[Mike Ashe]

Okay, here is the initial code. As I said, it is ugly, a hack and very minimal, but it gets the ball rolling and gets it out of my hands.  ....

:clock: Anybody got a little time to add a few features?

:beer: Cheers

3319[/snapback]

On another thread in the forums we ended up getting into some of the same stuff here. I don't like to cross-post, but I felt it might help a few more people see and also avoid some duplication.

Is there anyway to consolidate two topics into a single topic if their material has started to converge significantly? (Good question for the other Michael)

[Khalid]

BTW, I have did some probes project, for debugging applications, using Queries. It is working fine, have "console" debuging window, and works in DevSys as well in RunTime.. i had posted it in OpenG, but nobody was interested. Does someone will want to look at it? Works in LV6.1 too.

/PB

I downloaded this LVDEBUG utility. It's an interesting way to monitor data in real time.

I was however wondering what was the original intent of this utility as far as the DEBUG versus RELEASE builds go. I am guessing we don't want the data to get queued-up in the RELEASE mode; but to keep the VIs from breaking, we replace them with their RELEASE versions. Am I right here?

If so, then the DEBUG_TX_R.LLB should only have dummy VIs; but it appears to have the same exact VIs as the DEBUG mode i.e., the Queues, etc. So, even in the RELEASE mode we are queuing up the info' (-- but just not displaying it since the DEBUG_RX_R.LLB only has a dummy VI). Shouldn't we also have dummy VIs for all the VIs in the DEBUG_TX_R.LLB as well?

I have also emailed proximableu directly.

Any input/ideas on this would be much appreciated.

-Khalid

[psychomanu]

Hello,

I would like to see a probe with a timestamp to see WHEN data passes instead of the data itsself, for easy evaluation of the time spent between two points in the code. Or does anyone know an easier way than adding a tick count before and after and calculate the difference?

Manu

[hooovahh]

I think the easiest way to find out how much time it takes for a set of operations, is to use a VI global. You write a small VI which just works like a stop watch, with start stop and reset. This VI could have an error clusters in it to preserve data flow. You then put this in before your calculation and tell it to start, it gets the tick count and puts it in a uninitialized shift register. Then you do your calculations, and at the end put down the same VI global with a stop action which gets the tick count and subtracts it from the shift register which contains the original time stamp.

A quick and dirty way is to use a flat sequence structure, have the first case get the tick count, then the second is the actual work, then the 3rd case is to get the tick count and subtract it from the first.

[LAVA 1.0 Content]

The solution is quite easy, you make a normal probe and display the current time when the probe is executed.

The problem is that I think that probes are not time critical for the LabVIEW compiler and parallel processes might continue to run while the probe evaluates, so I would keep the probe as simple as possible.

Ton

[Yair]

Sounds like a good task for JKI's right click framework - you select a block of code, choose "add timing" and it wraps it in a flat sequence with timing code.

[Minh Pham]

QUOTE (psychomanu @ May 27 2009, 09:27 PM)

Hello,

I would like to see a probe with a timestamp to see WHEN data passes instead of the data itsself, for easy evaluation of the time spent between two points in the code. Or does anyone know an easier way than adding a tick count before and after and calculate the difference?

Manu

Back to the original question. It is a probe with data and time stamp is what you are after, right?

I would create my own probe for this purpose. To do this you just 'right click' on the wire you want to place a probe then select 'custom probe>>new'

give it a filename and location then Labview will create an 'probe' vi for you with the data type of the wire you right-clicked on.

In this 'probe' vi, you need to add a get current time function and an indicator for that. Create an indicator for the data as you need to see the data on the probe as well. resize the front panel to make it look nice & clean, add color of you want.

Do the same with other type of data wire for their custom probe with timestamp. then jusp drop the probes in ur vi and run good luck

Then you will have something like this:

[Cat]

QUOTE (Yair @ May 27 2009, 12:59 PM)

Sounds like a good task for JKI's right click framework - you select a block of code, choose "add timing" and it wraps it in a flat sequence with timing code.

I like that idea! :thumbup:

[Yair]

QUOTE (Minh Pham @ May 28 2009, 10:24 AM)

I would create my own probe for this purpose.

A more interesting version of this would be if you use a LV2 style global to remember the time of the last probe and then subtract to show the difference. Just note that this will only work if you have two such probes. If you have more, you might run into race conditions. Also, using the Tick Count primitive for this is generally better because it has a higher resolution.

QUOTE (Cat @ May 28 2009, 02:02 PM)

I like that idea! :thumbup:

So does Jim, apparently.

[Minh Pham]

A more interesting version of this would be if you use a LV2 style global to remember the time of the last probe and then subtract to show the difference. Just note that this will only work if you have two such probes. If you have more, you might run into race conditions. Also, using the Tick Count primitive for this is generally better because it has a higher resolution.

Ofcourse Yair, but i just want to demontrate the idea rather than do the whole thing for the questioner.