Array searching and inserting data to first available space

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

INCREMENTAL mode means that the FSC will search *one* array element each time the rung-in condition goes from false to true. If that one array element matches the search criteria, it sets the .FD bit; if not it increments the .POS ready for the next execution but does not continue.

ALL mode means that the FSC will search the array until it finds a match or reaches the end of the array each time the rung-in condition goes from false to true. If it finds something, it will set the .FD bit and stop looking; if it reaches the end of the array without finding anything it will set the .DN bit.

So yes, in your application, ALL mode is probably the correct choice.
 
The FSC will not work on a BOOL Array. The Expression only allows. SINT, INT, DINT, REAL and STRING

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.
 
A question from left field. If you're only dealing with '1' and '0' would a bit array not work as well?
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.
 
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.
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.
 
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"
 
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"

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.
 
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?
 
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?

I don't know why you are getting hung up on speed....

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.

Perhaps you've missed the "ALL" mode for the FSC, which finds next available space in one PLC scan.

Here's my take on your "problem" - I've used MOV instead of OTL to make it clearer.....

EDIT : Tested this - it works....

2018-01-06_130150.jpg
 
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?
 
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?

Yea, sorry, the screen shot should explain everything and my current issue.

Program Issue.jpg
 
If you need to Fill all 52 SINT then you could do this to manage the overflow.
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?

Thanks!
 
Based on what you've presented, it's not important where any particular 1 is, what's important is knowing whether there are 13 ones in a lane. Yes?

Filling the least significant bits, thirteen ones equal a decimal value of 8191. Maybe you could just compare with that value?
 
So I originally thought you wanted to find the first zero in an array of 52 and fill the next 12 spaces with 1's. That's what the 2nd FSC instructions did. The First found zero and the Second filled the 12 locations with 1. So to prevent overflow and fault you had to limit the start point. If you start filling 1's in at 41 + 12 it puts you at a 53 length. Which is greater than your array length of 52 and the FSC would fault the PLC.
 
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.

It sounds like there is something wrong with the way this program is being scanned. Is it in a periodic task with a very slow update period? Is there a relatively slow timer calling a routine containing this search logic?
 

Similar Topics

Good morning everyone, I'm working on a project where I am recording data from a machine by sending it message packets. Most of the time the data...
Replies
6
Views
2,130
I'm looking to see how I can search an array of DINTs to see how many occurrences of a certain value there are in the array. My thought was a FSC...
Replies
4
Views
1,342
I am using a UDT that has tool data. I need to query based on three values within an array of 43. ex. ToolData[43] DataType - udt_tool...
Replies
14
Views
4,997
Hi Guys, Is there an instruction suitable for searching an array of UDTs for lowest value? I can achive using a loop but figure theres an...
Replies
1
Views
2,551
Hello everyone, I'm working on a project that involves controlling an array of nozzles within a CNC environment, where the nozzles travel along a...
Replies
5
Views
118
Back
Top Bottom