rslinx excel need help

[Lancie1]

the excel spreadsheet gives #N/A past N101:200

Heehoo, that makes sense. For N101:201 to N101:248 to have any values (other than blank or 0), then somewhere in the logic, your PLC program would have to set N7:68 to the values for the range from 201 to 248. Most likely if you search for all occurances of N7:68, you will find that it has only set values for the first 200 numbers (indexed from 0 to 200). You will have to change some logic to create the remaining values.

As other said, if you go above N101:255, you will have to move everything to another file, such as N102 if it is unused.

5. It has been split up like this because of the 256-element file size limit.

I don't think that will explain the split in this case. One FFL could easily load all values from N101:1 to N101:255 (which is more than the used range of N101:1 to N101:248).

 

[daba]

Heehoo, that makes sense. For N101:201 to N101:248 to have any values (other than blank or 0), then somewhere in the logic, your PLC program would have to set N7:68 to the values for the range from 201 to 248. Most likely if you search for all occurances of N7:68, you will find that it has only set values for the first 200 numbers (indexed from 0 to 200). You will have to change some logic to create the remaining values.

It is not N7:68 that provides the "pointer" into the N101 file, it is the .POS register of the FFL control structure. N7:68 contains the data that is stored in successive locations of the FIFO.

As other said, if you go above N101:255, you will have to move everything to another file, such as N102 if it is unused.
I don't think that will explain the split in this case. One FFL could easily load all values from N101:1 to N101:255 (which is more than the used range of N101:1 to N101:248).

Very true, I didn't add the lengths together, I just assumed they had to do it that way.

Anyway, there is a way to overrule the 256-element limit for indexed addresses. There is a bit in the status file "Index Across Data Files S:2/3", which will suspend the processor checking of the index going above 255.

This does not mean you can have data-files bigger than 256 elements, but instructions that use indexable destinations, like FFL etc., can be made to work with a data structure greater than 256 elements.

To use it, you have to have contiguous files, so what I wrote in a previous post could be served by just one FFL with a length of 500

It may be an advantage to create the files thus...

N100:00 to 99
N101:00 to 99
N102:00 to 99
N103:00 to 99
N104:00 to 99

The actual position in the whole data structure is easily read as the last three numeric digits - and if you want to find reading number 357, then it is simply N103:57

Strike that idea : the FFL instruction will not compile due to file length error !

 

[Lancie1]

N7:68 contains the data that is stored in successive locations of the FIFO.

Yes, and somewhere N7:68 will need to be set for 249 different values at different times. That may be done in a For-Next loop, or with a counter that counts from 1 to 248. I would guess that N7:68 changes to a new value each time that B3:2/7 goes true and Timer T4:6 reaches the 90-second cycle time.

 

[daba]

As other said, if you go above N101:255, you will have to move everything to another file, such as N102 if it is unused.
I don't think that will explain the split in this case. One FFL could easily load all values from N101:1 to N101:255 (which is more than the used range of N101:1 to N101:248).

Actually there is a 128-element limit for a FIFO...

Got this from the FFL Help...

Length is the maximum number of elements in the stack, up to a maximum of 128 words. The same number is programmed for the FFL and FFU instructions.

 

[Lancie1]

That's right! I had forgot. That explains the split into two FFLs. Now if we had a copy of the logic that sets N7:68 for each new value, we could recommend some changes to get the remaiing values.

This all assumes that those additional values EXIST. If the data are only created for each ram machine run, it seems it would need to run 248 times to even need to put values in all the slots.

 

[daba]

To Lancie1

I'm wondering if this cheat may work, as RSLogix500 prevents you entering >128 for the length of a FIFO, it may be possible to wangle it this way.

I'll break out my SLC tomorrow and try it...

 

[heehoo10]

ok, i took out the program files that dont matter, the one im trying to fix is LAD 8 - RAM_FOLLOW

 

[heehoo10]

Most likely if you search for all occurances of N7:68, you will find that it has only set values for the first 200 numbers (indexed from 0 to 200).

here is something that has N7:68, do you know what this box means/does?

 

[Bob O]

MUL is multiply and what it is doing is multiplying the value in F8:8 x 1000 and place the result in N7:68.

 

[heehoo10]

oh ok, i wonder why its multiplying by 1000, since it divides by 1000 in the excel code:
=(rslinx|'T15'!'N101:1')/1000--0.01

Also, Idk what im doing so I added 2 FFL along to the existing 2 and created N102 with same number of elements, I also put R98:5 and R98:7 in the code the same way that R98:1 and R98:3 were in the code already. The left hand side is the same for the FFL picture, and above these 2 are the original 2, i have no clue what i wrote, and idk if it makes logical sense or not, i jsut followed the pattern that was there

 

[jkerekes]

This is a common technique. You multiply floats by a factor of ten, to convert it to an integer with an implied decimal point. Then when the number is used somewhere else, you divide the number again to get back the original float number. We did that in earlier processors, because Floats took up large amount of memory.

 

[daba]

heehoo10 : check your PM's

 

[Lancie1]

here is something that has N7:68, do you know what this box means/does?

The key is finding the trigger that causes N7:68 to change values, because it would need to change 248 times for you to see values in your Excel spreadsheet.

Following your logic rungs backwards, I arrive at Main Lad File 2, Rung 009, where B3:0/14 is the key. Apparently B3/14 is set in one of the OTHER ladder files. Every time that bit B3:0/14 goes true, analog input I:5.1 (unindentified) is read, moved, subtracted from the previous value of I:5.1, divided by F8:29, saved in F8:8, and then in File 8 Rung 5, F8:8 is scaled up by 1000 and stored in N7:68. N7:68 is the value that must change 248 times in order to fill all the data values that will be moved to your Excel spreadsheet. Therefore bit B3/14 must go on and off 248 times in order to fill all cells in your spreadsheet.

B3/14 is the trigger that creates your data. All the other stuff is bells and whistles that scale and convert the I:5.1 into the desired type and range.

 

[Chuck Woodbury]

Is it an array? Can you go to the first box and see if it says L200, C1? That would be Lines 200 columns 1 and change the 200 to 400.

 

[Lancie1]

Chuck, I see no arrays. Here are selected rungs. A search of the two files provided by Heehoo found no other occurances of B3/14, which shows the folly of trying to pull out only the files needed for certain functions. (Zoom your screen to about 150% to read the text in this picture).