FSC funtionality

Team,

I have a pick-2-light that does something odd.

Issue: When materials scans a barcode, if the barcode has not been asigned a bin location, Rack 1, bin 15 lights up.

Back ground info: Allen Bradley PLC, we have 2-15 bin racks side by side. Operator scans barcode and the plc, using two FSC functions, looks for the correct bin. IE Rack 1 bin 2 or Rack 2 bin 2.
As mentioned in the Issue Section, if a barcode is incorrect, or has not been assigned a bin location, bin 15 on rack 1 lights up.

I have several of these stations, this is the only one that does this. I have deleted the entire routine and copied over the routine from a sister station that works good. No change.

I haven't used FSC functions very much, they seem to work out well if you have the presets done correctly. I am just not sure if there is something I can do to "test" this function out.

I currently have some logic that compares what is scanned to what is actually assigned to that location and clearing the scan data in the event the FSC finds bin 15 with the wrong part number.

I asked my contact at the integrator about it, he said that was something they tried because they figured it would be less code writing to use that function, but that they did struggle with it to work properly during development. He did ask to shoot him an email about what I did to correct the issue so that he can not do whatever it is he did to cause this.. if anything.

Currently the fire is out, but I feel there is something that I am missing.


Gad

Can you check whether the FD bit is actually being set when this occurs? (Note that your logic may clear it immediately so you would never 'see' it as on visually)


Since you've copied the routine from a program that doesn't have this issue, I'm suspecting somewhere else in the program there's a check for the DN bit that should be FD instead. The FD bit is set when the instruction finds a match, while DN is set when it finds a match or when it finishes iterating without finding a match, in which situation POS will be the final element of the array -- exactly as it would be if the final element was a match.

Follow up:

I spent some more time crawling through the routine and looked for .DN where it should be a .FN and no luck.

I did find out that the sister machine is having the same issue, but we didn't notice it because that bin has always been empty AND the light was broken, so we never noticed the issue on that station.

I'll scratch my brain a few more times and update if I find a resolution.

You would be looking for the FD bit (not FN) and I will have to refresh my recollection of how that bit is cleared...your logic might not be handling the FD (found match) bit properly. From what I remember, that bit will stay set until your code clears it. The DN bit simply means the FSC has reached the end of the file it is searching through and will be set whether or not a match is found.

I agree that not properly checking or handling the FD bit is the most likely cause.

On digging in the manual a little, there seems to be some inconsistency in how the DN bit is handled -- its description is "The done bit is set when the instruction has operated on the last element (.POS = .LEN)" but in the Rung-condition-out is True flowchart it shows as being set after the FD bit when a match is found (which would not necessarily be when .POS = .LEN)

https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf

If the DN bit is set when a match is found, using it would provide the same functionality as the FD bit when there is a match, but if there is not a match it would appear to find a match in the last position.

As that appears to match what you're seeing, I suggested it as a likely possibility.

EDIT: The IN bit might be used instead of FD

My apologies, I meant FD not FN.

I started to type out a wall of text, and I think I may have figured out something.

Logic runs FSC.
FSC doesn't FD but it does reach DN.
When its DN, it stops scanning.
The bin logic looks for Search.POS.
When the FSC is DN and no longer enabled, the Search.POS is stuck at 15. (I presume it works similar to a retentive timer and doesn't reset unless told to)
This would light up bin 15.
I think I am going to do a mov function that only performs the move if the FSC reaches FD.
With a delete function that clears out the scan data in the event DN but not FD.

Now to go test my thought process and see if I can let production give me a few min to poke around..

Will update my results once I test this out.

You are correct. The FSC instruction will scan through, stopping either when it finds a match (in which case it sets FD and IN) or when it reaches the end (in which case it sets DN), and does not clear itself. POS will be the position it stopped at regardless of whether it found a match or not.

It sounds like whoever did the original setup didn't realize that checking FD was needed to verify a match was found.

In your logic use FD as indicating a match found, and DN but not FD as indicating no match found.

EDIT: It's not relevant here, but if you needed to check for multiple matches you would clear IN to allow it to continue scanning from where it stopped.

Update:

My thought process was correct.
The rung that handles the bin locations did not have a FD bit.
When the FSC would stop, it would end up on the last bin... bin 15 on this machine.
By adding FD I stopped getting bin 15 for valid part numbers that are not assigned to that machine, although prob not required, I've added FD to every rung just to be safe.
I also added DN but not FD to the invalid scan to clear everything out.
Everything works now, thank you for being my sounding board... sometimes I just need to talk my way through it.


Gad