CWRITE

    I've taken on learning the CWRITE, etc. Its actually not going terribly, and I think I may be able to make use of this...

    Here is my stab at a program

    DEF dataImport ( )
    INT FileHandle, i, length
    BOOL EOF
    DECL STATE_T State
    DECL MODUS_T MODE
    DECL SEEK_MODE_T SEEK
    MODE =#SYNC
    SEEK = #SEEK_CUR
    EOF=FALSE
    FileHandle = 0, length = 0
    i = 1
    CWRITE($FCT_CALL, State, MODE, "krl_fopen", "frametest2.txt", "r", FileHandle)
    CWRITE($FCT_CALL, State, MODE, "krl_fsizeget", FileHandle, length)
    WHILE EOF==FALSE
    Remote[i] = $WORLD
    Remote[i].E1 = 0,Remote[i].E2 = 0,Remote[i].E3 = 0,Remote[i].E4 = 0
    CWRITE($FCT_CALL, State, MODE, "krl_fscanf", FileHandle, "%f,%f,%f,%f,%f,%f", Remote[i].X,Remote[i].Y,Remote[i].Z,Remote[i].A,Remote[i].B,Remote[i].C)
    CWRITE($FCT_CALL, State, MODE, "krl_fscanf", FileHandle, "%f,%f,%f,%f", Remote[i].E1,Remote[i].E2,Remote[i].E3,Remote[i].E4)
    CWRITE($FCT_CALL, State, MODE, "krl_feof", FileHandle, EOF)
    i = i + 1
    ENDWHILE

    CWRITE($FCT_CALL, State, MODE, "krl_fclose", FileHandle)
    END


    So the above code sort of works fine, but I never hit EOF if I have more than one line in the file. Is it looking for something else to advance the pointer? FYI, Remote is a global array of E6POS. It seems CWRITE requires the return variables to already be initialized.

    My file is just :

    0,1000,2000,3000,4000,5000,0,1,2,3
    0,1001,2001,3001,4001,5001,0,1,2,3
    0,1000,2000,3000,4000,5000,0,1,2,3
    0,1000,2000,3000,4000,5000,0,1,2,3


    It reads the first line and then nothing after that(but it keeps looping). I thought maybe I could advance the file pointer with fseek, but its not clear where I should move it to. The krl_fsizeget of the file returns 142 byte.

    Is there a more streamlined way to do this?

    ah I think I see what you mean. for one thing state carries the end of file indication....and for another, it indicates how many bytes were read. This may just be a binary number thing, but any guess as to why this file is 142 bytes? I assume some the numbers are getting cast to specific types, but I can't seem to figure out how. Probably this won't matter once I use state correctly, but its more a curiosity.

    eh....? ??? someone is having rough day :hi-bye:


    this is a text file... in text files each ASCII character is one byte...

    just...count characters...

    or paste the data into a text file and see the properties:

    Been playing with FSCANF myself lately. One thing I'm still looking at is that, when I hit the end of the file, I get a STATE.MSG_NO of -2 (operation failed) rather than -4 (end of file). Still looking into that -- I had issues with the "EOF" call when I tried to use it. Work in progress.

    Also, FSCANF with %f seems to get really finicky when you have actual Real/floating-point variables in the text file. So far, the only way I got it to work was to alter my text file so that every value was exactly the same number of characters, which included adding "+" or "-" to the beginning of each number, and using leading and ending zeros to pad out the length. Basically, a %8f would work for '+0099.90' (the decimal point counts towards the character total), but would crash for '0099.90' or '+0099.9' or '+99.90' -- basically, it just doesn't seem to be able to handle dynamic character lengths. A plain %f wouldn't do it either. SREAD also seems to exhibit the same behavior. I'm guessing that you're not tripping over this (yet) because your example text file is all Integer values.

    Beyond that, once I massaged my text file to meet these criteria, it seems pretty solid. I generated 6000-deep array of randomly-generated Frame values, and was able to open and read them into a same-sized .DAT file array with 100% reliability. And the entire process, from 'fopen' to 'fclose', took maybe 2sec total.

    well thats really helpful. I made some changes to suit my application; and I think I broke it! On the second pass through, the CWRITE calls fail, leading to nArrayIndex inadmissible(because its still set to 0, which is out of range).

    Possibly the changes to the text file I made?

    I changed the fscanf calls to:

    CWRITE ($FCT_CALL, _State, _Mode, "krl_fscanf", _nFileHandle, "%d,%f,%f,%f,%f,%f,%f", nArrayIndex, myPos.X, myPos.Y, myPos.Z, myPos.A, myPos.B, myPos.C)
    CWRITE ($FCT_CALL, _State, _Mode, "krl_fscanf", _nFileHandle, "%d,%f,%f,%f,%f", nArrayIndex, myPos.E1, myPos.E2, myPos.E3, myPos.E4)
    Remote[nArrayIndex] = myPos


    and the data file looks like this:

    1,+0000.98,+0000.16,-0000.28,+0001.31,+0000.31,-0001.04
    1,+0001.98,+0001.16,-0001.28,+0001.31,+0000.31
    2,+0001.29,+0002.27,+0000.16,-0000.88,-0002.49,-0000.41
    2,+0001.29,+0002.27,+0001.16,-0001.88,
    3,+0001.84,-0001.10,+0000.29,+0001.01,-0000.18,+0000.94
    3,+0002.84,-0002.10,+0002.29,+0002.01
    4,-0001.15,+0000.17,-0002.46,+0000.09,-0001.56,-0001.39
    4,-0002.15,+0002.17,-0002.46,+0002.09


    The limit on fscanf vars is unfortunate, so I am doing the frame on one line and the ex axes on the next. It works the first time, and then on the second pass fails?

    yeah definitely something I did. I took out the new lines in the txt and the 2nd CWRITE and I made it through 4 times, before getting an error as I ran of of lines. So thats good. Any idea why my changes cause the error though? I was pretty careful with the formatting, but this is "sensitive" code to say the least. Ive been spoiled by visual studio....it practically does it for you.

    Well, FSCANF reads an entire line, but the file pointer is essentially invisible to use (at least, going by the manual). One thing to watch out for is the End-of-Line (EOL) terminator. My test file used both CR and LF for the EOL termination, and it works so far, but I haven't experimented with trying either one solo. And I know that some text editors terminate lines differently (most notably "Windows style" vs "Unix style").

    As for using fewer CWRITEs, well, you could simply scan the entire line into a CHAR[] using FSCANF, then use SREAD to parse out the Reals. But since SREAD maxes out at 10, you'd have to use two of them. The Offset variable will allow you to have the second pick up where the other left off.

    FGETS only reads a file line into a string, so you've got the same problem there. Off the cuff, it looks like you're stuck with either two CWRITES with FSCANF, or one CWRITE followed by a minimum of two SREADs.

    Well, I had to return to this, because now I'm the one that needs to read in more than 8 variables per line. Turns out FGETS actually works quite well -- the hard part is the SREAD to parse out the values after.

    Long story short, I had to go back and also make my integer variables of fixed character length, and set the format string to match. Once I did that, everything worked quite well.
    (I still need to get my end-of-file checking working, though).

    One problem that had me going in circles for half an hour: for a while, every other SREAD was failing, because the buffer was empty. But the FGETS was always returning #DATA_OK. I finally figured out that, including my Carriage Return and Line Feed characters, my line length in the text file was now one character longer than the max length I had in the FGETS command. Which meant that every other FGETS was reading in just the Line Feed, which satisfied the FGETS, but left the SREAD with nothing to parse. :wallbash:

    Ah, well. Going to need to give this some pretty smart protections to trap errors intelligently, but it works.

    nice, will check this out. The two line technique has been working well for me. Working with up to 20k E6POS, no problem(takes a few seconds to load those). Wish I had done this years ago, it is so convenient to update via OLP software and then reset the program. From a user perspective, a bit more challenging, as of course the programmer needs to understand whether the program structure has changed, and in that case recopy the SRC.

    i have not played with this in a while but i don't recall need for all those formatting constraints (forced sign value, fixed width, splitting data into two or more lines etc.). you may be overthinking this....

    use CWRITE with "krl_fgets" to read line of ANY length, then use SREAD to parse it. and if one SREAD does not do it, add another one... and another... etc.

    here is example of rather "messy" looking data format with varying length of records, with and without sign, with just space character as separator and all 14 elements in one line (one E6POS per line...).

    ...and program that reads it without issue.... and detects file end... and does not use ON_ERROR_PROCEED.

    unless i am missing something...

    All I can tell you is, if I replace the %4d with %d, or the %8f with %f, the SREAD will fail 100%. And if I have an Integer in my text file that's only 3 digits, or 5, even the %4d will crash. Ditto for the %8f and any Real that has more or less than 8 characters between the commas.

    I was wrong about the CWRITE with FSCANF, though -- it will work fine with simple %f on the same file. But given the 8-variable limit....

    On a related note: STATE.MSG_NO from the FGETS or FSCANF doesn't appear to reliably return a -4 when hitting the end of the file. Using an FEOF immediately following every FGETS has shown me that even when FEOF shows end-of-file, the FGETS State.MSG_NO will still return -2 ("Operation Failed").

    Using consecutive SREADs to pull more than 10 variables/line out of the buffer, I found that I had to manually increment my Offset counter by 1 in between the 1st and second SREADs, or I'd get a failure on the second. Probably because without incrementing Offset, the second SREAD was treating the dividing comma as the start of the line and choking on it.

Advertising from our partners