Writing a binary file

Hi,
I have trouble when writing a binary file. Here is what I do:
I have some VI's collecting various data for a fixed period of time. I put all the data into 1D arrays at a fixed frequency (they all have the same size). Once it is done I merge all the arrays into one 2D array and I write that to a binary file. If I wait about 10 seconds after writing the file and I repeat the whole thing, everything is fine and the timing is correct. If I wait for a shorter period of time (say a sec, and this is the maximum I can wait to have a usable application) then the timing is wrong in the first part of the loop (the time-critical data-acquisition one). Of course, if I don't write the file, everything is fine (I have to wait about 250 msec between two runs, but that's ok). Any advice ?
I also tried several things like streaming the data to disk during the time-critical period and this works fine only if the file allready exists. If not I experience jitters again. I don't really want to stream the data in real time, but it could work if I can get rid of the jitters. Again, any advice ?
I'm using LV7.1 and the real time module running on a PC (ETS).
Another, sort of related, topic: I noticed that when using 2D arrays within time critical loops all the process are slowdown whereas if I use several 1D arrays everything is fine... Any idea why ?
Thanks,
Laurent

Hello,
File I/O transfer rates during streaming to disk depends on several factors: CPU speed and load, hard drive technology (IDA / Serial ATA / SCSI ...), quality of programming. High jitter is always due to bad programming. File I/O operations are not deterministic. So, file I/O VI's must not be called in the critical task. Data must be saved in the normal priority VI's in order to keep jitter as low as possible. This is the reason why an application in RT is based on RT FIFO to transfer data from the critical loop and the normal priority VI.
You will find a lot of tutorials detailing the key concepts for RT programming at the link below:
* Real-Time Module
http://zone.ni.com/devzone/devzone.nsf/webcategories/C25F8C664230613A862567DF006ABB06
Moreover, memory allocation in LabVIEW is implicit. You must use large set of data carefully because some function reallocate new buffers for their outputs instead of reusing the input buffers (like the function "build an array"). You will find an example of how we can decrease the memory use with array in LabVIEW in the tutorials linked above.
If you need more specific advices, you can post a sample code that reproduce the behavior that you does not understand. I will try to look at this and give you my feedback.
Sincerely.
Matthieu Gourssies, NIF.

Similar Messages

  • UTL_FILE write_error when writing large binary files to unix os

    I am trying to write large files to a folder in unix from a table containing a BLOB object. The procedure below is called by another procedure I have written to do this. It works in windows environment fine with files up to 360MB. When I run this exact same procedure in UNIX I get an initialization error. When I change the WB in the fopen call to W it works. I can store all the files I want up to 130MB in size. The next size larger file I have is 240MB and it fails after writing the first 1KB passing the utl_file.write_error message. If someone can help me to diagnose the problem, I would really appreciate it. i have been trying everything I can think of to get this to work.
    Specifics are, the windows version is 10GR2, on unix we are running on Sun Solaris 9 using 9iR2
    PROCEDURE writebin(pi_file_name IN VARCHAR2, pi_file_url IN VARCHAR2, pi_file_data IN BLOB)
    IS
    v_file_ref utl_file.file_type;
    v_lob_size NUMBER;
    v_raw_max_size constant NUMBER := 32767;
    v_buffer raw(32767);
    v_buffer_offset NUMBER := 1;
    -- Position in stream
    v_buffer_length NUMBER;
    BEGIN
    -- WB used in windows environment. W used in unix
    v_lob_size := dbms_lob.getlength(pi_file_data);
    v_file_ref := utl_file.fopen(pi_file_url, pi_file_name, 'WB', v_raw_max_size);
    v_buffer_length := v_raw_max_size;
    WHILE v_buffer_offset < v_lob_size
    LOOP
    IF v_buffer_offset + v_raw_max_size > v_lob_size THEN
    v_buffer_length := v_lob_size -v_buffer_offset;
    END IF;
    dbms_lob.READ(pi_file_data, v_buffer_length, v_buffer_offset, v_buffer);
    utl_file.put_raw(v_file_ref, v_buffer, TRUE);
    v_buffer_offset := v_buffer_offset + v_buffer_length;
    END LOOP;
    utl_file.fclose(v_file_ref);
    END writebin;
    Message was edited by:
    user599879

    check if this cample code helps -
    CREATE OR REPLACE PROCEDURE prc_unload_blob_to_file IS
    vlocation      VARCHAR2(16) := ‘LOB_OUTPUT’;
    vopen_mode     VARCHAR2(16) := ‘w’;
    bimax_linesize NUMBER := 32767;
    v_my_vr        RAW(32767);
    v_start_pos    NUMBER := 1;
    v_output       utl_file.file_type;
    BEGIN
    FOR cur_lob IN (SELECT vmime_type,
    blob_resim,
    vresim,
    dbms_lob.getlength(blob_resim) len
    FROM tcihaz_resim a
    WHERE rownum < 3 -- for test purposes
    ORDER BY a.nresim_id) LOOP
    v_output := utl_file.fopen(vlocation,
    cur_lob.vresim,
    vopen_mode,
    bimax_linesize);
    dbms_output.put_line(’Column length: ‘ || to_char(cur_lob.len) || ‘ for file: ‘ ||
    cur_lob.vresim);
    v_start_pos := 1;
    IF cur_lob.len < bimax_linesize THEN
    dbms_lob.READ(cur_lob.blob_resim,
    cur_lob.len,
    v_start_pos,
    v_my_vr);
    utl_file.put_raw(v_output,
    v_my_vr,
    autoflush => TRUE);
    dbms_output.put_line(’Finished Reading and Flushing ‘ || to_char(cur_lob.len) ||
    ‘ Bytes’ || ‘ for file: ‘ || cur_lob.vresim);
    ELSE
    dbms_lob.READ(cur_lob.blob_resim,
    bimax_linesize,
    v_start_pos,
    v_my_vr);
    utl_file.put_raw(v_output,
    v_my_vr,
    autoflush => TRUE);
    dbms_output.put_line(’Finished Reading and Flushing ‘ || to_char(cur_lob.len) ||
    ‘ Bytes’ || ‘ for file: ‘ || cur_lob.vresim);
    END IF;
    v_start_pos := v_start_pos + bimax_linesize;
    WHILE (v_start_pos < bimax_linesize) LOOP
    -- loop till entire data is fetched
    dbms_lob.READ(cur_lob.blob_resim,
    bimax_linesize,
    v_start_pos,
    v_my_vr);
    utl_file.put_raw(v_output,
    v_my_vr,
    autoflush => TRUE);
    dbms_output.put_line(’Finished Reading and Flushing ‘ ||
    to_char(bimax_linesize + v_start_pos - 1) || ‘ Bytes’ ||
    ‘ for file: ‘ || cur_lob.vresim);
    v_start_pos := v_start_pos + bimax_linesize;
    END LOOP;
    utl_file.fclose(v_output);
    dbms_output.put_line(’Finished successfully and file closed’);
    END LOOP;
    END prc_unload_blob_to_file;
    set serveroutput on
    set timing on
    create or replace directory LOB_OUTPUT as ‘/export/home/oracle/tutema/’;
    GRANT ALL ON DIRECTORY LOB_OUTPUT TO PUBLIC;
    exec prc_unload_blob_to_file ;
    Column length: 3330 for file: no_image_found.gif
    Finished Reading and Flushing 3330 Bytes for file: no_image_found.gif
    Finished successfully and file closed
    Column length: 10223 for file: OT311.gif
    Finished Reading and Flushing 10223 Bytes for file: OT311.gif
    Finished successfully and file closed
    PL/SQL procedure successfully completedWith 9iR2 PLSQL can write binary files using UTL_FILE put_raw function, prior to Oracle9iR2 you will need to create an external procedure with Java, C, VB or some 3gl language.
    Some references -
    http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:6379798216275
    Oracle® Database PL/SQL Packages and Types Reference 10g Release 2 (10.2)
    UTL_FILE - http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14258/u_file.htm#sthref14095
    http://psoug.org/reference/dbms_lob.html
    Metalink Note:70110.1, Subject: WRITING BLOB/CLOB/BFILE CONTENTS TO A FILE USING EXTERNAL PROCEDURES

  • Reading and writing u16 binary file to a new file

    Hello all,
    a very simple thing that I just don't seem to be able to figure out. I have a file containing 1024bytes of unsigned 16bit words. I can read it successfully with the right value  being displayed. But then I try to write these values to a new file, I can no longer read the same value (in fact it's all grayed out 0) from the newly written file. The newly written file has the right size 1024 bytes, but I don't seem to obtain the right information. I made sure the endian are the same, little-endian.
     Attached is my basic VI, and the .dat file is the file containing the binary information. 
    I'm not using copy file because once I get this figure out, I'll need to append more of the Scan.dat file to one single file. 
    Thank you!
    Solved!
    Go to Solution.
    Attachments:
    read_write_binary_u16.zip ‏11 KB

    I would put some wait time between the write and the read.  It may be a good idea to actually close the file in between.
    I have a feeling that you may not have allowed enough time to actually have the file written out before you read it again.  That or since it is still open, the file pointer is at the end of the file and you are trying to read all the bytes starting at the end, which means you get nothing.
    Not sure of the exact issue, but those two things comes to mind.

  • How do I create a binary file using PL/SQL

    Hi
    Can you help me with writing a binary file in PL/SQL? I like to load binary data from data file, process in database then write to a new binary file.
    Thank you very much in advance.
    regrds
    Yongdong

    DBMS_LOB won't help you write a BLOB to disk.
    You need to an external procedure to do that. Eric K's java works great and he's helped me with his solution and probably about a thousand others.
    Doing a search on this forum will yield many discussions on this often regurgitated topic.

  • Write to binary file different from 8.0 to 8.2?

    I am communicating with a device via USB and am using a method setup by the USB driver programmer. To communicate, I write to a binary file with a filename of \\?\COMx. This has been working fine for about a  year in mfg with Labview 8.0. I recently "upgraded" to 8.2 and now it does not work. If I save for a previous version and run 8.0 it works fine. How can I make this work with 8.2?

    Yi Y,
    The USB device is one of the instruments we manufacture. The USB driver is written so writing to the USB port is just like writing to a file. I use the binary read/write VI's to send and receive commands to this USB device. The filename I use is \\?\COM#. I am told by the USB driver creator that this is common for low level C. I have been using this VI for that last year and recently upgraged from 8.0 to 8.2 and it does not work. I run the same vi under 8.0 and it works fine. This is not a common way to communicate, so will probably not get an answer.
    My next question is, is there any way to run an 8.0 dll or vi from an 8.2 executable?
    Thanks
    Hi dgtest1,
    Which USB device you are using, and which driver are you using? I'm trying to figure out specifically how you are communicating with the USB device by writing a binary file and how was the binary file written.  Could you please post more information to describe in more details about what your set up is doing?
    Thanks!
    Yi Y.
    Applications Engineer
    National Instruments
    http://www.ni.com/support

  • Write to binary file

    I have a relatively large 3D array (Phase Settling), which I want to store in a Binary File. The array is a 15000 point sweep (after decimation), repeated up to 48 by 48 times (in two FOR loops, one inside the other), meaning it can end up having as many as 34,560,000 data points. At the moment, I am attempting to dump that 3D array into a Binary File in one go, using the following VI. There are two possile versions of this array (both the same size as each other) and, depending on which has just been tested, they will be written to their own individual file. Once both tests have been run and their results stored, the idea was to open both files, subtract one array from the other, and store the new 3D array to another Binary File whilst also displaying this latest data elsewhere in a higher-level VI.
    After its first trial run, LabVIEW presents me with an error message saying something along the lines of "LabVIEW had run out of memory". I assume it would be to do with this VI, since that's where the first error code appeared (Error Code: 2), apparently originating in a 'Write to Binary File' function.
    Any ideas as to how I could get round this first hurdle, or perhaps an alternative method I could try?
    Thank you.
    - James
    Message Edited by James Mamakos on 04-08-2010 10:07 AM
    Never say "Oops." Always say "Ah, interesting!"
    Attachments:
    Running out of LabVIEW memory when writing to binary file.PNG ‏30 KB

    Well, as shown in the attached screen-shot, the error indicator shows an error code of 2, and that the error occurred in one of the Write to Binary File functions.
    However, when trying to save this particular VI after a couple of tweaks, I was presented with the following pop-up alert message:
    LabVIEW:  Memory is full.
    Cannot save VI "Compare Amp - calculate.vi".
    LabVIEW Save error code 10: Default data space.
    Anyway, returning back to the main problem at hand, I've though of a couple of possible solutions...
    We don't really need a particularly high resolution to the data points for the comparison, so I could convert the array doubles into an array of singles to save space.
    I should be able to implement the 'Write to Binary File' for the initial arrays into the outer FOR loop, thereby reducing the amount data written in each instance by a factor of up to 48. The only problem I can foresee in this is that I'm not sure how to append 2D arrays into a binary file such that, when the file is read, they would appear as (or be easily converted into) a 3D array.
    As for the 'True' case in my case structure, am I being grossly inefficient in my passing of data from one place to the next? I know there are a lot of branches (and buffers?) of 3D arrays; is there a decent way to reduce this overhead by tweaking the data paths or something?
    - James
    P.S. The computer I'm using has 1GB RAM.
    Message Edited by James Mamakos on 04-08-2010 12:39 PM
    Never say "Oops." Always say "Ah, interesting!"
    Attachments:
    LabVIEW - error code 2.PNG ‏35 KB

  • How to write a 2-D Array of Doubles to a binary file in LabView 8.5?

    Okay, this is driving me nuts. I got a program that worked fine in LabView 8.0 but refused to write any data after my institute upgraded to LabView 8.5. The data is stored in a 2-D array of doubles and is supposed to be written to a binary file, that has been correctly opened and got a header written to it containing some meta-data of the measurement. But when the doubles from the array should be written to the file, nothing happens. All I get is an (except for the header) empty file of 786 kB. I found out that writing works if I convert the data from the array to singles right before wiring them to the "write to binary file" VI, but for several reasons I need the data as doubles. Can anyone help me? I've tried everything anyone has written here about writing to binary files and more.
    Remember, it worked perfectly fine with an older version of LabView. Any ideas?

    It is possible that you run into a known memory optimization bug.
    Try to place an "always copy" primitive as discussed here.
    Message Edited by altenbach on 11-18-2008 09:11 AM
    LabVIEW Champion . Do more with less code and in less time .

  • Problem rendering certain bytes when reading binary file

    I have a two part problem. I am trying to read files of any type from a client and transfer them over a pipe to a UNIX host running a C API. I have this process working for text data just fine however when I try and submit binary data there appears to be some data loss. Most of the file appears to end up on the host but it just isn't as long as the source, nor will it render correctly.
    In investigating this problem I tried to simply output a temporary copy of the transferred file on the client as I was reading the file just to see if my "thinking/process" was correct. The copy of the file ends up the same length but some bytes seem to have been misread. Upon doing a windiff on the source and copy it appears that several characters that are rendered as blocks in the original show up as '?' in the destination file.
    I believe this is an entirely different problem than why I am losing data on the host side but I want to first figure out why this problem is occuring. The below code is how I am reading and writing the binary file. I realize it has some problems with it, it is more of a POC at this point.
               final int BUF_SIZE = 1000;  // 1K
               char[] cBuffer = new char[BUF_SIZE];
               byte[] bBuffer = new byte[BUF_SIZE];
               int read = BUF_SIZE;
               long length = fLocalFile.length();
               FileInputStream fis = new FileInputStream(fLocalFile);
               DataInputStream dis = new DataInputStream(fis);
               FileOutputStream fos = new FileOutputStream("C:\\temp.file", false);
               DataOutputStream dos = new DataOutputStream(fos);
               for (int start = 0; start < length && reply.getSuccess(); start += read)
                   System.out.println("length: " + length + " start: " + start);
                   read = dis.read(bBuffer, 0, BUF_SIZE);
                   // Send the file data
                   String sTemp = sDestName + ":" + new String(bBuffer,0,read);
                   dos.write(bBuffer,0,read);
                   reply = axBridge.execute (Commands.CMD_FILE_TRANSFER_SEND, sTemp);
                dos.close();
            }It seems as if when reading or writing on the data streams some of the characters aren't getting converted correctly. Can anyone help? I've been testing with a PDF if that sheds any light.

    Yes but you ARE converting to a String first which you then send to the axBridge (sTemp!). Try just sending the bytes. You can easily pre-pend the "<filename>:" by sending those first.
    I know that some conversions occur when converting to a String, what they are exactly and what the exact effects are escapes me. Past experience though has taught me to ALWAYS send bytes, with no conversions, what you read is what you send.
    You may need to modify the send/receive protocol so that you send the command first with the filename then the bytes are sent after...
    As for why the file is not being written correctly to: c:\\temp.file, don't know... try the following code, it tends to be one of the "standard" ways of "streaming" data...
         byte buf[] = new byte[bufSize];
         int bRead = -1;
         while ((bRead = in.read (buf)) != -1)
             out.write (buf,
                     0,
                     bRead);
         }     And try just using a FileOutputStream or wrapping in a BufferedOutputStream.

  • Writing waveforms from Ch. 0 of niSCOPE to binary file in a multi-record setup?

    Hello,
    I am not very experienced with niSCOPE and writing waveform records, so I need some expert help here.
    Here is my application:
    I am generating a pulse train using a 6602 counter/timer. Each rising edge of this pulse train triggers an niFGEN to generate a single sawtooth waveform output to another device and, at the same time, acquiring data from Ch. 0 of an niSCOPE. I am fetching one record per rising edge of the pulse train for the niSCOPE (multi-record setup).
    The attached VI is where I am at thus far. All triggering and reading/fetching of the waveforms seems to be working just fine when testing with an oscilloscope. I now need to save each waveform record along with the timestamp of its rising edge trigger to a binary file. The bottom of the VI is where my attempt is at saving the waveforms to a binary file, so the attention should be there when looking at it.
    I am running LabVIEW from a computer connected to the NI PXI-Chassis using a cross-over cable.
    Questions:
    1.) Do I need to convert the data coming in on Ch. 0 of the niSCOPE to digital? Does it come in as analog from an oscilloscope? If I need to do this, how can I accomplish this?
    2.) When I try to run an example VI to write a waveform to a binary file by choosing "My Computer" in the bottom left of the VI window, it works it saves the file just fine. When I change this to run on "PXI2", a file is not even created and I get an error on File Dialog (code# 7, I think) each time the file is attempted to be closed. This may be a stupid question, but why can I not save data to a file on my computer if running the VI on "PXI2"?
    3.) Assuming the saving of each waveform to a binary file is working (read: (2) is successfully addressed), how can I also write the timestamp of the starting trigger for the waveform along with the waveform in the binary file? An example VI of how I can accomplish this would be fantastic, but I haven't been able to find one thus far.
    4.) When I was messing around and trying to accomplish this, it seemed that doing this writing may slow down the entire process too much. I need to record data to the extent of the sawtooth waveform generated by the niFGEN AWG for each trigger. Is there any changes I should make to my acquisition process in the niSCOPE section so that I can read each waveform, along with keeping the timestamp for each, and write this information to a binary file?
    I need to get this working quickly, so any help on this is greatly appreciated. Thanks in advance.
    Attachments:
    5124_update.vi ‏157 KB

    Thank you so much for your reply, David. Let me try and explain my
    situation and setup a little better, as well as discuss the points you
    made in your reply. Beware, you may want to refill your coffee as this
    post is long .
    I am using an embedded controller in a PXI-1044 chassis. I now have the
    chassis hooked up to our local network, and I am deploying my project
    to the chassis over the network as I am also connected to the local
    network. I have an oscilloscope next to me that takes as input the
    pulse train for a trigger and the generated sawtooth from the niFGEN
    for each trigger (rising edge of the pulse train from the 6602
    counter). Just to make sure synchronization is taking place, the
    sawtooth is also fed as input to the niSCOPE for acquisition.
    "PXI2" is what shows up when I choose to run a VI on the PXI chassis
    rather than "My Computer"; not sure why the 2 is there either, but that
    is what it says. I may have tracked down the issue I was having with
    writing, but more about that a little later...
    The attached VI is an update, although not much has changed. My
    application design is like this (keep in mind that some values for VI's
    are still constants in the block diagram while others are controls on
    the front panel): I am using the 6602 to generate a 1 KHz pulse train
    and routing this pulse train to PXI_Trigger0/RTSI0. I am also using the
    PXI_Clock (10) as a sample clock for this, and also using this same
    clock as the reference clock for both the 5422 and the 5124 (as per the
    synchronization help file mentioned for synchronizing multiple
    devices). Both the 5422 and the 5124 are triggered by a digital rising
    edge (from the pulse train) on PXI_Trigger0/RTSI0 (as it was routed
    there). For each trigger, the niFGEN generates a sawtooth waveform
    using a stepped trigger mode and outputs it. For each trigger, the
    niSCOPE acquires data. They are both synchronous, which is tough to see
    since one has its trigger source on the front panel and the other has
    its trigger source on the block diagram. All devices use PXI_Clock so
    they are synchronized.
    The expected behavior is to only generate a single sawtooth waveform
    per trigger with a certain number of sample points. I want to acquire
    the same number of samples using the niSCOPE, which is what I meant by
    "the extent of the waveform" in my previous post. So, should I change
    the 8192 to 1000 for the number of samples for the niSCOPE? What would
    you recommend for the sampling rate? I have been using 5 MHz for the
    niFGEN and 5 MHz for the niSCOPE...this is how it should be done,
    correct? If it is different in the VI, please let me know. For some
    reason, I have to adjust all of the values each time I open it since
    the default values are not the ones I want.
    I want to generate and acquire one waveform per trigger (one waveform
    per record). However, I want to be able to record a large number of
    records so I have enabled the circular buffer-like treatment of the
    acquired waveforms. The 100 or 1000 records is actually just a number I
    am giving it for now to make sure it is working before recording many
    more records.
    As for saving the niSCOPE data, I would like to save all data in a
    single file that is NOT ascii (to save space). I have been looking at
    the HWS file format, and would like to use it. I think the attached VI
    includes this at the bottom of the while loop. For each trigger, I
    would like to save the time (as accurate as possible) that the trigger
    occurred for the record/waveform, which appears to be (absoluteInitialX
    - relativeInitialX) as you said in your post (thanks!). I just need to
    store as much information about the waveform and time information for
    it as possible with the waveform in the file. So it looks like I will
    need to use the wfm info for that information, providing portions of it
    as waveform attributes in the HWS VI's?
    What format of data do you recommend I fetch, and will I be fetching a
    "Single waveform" or "Multiple waveforms"? Should I use I32, DBL, WDT,
    or other for the format? A balance between good precision in values and
    time it takes to fetch/record would be best.
    Given all of the above, I am having one troube with saving data to a
    file. As a reminder, I am deploying the project to the chassis over the
    network. When I choose a location and/or file to save the HWS data to,
    I only get choices that are on the PC's hard disk (such as C:\Documents
    and Settings\cgifford\...) NOT the chassis's hard disk. When I choose
    something other than "C:\" I get an error that the file could not be
    opened. However, when I choose "C:\" everything goes fine. The saved
    data is nowhere to be found on my PC though, so I am assuming that it
    is being stored on the internal 60G hard disk in the chassis that must
    be named "C" by default or something!?
    I have been told by phone support that I should be able to make a
    direct connection with the chassis just like another PC, and should be
    able to access the information on its internal hard disk in a drag and
    drop fashion. I however cannot directly connect to the PXI chassis to
    get the data that has been saved on the hard disk. We are running
    Windows XP on the PC. We did some poking around and noticed that the
    chassis is not running Windows file sharing, and only has ftp and http
    running. We tried to access it using ftp, but we didn't have a username
    and password to supply it. So, how can we enable Windows file sharing
    on the chassis? How can I connect to it to do drag and drop to get
    saved waveform data off of it? This is the main problem I am now
    facing. Eventually we would like to store data to an external hard disk
    connected to the chassis, which assumes that I can have access to the
    internal storage to tell it to save files to the external hard disk.
    For now saving it to the internal hard disk is just fine until
    everything is proven to work, but I would like to get the data off of
    the internal hard drive to put on another computer.
    Any answers/suggestions on my above questions are greatly appreciated.
    I also want to thank you for reading this long post . I eagerly await
    a reply. Thanks again in advance.
    Chris
    Attachments:
    5124_update.vi ‏143 KB

  • Binary file write cancatenat​ion during writing

    Hi, 
    I'm trying to write a 2D array into a binary file and save the whole complete array in 2D.  As shown in the picture, data is written and appended to the binary file during each loop.  However, each loop would generate a 5x800 2D array (5 rows, 800 elements in each row).  Right now I have to use another vi to process the binary file I saved to concatenate all the arrays in the binary file to finally obtaion a 5 x 800n (n is the number of loops) array.  Is there a way to save the data into binary file in that format during each loop instead of writing into different segments and I have to concatenate different segments together after that?  
    On the other hand, if there's a way to do that, would that increase the loop cycle time because it's more computationally expensive?  Thank you very much for your help.
    Thank you,
    Charles
    Attachments:
    picture2.png ‏37 KB

    See the attached examples.
    If you have the file open you can basically just write data to it whenever you have it available, just do not include the length. It can cost a bit to write single elements so the row option is more commonly used, but it depends on how large each row is (if they are huge then it will cost to much to keep them in memory and you write parts of each row instead...). 
    I have not covered cases where you need to close the file and add data later, but the difference then is just that you need to set the write position after you have re-opened the file.
    MTO
    Attachments:
    Write and read 2D array.vi ‏26 KB

  • Problems writing a structured binary file...

    Hi Folks,
    I've been working with one of my students to convert this matlab routine into a VI to no avail:
    fwrite(fout,version,'char');
    fwrite(fout,nchar_text,'short');
    % convert wave_text into array of ascii integers
    fwrite(fout,wave_text,'char');
    % output a null character to terminate string
    %count=fwrite(fout,0,'char');
    fwrite(fout,n_bits,'char');
    fwrite(fout,n_bytes,'char');
    fwrite(fout,data_polarity,'char');
    fwrite(fout,user_data,'float');
    fwrite(fout,s_rate,'ulong');
    fwrite(fout,adrange,'float');
    fwrite(fout,n_pts,'long');
    fwrite(fout,wave,'short');
    fclose(fout);
    I've written a VI that can open the files written by this Matlab procedure with no problem (see openfile.VI), however I can't seem to recreate the method for writing this file to binary (writefile.VI).  I think the Matlab approach is very similar to C, and I'm guessing the issue has to do with converting datatypes effectively.  I've been searching the forms and google, but can't seem to come up with the proper solution.  Any pointers would be greatly appreciated!
    Best,
    Jason Gallant
    Attachments:
    writefile.vi ‏27 KB
    openfile.vi ‏26 KB

    crossrulz wrote:
    The additional bytes for the array and string lengths is what is throwing you off.  Even if you turn it off at the Write Binary File, because you built a cluster they will be in there.  You do not want to cluster up your data in this case.  You need to string together a bunch of Write Binary Files, one for each of your parts of data.  Similar to what you had to do in Matlab.
    Great suggestion!  We tried implementing this, and things are looking better.   I've attatched the new VI that implements this.   There still seems to be a problem, however with the datatypes being written.  As mentioned in the previous post, the data written is:
    version   - 'char
    nchar_text, 'short'
    wave_text, 'char'
    n_bits,'char'
    n_bytes,'char'
    data_polarity,'char'
    user_data,'float'
    s_rate,'ulong'
    adrange,'float'
    n_pts,'long'
    wave,'short'
    Should i be typecasting (or something similar) to string in order to make this readable by my previous routine?
    Attachments:
    writefile.vi ‏38 KB

  • Memory issues writing binary files, using a subVI to do all File Handling, topVI, when run normally files are way too large.

    Problem writing binary files with LV 8.5. I have one VI that does all the interaction/file I/O and another VI for testing. I find when I run the subVI where all the data reading/writing is happening with break points and single stepping through the code all is OK, but when I run normally the files are much larger than they should be and as well when I close the files I get a error. Any insights?  
    Walter

    Waltz wrote:
    I found the problem, I was actually trying to close the files twice.
    I don't see how this could cause the symptoms you described in the first post.
    (It only explains the error on close).
    LabVIEW Champion . Do more with less code and in less time .

  • Writing binary files & trouble with no unsigned byte type

    I've got a fair amount of Java experience, enough to know what I'm doing most of the time but I do have a vast experience with C & C++ which helps my Java. I've stumbled across a problem when trying to write out files in binary.
    If I was to write out a binary file, I would always choose C/C++ to do this because simply because I'm at ease with the implementation.
    I've now written a Java program which needs to output a file in binary and I'm having real issues doing the most simple things because of no unsigned support.
    I want to write out elements byte-by-byte and make use of the 8-bits provided in the byte type in Java.
    Let's assume I've done my processing and I end up with an int. I know that this int is 0-255 in value. I now want to pack it into a byte and write it to my file. How do I go about assigning the byte without Java 'converting' it to a signed byte? I simply want to copy the lower 8-bits of the int and duplicate them into the byte variable - no conversion.
    In C you would do something like this:
    char mySignedChar = *( (char*)&(unsigned char)myInt ) );
    What's the Java equivalent? Am I going about this the right way?

    Whether a byte is signed or unsigned only matters if one is doing arithmetic on it. If the int is 0-255 then you just cast to a byte using
    byte theByte = (byte)theIntValue;When reading back you just use
    int theByteAsAnInt = theByte & 0xff;

  • Writing binary files in block mode?

    I am sampling two channels in continuous mode using labview basic version. I would like to take the two arrays of values as I am sampling them and write them out in block mode to a binary file. What's the best way to do that?

    Open or create a file for write before daq starts, then continuously write data to the file, and close it after the daq is stopped. Make sure each column of the data array is each channel, so an Array transpose might be needed.
    -Joe
    Attachments:
    Snap8.gif ‏8 KB

  • Writing binary file - random places

    Hi,
    I want to write to random places inside a binary file using powershell.
    something like a function write(position,value) 
    Original file content "0123456789"
    write(1,2) -> file is now "0223456789"
    write(6,2) -> file is now "0223452789"
    write(end,12345) -> file is now "022345278912345"
    Is something like this possible? And how? Does somebody have any linkes for me to follow.
    With kind regards,
    Maurice Lucas

    The example is text.  You cannot write to a binary file using text.
    We would open the file as a binary stream and use file seek methods.
    A binary file has only 1s and 0s.  They may look like hex in a binary editor.
    See:
    http://msdn.microsoft.com/en-us/library/d3wke8tz(v=vs.110).aspx
    Binary is written to by byte position and buffer length.
    ¯\_(ツ)_/¯

Maybe you are looking for