shift registers to conunicate data between different vis

[asper]

I'm developing an application on a cRIO-9002 unit by using the TCO/IP modbus library for communicating with the host computer.

I have tried the Modbus Library for LabVIEW (http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=F1582737BACF5CA8E0340003BA7CCD71&p_node=DZ52363&p_source=External), the master and slave examples work fine both on windows OS and on board of the cRIO.

For my application I need only some pieces of the library, so I started to looking into the architecture of the modbus VIs.

The main "Slave" routine write and read the data to a "Slave Demon" that answers, via TCP/IP, to the "Master" query using the modbus protocol.

Actually the main "slave" task write and read the data from the "MB Registers Manager.vi" (the VI uses some shift registers to temporary store the data).

The demon task is the "MB Ethernet Slave Demon.vi". Inside the "MB Ethernet Slave Demon.vi", the "MB Ethernet Call Wait on Query.vi" calls the "MB Ethernet Wait on Query.vi", that next calls "MB Ethernet Slave Communication.vi" that next calls the "MB Update Registers.vi" to finally read and write from the "MB Registers Manager.vi".

Actually two tasks call independently and simultaneously the same VI to read and write data into his shift register.

Why there is not conflict in the simultaneous call to the same VI?

Thanks,
Asper

[TiTou]

Asper,

The coding technique that consist in holding datas in the shift register of a vi so that it can be read/write at any part of an application is comonly call FGV (Functional Global Variable) or LabVIEW 2 global variable.
I don't see why it should cause any conflict for the different calls are NOT simultaneous unless the vi is set a re-entrant but in that case that would have no sense at all...

[tst]

As TiTou pointed out, the Registers Manager VI is not reentrant (VI Properties>>Execution).
As such, it has a single memory space, and whenever it is called from one place, any other place calling it in the program will have to wait until it has returned in the first place it was called (except, since it's set to subrouting priority, it can be configured to be skipped if it is occupied, but that's not the default behavior), so it's not called simultaneously.

If you will look at how it's structured, you will see that the shift registers actually hold the data for all the registers and you can access it from any place in your program. This is basically a global variable which can be made to be very smart and avoids race conditions and some memory allocation problems. You can search for data on the terms mentioned earlier to learn more.

[asper]

Dear TiTou and tst,
thank a lot for your replay.
I'm using the Functional Global Variable since long time but calling them only sequentially with the intention to avoid any 'conflict' ... now I have learned that the FGV is more smart than what I was thinking.

Thanks,
Asper