Branch object wire without creating a copy

[max_]

Hello,

I try to interact with a device.

I abstracted the device into a class with several methods.

My application is one big event frame taking care of user input from the front panel and converting it into method calls in order to control said device.

I tried to introduce a parallel loop.

Both loops need to access the object.

It seems like as I branch the wire, a new object is created, therefore my two loops operate on different objects.

I basically want to create a reference to an existing object.

How do I do that?

I cannot click on the wire and create a reference.

[Norbert_B]

Data Value Reference (DVR) or Single Element Queue would be a solution.

Norbert

[crossrulz]

You could make a Data Value Reference to the object.  Then you would have to use the In Place Element Structure to access the object itself.

Personally, I would make a seperate loop that does nothing but interact with your device.  You can use Queues or User Events to pass data/commands to/from that loop.

[max_]

Thank you crossrulz and Norbert for your suggestions.

What would be the difference between Single Element Queues and User Events?

Isn't a Notifier pretty much the same thing as a Single Element Queue?

I do have the one loop that does nothing but interact with the device, but occasionally, I want to have an additional loop running in parallel, also interacting with the device.

I want to monitor the change of a value in the device.

I cannot do that in an asynchronous way, therefore I have to poll the device for the current value and see if it's a new one.

I do not want to do this busy waiting all the time, so I thought I could put it into a separate loop that I can switch on and off based on what happens in the main loop.

I hope that makes sense.

[crossrulz]

---

max_ wrote:

What would be the difference between Single Element Queues and User Events?

Isn't a Notifier pretty much the same thing as a Single Element Queue?

---

I lot is different between User Events and Single Element Queues.  A User Event is basically a broadcasted queue.  A Single Element Queue is a trick to create a semaphore.  Don't use SEQs anymore.  The DVR does the job.

I guess you could say a Notifier is mostly the same as a Lossy SEQ, but it also has the broadcast capabilities.

---

@max_ wrote:

I do have the one loop that does nothing but interact with the device, but occasionally, I want to have an additional loop running in parallel, also interacting with the device.

I want to monitor the change of a value in the device.

I cannot do that in an asynchronous way, therefore I have to poll the device for the current value and see if it's a new one.

I do not want to do this busy waiting all the time, so I thought I could put it into a separate loop that I can switch on and off based on what happens in the main loop.

I hope that makes sense.

---

Send commands to that loop using a queue.  Have the Dequeue Element have a timeout.  So on timeout, you perform your normal monitoring.  That timeout is allowed to be 0.  If you get a command via the queue, you do whatever it is you need to with it.

[max_]

In order to understand Queues a little better I created a loop that receives values and logs them into an array. They are sent to that loop via a Queue. I was able to make that work.

So far so good.

I think that a Queue is not the solution to the original problem.

I do not want to send commands or values to the second loop, but the object itself which the values should be retrieved from / the commands are executed on.

Sure enough I can constantly send the object via a Queue from the main to the second loop.

But this won't work because the main loop possibly blocks from time to time during some operations.

When the main loop blocks, the object data is not updated and send to the second loop.

Therefore the second loop would keep on operating on an old object it recieved via the queue, which would not be the current one which is manipulated in the (blocking) main loop.

I hope that the Data Value Reference solves this problem.

Will the changes that are applied to the data (in the other, blocking loop) be reflected in the DVR that was sent to the second loop only once?

(I cannot constantly send it because the sender (the main loop) is blocking)

I'll try to use the DVR and report back if it works or not.

Edit:

According to this article:

http://www.ni.com/white-paper/9386/en/

"Multiple In Place Element Structures can exist in the same VI, but only one can operate on the data from a reference at a time, as they are blocking functions to prevent race conditions. "

As I need an In Place Element in both loops to get to the data, they cannot run in parallel (each one would block the other), so there seems to be no point in introducing the second loop, because it will be in synch with the other loop.

Am I right on this?

Why is this so hard to accomplish?

[Norbert_B]

I mentioned "Single Element Queue" (SEQ), not "Queue". This is, while using the same methods, a different set of functionality.

And, yes, both loops will influence each other in either case (SEQ and DVR alike). The SEQ has an advantage: You can "skip" the access to the object in one loop ("high priority") in case the "low priority" loop currently accesses the object. This cannot be done in case using DVR.

Norbert

[dkfire]

To me this question screams of race-condition.

Having two loops accessing the same data at the same time without blocking.

Why is it that you need to spilt the Object wire and still need some updated data in the Object?

[max_]

I don't need to. I want to.

The main loop is an event loop and polls the device for values, say a, b, c, in the timeout event case.

The recieved values are then written into the object, so that the properties of the object are the same as the properties of the device.

Occasionally, value d is also of interest and should be monitored as well.

At the moment I also poll value d in the timeout, depending on a flag variable.

While this works, I felt like it would be better to put this polling of value d into a seperate loop, that can be switched on or off.

The current solution works more or less.

As mentioned, some events in the main event loop thing are blocking.

That means that the values of a,b,c and d are not updated.

To work around this, I duplicated the code to update the values and also placed it into the blocking parts of the code, so that my object is updated regardless of the state of the loop (blocked or not).

Duplicated code is not a good practice and I try to improve it.

If I can have one loop that polls values a, b, c constantly with parallel loop(s) that deal with other things and possibly block, I'd be very happy.

[dems]

Another option which is only a smidge more advajnced:

https://decibel.ni.com/content/docs/DOC-15385

ESF centers around the concept of a single entity rather than many instances of an entity. It uses both DVRs and an SEQ (single element queue) to accomplish this, which makes it nominally more complex....but it also feels like the "right" way to go.