08-19-2025 08:21 AM
Hello, I have a Data Logger (Almemo 2890-9) with its free software Almemo Control 6.3. This software generates in real time a .txt file (like the one I attached) with the values of the different channels where the sensors are connected.
I created a small code to be able to read the latest pH value from this .txt and activate a relay that in turn will activate a solenoid valve (wich i've tried to test it with a LED indicator). The problem I have right now is that this .txt file cannot be opened while it is being acquired, so with the blocks I am using it does not allow me to. I tried using read only in the Open Create Replace and I also tried using a Copy block, but in both cases I receive the message "The file is in use. Enter a new name or close the file that is open in another program." This Almemo is connected through a WLAN module (Wireless connection from a PC directly or via a WLAN network to an ALMEMO) that connects to an xPico network. What other options do you see?
😥
Thanks in advance.
Solved! Go to Solution.
08-19-2025 08:31 AM - edited 08-19-2025 08:32 AM
Hi Aros,
@Aros wrote:
I tried using read only in the Open Create Replace and I also tried using a Copy block, but in both cases I receive the message "The file is in use. Enter a new name or close the file that is open in another program."
What other options do you see?
When a file is opened with exclusive access (by Almemo) then you cannot access this file in parallel. There's nothing you can do about it…
Ask Almemo why they need to lock the file even though they only write a data line each 10 minutes!
Can you read the data in a different way than by accessing this text file?
08-19-2025 08:49 AM
Thanks, I suppose it’s because they must have a more complete paid software. I would do it using an Almemo data cable, and it wouldn’t register in the software by connecting directly to LabVIEW, but that’s not physically possible because the cable is short and doesn’t support extensions. So the only thing I can think of is using some TCP/IP block? But is that even possible, ive never tried with IP's.
08-19-2025 10:27 AM - edited 08-19-2025 10:27 AM
It's not the Almemo software doing something strange, Windows (and probably every other operating system) locks files when one program has them open for writing to prevent multiple users or processes from simultaneously modifying the same file, ensuring data integrity.
Opening it read only or copying it to a new location and opening the copy should work.
08-19-2025 11:05 AM
Could you be more specific? Because I tried putting a Copy block in LabVIEW or specifying Open/Create/Replace with Read Only as shown in the code I shared, and neither of them worked.
08-19-2025 11:16 AM
I've previously been able to copy a "in use" file by doing a Windows copy-paste action, then opening the new copy.
I can't guarantee it will work in your use case, but that does mean you might be able to use a .NET file copy instead of a LabVIEW one to create a temporary "not in use" copy you could read from using LabVIEW:
VI attached to save you the hassle of finding the .NET copy function. If it does work, you might be able to remove or reduce the wait time.
08-19-2025 11:24 AM
I’ll try it tomorrow, I’m no longer at my workplace. Thank you very much!
08-20-2025 05:26 AM
I ended up creating the VI myself because I have the 2020 version and your file was 2021. I think it's fine, however, I'm still having the same issue since I can't copy/paste the file in Windows. I'm not quite sure I understood what I'm supposed to do.
Best regards.
08-20-2025 08:39 AM - edited 08-20-2025 08:39 AM
As mentioned on the Discord discussion, there is not a lot of options you can do other than asking Almeno to change the CreateFile() function call in their software to specify FILE_SHARE_READ for the third parameter.
There might be another option to create a file mapping to the file according to https://learn.microsoft.com/en-us/windows/win32/memory/file-mapping, but that is low level Windows API tinkering and just a very random thought. Not sure if it can circumvent the missing FILE_SHARE_READ flag when the application opens the file.
Also reading the file on disk is anyhow a very unreliable operation as long as the writing application has the file open. The data visible to other processes may be a lot less than what the application believes to have written to the file due to file caching where Windows will only write data to the file after a certain amount of bytes have accumulated.
If the application has any other method such as querying the data through TCP/IP or similar, that has always the preference.
08-20-2025 09:38 AM
Another option would be to get a DAQ card to read the output of the pH meter to control the relay and skip the Almemo data file approach altogether.
-AK2DM