Here's a strange one.
In a nutshell I've got some code that continuously captures data from hardware to a text file, and another portion which can vomit the contents of the text file back in a string - simple enough. The former is compiled into an exe (multiple instances running on the PC performing the testing), the latter into a lvlibp. Both 'source' from the same project, compile fine, and indeed work just fine on all of my existing test systems (10+, some with single data streams, some with 4, some with 20~30).
In comes the newest test system, and all of a sudden it's *almost* working on this new PC
- also Win10 like the others, potentially a different service pack/build
- LV2017x32 (17.0.1) on Win10x64 dev machine(s) - same LV but Win10x32 and x64 test stations (both bitness working fine)
The bonkers bit on the new PC is that - if you independently open the text file (notepad) all the data is there, but if you use the lvlibp routine to read the text file (before and after viewing it in notepad) it only 'sees' the first splash of data, but none of the subsequent writes that have occurred. Now if you perform an 'unnecessary save' in notepad, the lvlibp function can now 'see' all the data that was visible in notepad (unsurprisingly). If you don't force-save the file like this - successive delayed attempts via the lvlvibp function to 'read' give no change on this PC, just the first splash of the file (presumably what got captured on the FIRST exe based write cycle, nothing after that) though closing/opening in notepad will keep showing the (continually growing) new data being in the file...
On every other machine, calling the lvlibp to fetch the guts of the text file gives you everything, no prob.
With that oddity, I naturally scraped down to the actual File IO calls being made on both sides...and I'm not seeing anything strange? I mean, it's just the read/write file primitives...
So then I thought 'maybe permissions?' but I doubt it - same user account running the LV exe that's writing the file, using the lvlipb to read the file, and opening notepad...
For what it's worth, the top level automation is teststand 2017 (launching the exe's and calling the lvlibp functions) and I briefly considered maybe doublechecking the selected labview adapters in teststand on the new PC...but the EXE and LVLIBP are going to be running in the Run-Time engine regardless right? The sequence step that calls the lvlibp doesn't override the default adapter in favor of the runtime - so I'll doublecheck at my next chance...but that seems an unlikely source of this odd behaviour.
I'll try to figure out how to upload a snippet or screen grab (there's clearly nothing vaguely proprietary that this basic level - but corporate nanny-ware makes innocent things like this...complicated) - in the meantime here's the basics of the LV in pseudo:
The code that writes to the file uses:
- Open/Create/Replace File (Path, Open, Write-Only) [disable buffering =default false]
- Set file position (end) [offset=default 0]
- Write to text file (new strings) [convert EOL checked]
- Close file
The code that reads the files uses:
- Open/Create/Replace File (Path, Open, Read-Only) [disable buffering =default false]
- Read from text file (count = -1)
- Close file
All cards on the table - the latest machine is running the 'newest' compiled exe (the LVLIBP is unchanged) - but the only change (new HW/new problems) is ONE more VisaRead error being handled (in a separate loop that hands the visa data to a shared queue - the queue to file code is unchanged, and the visa and file IO calls are in separate SubVIs, not just separate loops). Without this update the new HW would randomly flip from english to runtime errors and wingdings...so I don't have much data on the fileIO with that build and this HW
Also, this new test station is more complicated from an IT perspective (it's a full up CS-LAN/Domain, not just a standalone or peer-to-peer setup) - but Labview, Teststand, all portions of the code and the text file are running on the C:\ of a particular PC - so I'm not expecting RAID/etc issues...
PS: I really wish it was the complicated code that had gone wrong - it's almost insulting that I'm asking for help 'reading a text file' when all the rest is working fine haha
