Jump to content

Recommended Posts

Hello everyone,

Is someone can explain me. How works this modbus VI? Two questions

I never used the "in place element structure" what's the point of using this type of structure? Is it better FGV? 

Is it important connect "Modbus master out" at the end of this  structure VI or, if it plug to the input "Modbus master in" it will do the same? This VI use a memory control, how it work ? (three question sorry 😊)

Kind regards.

 

François A.

Mutex.png

Link to comment

The mutex ensures that no one else can perform a read or write while it is locked. Otherwise you could mismatch requests and replies. [W1,R1], [W2,R2] instead of potential W1, W2, R1, R2

You could have it in a non-reentrant VI, but then you would also restrict parallel operations for completely different ports.

In this case, in could be wired direclty to out since there are no modifications to it. The mutex will be locked either way.

  • Like 1
Link to comment
On 7/18/2024 at 4:24 PM, Francois Aujard said:

I never used the "in place element structure" what's the point of using this type of structure?

The In-Place Element (IPE) Structure can be used for memory optimization purposes. It is most useful for large datasets. For example, to modify the value of a cluster in-place (hence the name).

Here is a simple example:

1935711968_IPESimpleExample.png.5b24dddb6041917fb3be6970800c01f7.png

This is functionally equivalent to using `Unbundle By Name` followed by `Bundle By Name` but it allows the compiler to avoid a memory copy for the OK value and increment it in-place.

Note that there are different kinds of border nodes that you can use on the IPE Structure: In Place Element Structure - NI

In your example, the Data Value Reference Read / Write Element border nodes are used: Data Value Reference Read / Write Element - NI

It allows you to access the value of a DVR in-place so that you can read, modify, and write a new value to the DVR. While the value is being used in one IPE Structure, no other IPE Structure can access it (all other IPE Structures that attempt to access the DVR at the same time are blocked).

Since a new DVR is created for each instance of `Modbus master`, this ensures that multiple `Modbus master` can execute in parallel (non-blocking) but for each individual `Modbus master`, only one read or write operation can happen at once (blocking).

On 7/18/2024 at 4:24 PM, Francois Aujard said:

Is it better FGV? 

Yes and no.

Yes because it is functionally equivalent to a FGV (prevent race conditions when reading/writing the value).

No because it is not necessarily global (there may be multiple instances of `Modbus master`, each with its of copy of `mutex`).

You can think of it like a FGV that is created for each instance of `Modbus master`.

Note, however, that the value of the DVR is never used in your example. It only serves as a synchronization mechanism.

16 hours ago, Francois Aujard said:

And how you decided what type of value to put in the opening of the VI "New Data Value Reference"?

In this particular case, the data type of the DVR doesn't actually matter.

If you have large datasets (for example an array that takes several MB or GB of memory), it is a very good candidate for a DVR so that memory copies can be avoided while you work on it. Especially in 32-bit, where memory is relatively limited.

On 7/18/2024 at 4:24 PM, Francois Aujard said:

Is it important connect "Modbus master out" at the end of this  structure VI or, if it plug to the input "Modbus master in" it will do the same?

Since its DVRs are `By Reference`, you don't need to connect `Modbus master out`. It will work even if you split the wire (only the DVR is copied, not the value inside the DVR).

16 hours ago, Francois Aujard said:

OK, It's the same as a semaphore ?

In this particular case, yes - if you had a different Semaphore for each instance of `Modbus master`.

Link to comment

Thank you very much for your explanations @LogMAN 🙏. It's clearer for me. 

as I understand it I can do that

323835054_CopyMutex.png.16aea13b8cb9211a5db97b240eb34e2f.png

Synchronization is managed by the mutex, which is called up a IPE structure (accessible as a one-to-one like a FGV). This mutex serves only as a “semaphore”. 😊

31 minutes ago, LogMAN said:

This is functionally equivalent to using `Unbundle By Name` followed by `Bundle By Name` but it allows the compiler to avoid a memory copy for the OK value and increment it in-place.

What exactly happens during the memory copy if you don't use an IPE structure? 

Link to comment
4 hours ago, Francois Aujard said:

as I understand it I can do that

323835054_CopyMutex.png.16aea13b8cb9211a5db97b240eb34e2f.png

Yes that works.

4 hours ago, Francois Aujard said:

What exactly happens during the memory copy if you don't use an IPE structure? 

It creates a copy of the unbundled value (requires more memory). The IPE Structure avoids this copy by overwriting the original value. This is also explained in the docs: Unbundle / Bundle Elements - NI

Please note that my example is simple enough that the compiler can probably optimize it on its own.

Here is another example that the compiler cannot optimize on its own because of the Select:

889485159_IPESimpleExample2.png.431990a8746d1330d6dc3ffedfda5295.png

Link to comment
22 hours ago, LogMAN said:

Yes that works.

It creates a copy of the unbundled value (requires more memory). The IPE Structure avoids this copy by overwriting the original value. This is also explained in the docs: Unbundle / Bundle Elements - NI

Please note that my example is simple enough that the compiler can probably optimize it on its own.

Here is another example that the compiler cannot optimize on its own because of the Select:

889485159_IPESimpleExample2.png.431990a8746d1330d6dc3ffedfda5295.png

OK I have read your link. But what happen with the select? Labview create 2 copy : one for the case True and one for the case false and choose after the correct response?

Link to comment

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.