LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Number of cycles?

Dear pallen

Thank you for your ansewer.

0 Kudos
Message 21 of 29
(1,067 Views)

@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.

0 Kudos
Message 22 of 29
(1,059 Views)

Dear 

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.

0 Kudos
Message 23 of 29
(1,053 Views)

@Zourvan wrote:

Dear 

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.

 

0 Kudos
Message 24 of 29
(1,032 Views)

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! 

 

  

 

 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
Message 25 of 29
(1,028 Views)
Maybe you right. but I have one easy question, how measure time elapsed on VI1?
0 Kudos
Message 26 of 29
(1,009 Views)

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

0 Kudos
Message 27 of 29
(1,006 Views)

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.

GCentral
Message 28 of 29
(995 Views)

@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

0 Kudos
Message 29 of 29
(984 Views)