LabVIEW
Number of cycles?
@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.
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!
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.
- 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.
- 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.
- 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.
