Write/Recall Recommendation

[RBPLC]

I've defined a UDT with 15 fields. This UDT is used in a memory block that is 52 long. I would like to write all elements of the memory block out to the SD card in a file that can be recalled later and copied back into the memory block. Any suggestions on the easiest way to accomplish this?

[franji1]

"easiest" is not easily defined.

1. You could just dump the memory to the files and read it back as raw memory.  But that means you can never ever ever change the definition of your UDT, otherwise those files are not just invalid, they could be corrupted (e.g. moving bit patterns to a float that is NaN, etc.).  This is "easiest" but those files are not human readable.

2. An alternative is to take advantage of JSON grammar.  JSONPRINT and JSONPARSE could be used.  The benefits here are it is very human readable, and can be easily understood/displayed/modified by other programs.  This will definitely complicate the logic, but stick it in its own code-block, and it will be buried.  It's also a memory hog, but we could work around that by not using arrays, but writing each record to a text file with CR/LF as the delimiter for each JSON record instead of JSON array grammar.  Also, if you add a field or remove a field, the code can be easily tweaked and logic could be added to handle missing new fields in older files, etc.

If you know this UDT is written in stone, option 1 is definitely "easier" than option 2.  Option 2 is not that bad since the code will be mostly understandable.  Stage program would make this work nicely.

WriteDataFile
S0
RST C99
FILEOPEN OnSuccess JMP S1 OnError JMP S99
set record index V42 to 0

SG S1
JSONPRINT JSONBUILD MyUDT[v42] to SL0  // this is more complicated parameters, but the JSONPRINT editor has a short cut to generate all 15 fields with a single button)
STRPRINT SL0 Append CR/LF "$0D$0A"
JMP S2

SG S2
FILEWRITE SL0 OnSuccess JMP S3 OnError JMP S99

SG S3
INC V42
V42 >= 52  JMP S4
ELSE JMP S1

SG S4
FILECLOSE
EXIT

SG S99
SET C99  // turn on alarm C99 that file creation failed, e.g. missing SD card, etc.
EXIT


The File Read mechanism is  a little more complicated, but kick the tires with this, get it working, look at the file on your PC, see if this is worth doing (a raw binary file will be very hard to understand).

[RBPLC]

"this is more complicated parameters, but the JSONPRINT editor has a short cut to generate all 15 fields with a single button"

JSONPRINT? Is this a command? If it is I'm definitely missing something.

