Can I manipulate one channel (Digital Out) from several VIs

[RUrm]

Hello all,

I have one VI to do switching digital outputs by hand. Then I start my Testprogram. As long as the simple switching thing is running (although not doing anything else but waiting) the testprogram cannot handle the output.

Is there a way to enable access for both VIs ?

Regards

RU 

[Pnt]

If i understand correctly, the simpler way is to not to wait in the "simple switching thing ".

Call it once to activate your output, switch to main program, then call it again to deactivate the output.

There are other options too. Ask, if you need more info.

[RUrm]

Thank you.

Yes I know this,

BUT:

It is just a question of laziness. I do not want to search for my switch-VI each time I want to use it.

And what is probably worse: it happened already that I left my running (as I thought then) test without deactivation of the switch and

so blocking everything.  I noticed the day after!

So I think it would be helpful to acess an output from more than one VI.

Regards

RU

[Pnt]

Then you have to dynamically load the vi,

with the "wait until done" set to false

Message Edited by Pnt on 07-02-2008 03:15 PM

[johnsold]

RU,

If you intend for both programs to run simultaneously, it is often better to create a parallel VI which handles the DO task and have all other VIs which need to control the outputs send data to the DO VI via a queue or Action Engine.

You can set up your programs to check to see if the DO VI is running before they send data to it. If it is not running, then they can start it (via invoke nodes) before sending the data.

If two different VI can control the same digital lines, how do you handle the case where one of them overwrites what the other just did?

Lynn

[RUrm]

Hi Lynn,

so I understand I (or the programmer in charge) have to change my testapplication.

Don't you think the access  might be enabled by finding and setting the right task or channel property?

RU  

[johnsold]

RU,

There can be many ways of controlling the access. I just wanted to be sure that you were thinking about the possibility that the tow programs might be competing for control of the same line.

Lynn

[RUrm]

Oh, yes.

In this case there is definitely no synchronisation problem.

So I was hunting for a simple solution.

RU