A question from left field. If you're only dealing with '1' and '0' would a bit array not work as well?
The FSC will not work on a BOOL Array. The Expression only allows. SINT, INT, DINT, REAL and STRING
A question from left field. If you're only dealing with '1' and '0' would a bit array not work as well?
Ok, that makes sense. I would try the unlatch if I needed it to continue to search. What I'm trying to do is have it find the first available space in the array then MOV a 1 into it. After, RES the CONTROL tag for the next search. The problem I'm coming across is that it will fill the first two available places in the array but will then take 3 or 4 search attempts to fill in the next place. I'm wondering if it has to do with my ONS's. Also, I have it set to INCREMENTAL. Not sure if I should be using the ALL mode. I may attempt to upload the code.
Thanks guys
The FSC will not work on a BOOL Array. The Expression only allows. SINT, INT, DINT, REAL and STRING
I tried using a bit array but the FSC wouldn't take it. Daba said it runs more efficiently using Dints, I'm curious how much more efficient the Dint array would be over the bit array if the bit array was possible or how much more efficient than the Sints I'm using, I'll give it a shot. I'm really interested in the Dint situation because I ran my program test and it wasn't fast enough to file search through 52 files in time for the next box that came 1 second later. cwal61 looks to have something efficient.A question from left field. If you're only dealing with '1' and '0' would a bit array not work as well?
Would it work any quicker than using Dints? My file search has about 1 second to look through the 52 spaces before the next box comes and needs to search the file again. Although, I do have 4 lanes of 13 spaces to search through, maybe I can split the FSC of 52 places to search into 4 places then have an FSC for the 4 lanes of 13 after that. Sounds a lot more complicated though.Yes. But if only bits are involved it would take but a few instructions to put together a loop to search for a bit value of zero and return its position.
Unloading the 1's is done when a box has been picked from 1 of the 52 spaces and a clear timer of 2 seconds has been met which will then MOV a 0 to that place in the 52 sint array. I don't quite understand the "OTL SPACE[FIND_AVAILABLE_SPACE.POS].0"Looks ok to me.....
Any reason you are using a SINT array ?
Are you assuming it is more "efficient" because you only need to store 0 and 1 values ?
The controller has a 32-bit architecture, so works most efficiently with DINTs. I'll try to set up a test to see how much using SINT arrays knocks the performance.
Talking about efficiency, OTL SPACE[FIND_AVAILABLE_SPACE.POS].0 will be more efficient than the MOV 1, but is less transparent to a casual observer of the code. Properly documented should be OK.
I presume something else is "unloading" the 1's in the array.... Have you thought about what would need to happen if one of the cells was triggered and there ware no spaces available in the array ?
Unloading the 1's is done when a box has been picked from 1 of the 52 spaces and a clear timer of 2 seconds has been met which will then MOV a 0 to that place in the 52 sint array. I don't quite understand the "OTL SPACE[FIND_AVAILABLE_SPACE.POS].0"
Oh ok, I get it. So but would using the .fd to latch instead of .fd to MOV in the next rung allow the FSC to search the file faster? Or is this for moving the 1 to the available place faster?When the FSC finds the first available "zero" location, the .POS
register of the FSC Control will be the "position" where that zero value was found.
Ley's say this was at position 19 in the array, so SPACE[FIND_AVAILABLE_SPACE.POS] would enumerate to SPACE[19].
Now, to make the value in that location = 1 you can simply turn on (OTL) bit zero of that SINT, INT, or DINT.
So, OTL SPACE[FIND_AVAILABLE_SPACE.POS].0 will change the zero value to 1
As I said, it is less "transparent" than "MOV, 1, SPACE[FIND_AVAILABLE_SPACE.POS]", but would be faster execution time. The MOV will always inspect the destination element to see if conversion of data-types is needed. The OTL is just much faster, and achieves exactly the same result.
Oh ok, I get it. So but would using the .fd to latch instead of .fd to MOV in the next rung allow the FSC to search the file faster? Or is this for moving the 1 to the available place faster?
Anthony, I am not sure I fully understand. Please Explain What Your System Does.
It sounds like it is a pick and place. But I am not sure what you are picking.
1. 52 individual items
2. 1 item stored in 52 locations
Do you have 1 conveyor feeding 4 lanes?
Do you have 2 conveyors feeding 2 lanes each?
So how does moving 40 into the FSC length of 52 prevent overflow/PLC fault? Doesn't that length of 52 prevent the FSC from looking past 52 places? My sint (now dint array for efficiency) array has 56 places. Is there something I'm not understanding?If you need to Fill all 52 SINT then you could do this to manage the overflow.
You say you have a second to find an "available space" in the array, that is PLENTY of time to perform the operation... you could probably do it for hundreds of arrays in that time on an L71.