LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

simultaneous read/write a binary file

I did exactly that as my first post said.

However, each client had to open the STM sessions, send the command, receive the response, close session, close itself.

That took way too much time.

A file can raise an event when it is changed.

There is no session that you need to listen to.

I should've probably checked the set permission vi instead of wondering why yet another LabVIEW feature behave differently than what I expected.

0 Kudos
Message 11 of 22
(1,380 Views)

@GoofyWires wrote:

... Speed and order are not important.


@GoofyWires wrote:
... That took way too much time.

Isn't that a contradiction? 😄

0 Kudos
Message 12 of 22
(1,376 Views)

@GoofyWires wrote:

...

The question is actually: how do you serialize the access to the file from different EXEs? Speed and order are not important.

...


Go with what Christian said about wrapping all of the file I/O in an Action Engine (which are non-reentrant and force serial access to the included methods).

 

Action Engine can be "served" using VI Server between exe on a machine (or between machines). See here for a recent VI-Server thread with an example. See here for an old discussion on file I/O using VI server.

 

If there is any caveat that I should mention it is that LV will close resources when the VI that open the resources close or goes idle. That means that the file should be opened by the VI serving the file I/O otherwise a comm. error could wind up closing a file.

 

Works great and have been using since at max LV 6i and maybe earlier.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 22
(1,368 Views)

Funny...

Speed = 100 ms for an action

No speed at all = 3 sec for an action

I'm ok with 500 ms - 1 sec 

0 Kudos
Message 14 of 22
(1,365 Views)

@GoofyWires wrote:

I did exactly that as my first post said.

However, each client had to open the STM sessions, send the command, receive the response, close session, close itself.

That took way too much time.

A file can raise an event when it is changed.

There is no session that you need to listen to.

I should've probably checked the set permission vi instead of wondering why yet another LabVIEW feature behave differently than what I expected.


Have the single File handler and use TCP to communicate to it as suggested. However, don't open/close the connection all the time in your other applications. Have the file handler keep the file contents in memory and operate off of that. Periodically the file handler application will write it to disk.

 

Another alternative is to simply create a simple TCP protocol to use between your Python and LabVIEW code and let those processes communicate directly. Again, don't open/close the connections every time you communicate unless they communicate infrequently.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 15 of 22
(1,363 Views)

You could also keep all your data (array of clusters, etc.) in a shared variable (even network published). Two (or more) VIs do their "read...modify...write, etc." on the shared variable and a third VI would just read it and write it to file at a leisurely pace so it can be used by other apps (excel, python, whatever). The file writing could be soft so that it will postpone writing whenever the file is locked by another app (i.e. if there is an error).

Of course you might see if the other (non-LabVIEW) readers don't lock the file. For example I am not sure if opening it in excel in read-only mode would work. Notepad is dumb and never locks any file....

 

If the non-LabVIEW processes also modify the file, things become a bit more complicated

0 Kudos
Message 16 of 22
(1,354 Views)

I should have probably started with the project description:

Python is writing and reading directly to the hardware.

The GUI and the test sequencer need to request the Python engine to read or write.

The test sequencer can't keep a TCP session open and each request needs to open and close a vi.

Since opening and closing the TCP takes too long I thought of a having a file between the Python engine, the GUI and the VIs from the test sequencer.

The write requests from the GUI and from the Test Sequencer are not parallel.

The Python will update the current state to the file and see if the file contains a state change request and then it will implement it (no worry for race conditions, just implement the last value change request).

I need to get updated hardware state each 0.5 sec

I'll try using permission changes or a constantly open TCP session between the Python (that doesn't has STM and the comm cluster) and the GUI who will maintain the data with an action engine as suggested.

 

Thanks for all the help even though I still don't understand how Deny Access works and if the file permission can solve the issue. 

0 Kudos
Message 17 of 22
(1,335 Views)

What is your test sequencer? Do you really feel that opening/closing a TCP connection is slower than file access? If you are on a good network a TCP open will complete in tens of milliseconds. If you are seeing slower performance you should analyze either your network or how you are managing your connections.  Are you using IP addresses or computer names when opening your connection? Doing a DNS lookup can slow things up. Use the IP address.

 

I do not believe that file access is faster than a well written client/server implementation. Concurrent file access will be problematic as stated multiple times above. Trying to achieve half second updates via file will be extremely difficult and unreliable.

 

Why are you unable to leave a connection open?



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 18 of 22
(1,315 Views)

Ditto most of what Mark wrote.

 

If you insist on files to share then using multiple files may get you a solution.

 

How about...

 

Which_File_File This is a file that points at the file with the most recent status update. It is updated AFTER a file has been written with the most recnet status.

 

Status_File_A This is a file that contain status information. Status updates are written to it and THEN the "Which_Fil..." is updated.

 

Status_File_B Same as "A" but it is updated while the "reader" can be checking on A to avoid conflicts.

 

But TCP is faster and with the correct protocol you and keeping the connection open you can exchange messages to share whatever it is you are trying to share.

 

Just my 2 cents,

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 19 of 22
(1,311 Views)

Ben, this is exactly what I started implementing:

The Python Engine updates the current state to 2 files: one for the Test Sequencer to read from and the other for the GUI to read from (Python write one instance reads)

The Python Engine gets updated from two other files: One with state change requests from the Test Sequencer and one with state change request from the GUI (One instance writes and Python reads).

However, to simplify things I tried openg ini cluster read write. It turns out read operation locks the file!

To solve this I allowed write till success while the read is slower and event based using .net FileSystemWatcher.

This resulted in a communication mechanism with updates 300ms just because I added a wait to the read.

I guess it can be faster.

 

As to why I have to close the session... I can't do that unless I open a client side engine for each client

0 Kudos
Message 20 of 22
(1,305 Views)