What I believe you're saying is that for JSONBUILD I'd have to build a table with all 15 fields like this: MyUDT[v42].field1, MyUDT[v42].field2....MyUDT[v42].field3 (this has to be done manually because I can't index the field numbers). At this point I could then index using V42 in stage to write out my 52 memory block. Is this correct?   

[franji1]

"this is more complicated parameters, but the JSONPRINT editor has a short cut to generate all 15 fields with a single button"

JSONPRINT? Is this a command? If it is I'm definitely missing something.

What I believe you're saying is that for JSONBUILD I'd have to build a table with all 15 fields like this: MyUDT[v42].field1, MyUDT[v42].field2....MyUDT[v42].field3 (this has to be done manually because I can't index the field numbers). At this point I could then index using V42 in stage to write out my 52 memory block. Is this correct?

You know the mnemonics better than me!  Ha!  Yes, JSONBUILD.  Good catch!

You will loop across multiple PLC scans using Stage transitions.  Basically S1 generates the current data (indexed by V42 0..51), S2 writes out that ONE record of data to the file, then S3 increments V42, then JMPs back to S1 to do the next record.  It will take at least 52 PLC scans to write them all out.  Calendar time is not critical (this is not realtime control - it's a flash drive).  It does not take much time (less than a second?).

I wrote a little program the fills in the User Date/Time structure with the current time, writes it to a file, then reads it back in a different Date/Time data block.  I was going to post it on the example page (still working on the documentation).  I've attached that preliminary version here (it's for Designer 2.7).

[franji1]

What I believe you're saying is that for JSONBUILD I'd have to build a table with all 15 fields like this: MyUDT[v42].field1, MyUDT[v42].field2....MyUDT[v42].field3 (this has to be done manually because I can't index the field numbers). At this point I could then index using V42 in stage to write out my 52 memory block. Is this correct?

Yes, the JSONBUILD can do it in ONE instruction - it supports a very useful tool for including all the fields of a structure.  Enter MyUDT[V42] and it will fill in all 15 fields (it assumes that the JSON field name is identical to the UDT field name).  It's cool.

However, JSONPARSE is not table based.  Hence one JSONPARSE box can parse ONE field.  You have to have 15 of those on the "read" side.  It's not that hard.  See the example.  It makes sense.

[RBPLC]

Thanks franji for the help. I haven't looked through your examples yet but I understand the general concept. What I was missing was the "Insert Structure Fields" button within the JSONBUILD command. It is indeed pretty slick now that I've found it. I haven't attempted the read portion yet but the writing procedure does what I want it to do and with the JSON format it's human readable. On a related note, I'm running this with Simulator to try these reads/writes out. I'm looking at the general output of the .txt file to see if it's what I want, formatting wise. I'm running across the attached error when trying to copy the text file from the simulator ram to my desktop to look at it. Thoughts? I've tried this on 3 computers and only get this message on one of the three. On the other two it's just slow transferring the files between Sim and computer.

[franji1]

I'm going to guess that your PLC program never executed a FILECLOSE command, and it still has that file open.  Hence, when the communications driver in the PLC attempts to open the file to read it to transfer it up to Designer, the O/S is telling the comm driver in the PLC that the file cannot be opened (because it is already opened).

Or the FILECLOSE command executed, but then the program did a FILEOPEN?

Make sure you have stage transitions on your FILECLOSE command, and don't just immediately EXIT.  I did this wrong in my forum logic, but I corrected it in the example (so maybe this is the issue).

"Termination" should be something like

SG S4
FILECLOSE OnSuccess JMP S5 OnError JMP S99

SG S5
EXIT

I bet that's it.

[RBPLC]

I'll check that (program) out but I wonder why two computers would save the file and one would not. It's the exact program between the three with no changes.

[franji1]

With a RAM drive, the FILECLOSE could just immediately work, so EXIT in the same SG may work, but this cannot be assumed.  Not sure why it did not work on the 3rd one, but FILECLOSE/EXIT needs to be in separate/sequential stages regardless.

It could be you were doing Browse File System from Designer operations when the 3rd PC was trying to perform FILECLOSE? ? ?  Grasping at straws.  Fix the termination behavior and see what you get across the board.

[RBPLC]

I'm looking through your example, in the ReadBlock program in S2, shouldn't the D199 register be incremented by one with each instance of the JSONPARSE command? Currently they're all writing to the same memory address D199?

[franji1]

I'm looking through your example, in the ReadBlock program in S2, shouldn't the D199 register be incremented by one with each instance of the JSONPARSE command? Currently they're all writing to the same memory address D199?

Agreed (see my note at the end).  That parameter is an optional status register telling you what it actually parsed, or if an error, what the error was.  Typically, you would process D199 in the rung IMMEDIATELY after the JSONPARSE if you had any concerns.

The Help Topic for JSONPARSE (DMD0454) shows how the bits in that DWORD should be interpreted if you ever need to crack it.  I put that D199 there just in case there was a failure.  I guess I should have D199:SW1 == 1 in the following rung (the HIWORD as a signed integer will equal 1 when it works, it will be 0 or negative if it failed; details of what was parsed is in the LOWER 2 bytes of the DWORD - see the help topic).

STR ST1
JSONPARSE ... D199

STRE D199:SW1 == 1  // previous JSONPARSE parsed OK?
JSONPARSE ... D199

STRE D199:SW1 == 1  // previous JSONPARSE parsed OK?
JSONPARSE ... D199

...

STRE D199:SW1 == 1  // previous JSONPARSE parsed OK?
JSONPARSE ... D199

STRE D199:SW1 == 1  // last JSONPARSE parsed OK?
JMP S3

That's not to say you could not have a different D for each one like you suggested.  That is definitely good to help diagnose when there actually is a parsing error of some kind (either JSONPARSE logic is wrong, or possibly the FILEWRITE was wrong when that record was written to the file).  That's probably something worthwhile, just in case of some issue.

[RBPLC]

Have you seen display issues like the attached before (JSONBUILD)? Is there a display setting that could be causing this?

[franji1]

No.  Sorry about that.

I did not see that as I was developing that project.  I wonder if there's a certain setting (documentation, zoom level, status, etc.) that is causing it.

We will look at it.