Number of cycles?

[Zourvan]

Dear pallen

Thank you for your ansewer.

[altenbach]

---

@Zourvan wrote:

... help me and let's know how can I calibrate my output (ready my output at fixed time).

---

So you want to introduce a fixed and defined delay instead of measuring the time? Sorry, your description is not very clear at all.

[Zourvan]

Dear altenbach

Oh sorry, I try to find general solution, indeed in COE(CAN over EtherCAT) before "sync time" done my process and send on BUS, if I couldn't done this timing my process fall.

[altenbach]

---

@Zourvan wrote:

Dear altenbach

Oh sorry, I try to find general solution, indeed in COE(CAN over EtherCAT) before "sync time" done my process and send on BUS, if I couldn't done this timing my process fall.

---

Sorry, it is still completely unclear what you actually want. Assuming your primary language is not English, maybe you could use google translate to write your question in your native language and then post it in English.

To delay an operation, you could use stall dataflow  (only available in relatively new LabVIEW versions) or an explicit equivalent.

[pallen]

I'm not familiar with COE, but I did find a couple of basic links.  

Drivers Required for CAN over EtherCAT

Setting Up EtherCAT on NI Programmable Automation Controllers

NI EtherCAT RIO: Deterministic Expansion for LabVIEW RIO Systems

You also might want to re-post your question on the hardware forum. 

AUTOMOTIVE AND EMBEDDED NETWORKS

When you  post, describe what you want to do, and what you have tried so far.  Most importantly, attach some code to your post! 

[Zourvan]

Maybe you right. but I have one easy question, how measure time elapsed on VI1?

[Zourvan]

thank you,

but I have some computing data, they need to ready before timing of "sync Message" . indeed I need to timing on my calculating data

[cbutcher]

This thread is getting a little long, so let me try and summarize whilst I make some guesses. Please tell me if any are close, or correct me as I go wrong. Numbers are used to allow referencing, not to imply any order or importance.

1. It's possible that you have some VI, and you'd like to know how long it takes to run. In this case, you should do as was shown a few posts ago, and use something like a flat sequence structure, two high-resolution counter VIs, and the subtract node. If the time is short, consider using a For loop in the middle and dividing the total time by the number of iterations. Be aware that LabVIEW will sometimes (often?) do clever things to make your code run faster, perhaps (?) such as realizing values are not being used (and not generating output arrays), realizing inputs are constant (and not repeatedly recalculating - at the very least, you should get some improvement from caching here even if LabVIEW doesn't do this), and so on. There are many threads (and altenbach has written in lots of them) discussing accurately profiling code.
2. You don't really care how long your VI takes to run. You just need it to happen at some precise time relative to some other things (this has recently sounded much more likely as you describe your problem in more detail). Consider the use of a timed loop, or if possible a Single-Cycle Timed Loop on FPGA, to regulate the speed of iterations. More information about your problem is probably needed to give good advice here.
3. You already have everything running, but VI-1 takes too long to run, and is messing up your application. You need to improve the performance of this VI. The profiling tools mentioned before (found under Tools > Profile > Performance and Memory) might be useful if you call lots of subVIs (including built-in VIs in e.g. vi.lib). If your VI-1 is small, you may prefer the same idea as in point 1, with flat sequence structures around elements you suspect are taking too much time. Usual suspects include (but are not limited to) file I/O, database accesses, hardware input/output (especially if there are many elements), and of course explicit wait elements. Showing your VI would really be fairly crucial to get significantly useful help with this, I would have thought.

[Bob_Schor]

---

@cbutcher wrote:

Showing your VI would really be fairly crucial to get significantly useful help with this, I would have thought.

---

The Original Poster keeps asking questions that seems to be about timing some section of (thus far unseen) code.  The Poster's knowledge of LabVIEW seems quite limited, with a major issue being that a number of LabVIEW Experts (many of them LabVIEW Champions) who have tried to help have apparently "not understood the problem" (or the Poster has not understood the explanation, which is certainly the case).

Given this lack of communication, it seems clear (to me) that someone needs to look at the Poster's code, get a better understanding of the issue, and based on this knowledge, make suggestions for alleviating the problem.  One way to do this is for the Poster to hire a local LabVIEW Expert and pay for the advice.  The alternative is to post the code here and allow the experts who have already tried to make "blind" suggestions get a fresh understanding of the issues and possibly provide targetted "solutions".  Otherwise, we (the Forum Users and the Poster) are probably wasting our time.

Bob Schor