ddc 1553 card

[sikku]

i have ddc153 card .it has two channels chA and chB.here i am doing communication with seeker computer for every 25 milli sec.but communication is not happening(not updating for every 25ms).

[RavensFan · Accepted solution]

Do you have a question?

Why don't you post what you've done so far and tell us where it is not working right.  That is the best way to get help to help you solve your problem.

[sikku]

this is my vi

[Heesub]

You must use Case structure instead of Event.

In Event, source code can work 1 time when event you set is occured.

But it's possible to work consecutively in Case.

[Dennis_Knutson]

---

@Jemin wrote:

You must use Case structure instead of Event.

In Event, source code can work 1 time when event you set is occured.

But it's possible to work consecutively in Case.

---

???

[Dennis_Knutson]

---

@sikku wrote:

this is my vi

---

What is the rate that you actually see with no front panel activity? I don't have any of those subVIs. Do they take less than 25ms to execute?

[sikku]

how i can use case instead of event.before that i want send command word to subsytem then only i got status from subsystem but it not happening.give me idea how to get status from subsystem.

[sikku]

vis

[sumit.sen]

Well, there are certain execution order issues in the VI. I would suggest you to use flat sequence structures into the VI to add a definitive order of execution, e.g. the top most "True/False" case structure is parallel to the stacked sequence containing the steps "Bu Close Dev" and writing values to property nodes. So, you can't be sure of which one executes first.

Now, in the event structure you have created for data transfer, the "BuBC send data" and "BuBC Get Data" are in different events, with a timeout of 25ms. So, either of the events can occur in one iteration of the while loop containing the event structure, provided the stop designation is false. So, you can send data or get data in one iteration. Also, the event of value change is dependent upon the user input. So, in case the values in Frame A are not changed withing 25ms from start of the event structure execution, the timeout event occurs and the VI asks for "BuBC Get Data" and stops execution and moves to next iteration. Now, the value of controls in Frame A can change at any instant between 0 to 25 ms for the input to be registered and sent across to the "BuBC send data" subVI. This again makes the update rate indeterminate.

I would suggest you to use other techniques for relatively more deterministic update loop rates, if you are looking for fixed update rates of 40Hz.