RSLogix 5000 FSC glitch

Join Date
May 2019
Location
England
Posts
8
Hi there.
In RSLogix 5000 i have an array of barcodes, and used an FSC bit to find which array position an input barcode matches. However when the input barcode matches the barcode in array position 0, the FSC does not complete. It does not trigger a found bit, but this works fine for all other positions in the array. Is this just a glitch with FSC bit and the way it operates, or have i done something wrong?
Guessing the FSC bit although seems to reset to 0, starts searching from position 1, rather than 0?
Just after a better understanding of the operation, or of there is another simple alternative that works better.
Cheers
 
For starters, can you post a screen shot of the rung containing the FSC instruction?

One thing to make sure is that the FSC has been reset before starting a new search. A reset instruction is a convenient method for this.
 
reply

Thanks for the suggestions. I actually reset it if it fails, and if it completes, i believe it is re-setting itself with disabling and enabling the rung. Attached is my code as requested.
Will try your suggestion of a reset at the start of the instruction.
Cheers

FSC Instruction.JPG
 
One suggestion is to remove the XIC and OTU with CaseCheck.DN from rung #6. Also when BARCODE_MATCH is latched, BARCODE_SEARCH should be unlatched. This will require a reset of the FSC before starting the search, such as with a one-shot on BARCODE_SEARCH being latched. There are other ways "run out" the FSC after finding a match.

I could be missing something because it seems like this code will only work correctly when the barcode being searched for is in the last position of the TOS.Barcode array, not when it is in the first (zero) position.
 
Correct. That last rung isn’t going to work correctly. We will never know if there is a match at any position but the last position. Also, I wonder if they want to resume a search. If they find a match in position 43, should we resume searching from there through to the end? Or will it only ever match in one single position?

Assuming it will only match one position, I would change the last rung. One the input side leave the FD bit, remove the rest. On the output side keep the MOV then add a RES for Casecheck after the MOV. Get rid of the unlatches. They only add confusion and that is what the RES is for. Keep the Barcode_Match OTL at the end.

This is executing every scan. I would change that to only execute if the CurrentBarCode value has changed. If the value hasn’t changed, we don’t need to keep performing the search.


OG
 
The FSC will work for 1 match but what it you have more than 1 match you wil only find the first match
to let ti run on and search for aditional matiches reset the .IN bit
from the old days I always keep .POS empty
I think the reasion you can't fine the match in pos 0 is the way the index in incremented
it looks like tye increment it and then do the compare with it always starting on 0 it will skip pos 0
also you don't need to clear or reset the FSC .POS index, it is reset to 0 when the rung goes false
 
As OG and Gary have said - use the RES instruction to reset you FSC instruction, and forget about unlatching bits and setting the position back to zero manually. That'll be the root cause of your issue.
 
After reviewing Gary's comment and looking closer at rung #6, I stand corrected. It will work for a match anywhere, not just the last position as I had said before. The .IN and .FD will make that happen.

I'm not sure why the inputs are so convoluted though. Seems like you just need the .FD and BARCODE_SEARCH. The .EN, .DN, and the .IN aren't really necessary. BARCODE_SEARCH and the .EN will track with each other. We don't care if the .DN is set to have a match. It isn't relevant to a match. and the .IN and .FD will also track with each other.

With that in mind, on rung #5 the unlatches and the MOV are unnecessary too. When the FSC is done and then BARCODE_SEARCH goes false, all of those are automatically reset.

My guess here is that those unlatches occurring before the MOV are affecting the result when it is on the zero position. As I stated previously, I would use a RES after the MOV. But if you insist on the unlatches, try putting them after the MOV.

OG
 
Last edited:
I tested your logic and saw the same results. I placed the MOV on rung #6 ahead of the unlatches and it worked. It found the match in position 0 and the other positions as well. No other changes. Below is a cleaned-up version that also works. Note I only tested 10 positions instead of 60. And I named my array differently in the FSC expression. I also added an unlatch for the match bit.

OG

FSC.png
 
Last edited:

Similar Topics

Hello, Please Help! I have an array of 20 registers that I want to search for a value. There will be over 100 DINTS Values that come in and if the...
Replies
7
Views
1,777
Hello Please Help, I want to use a FSC instruction that will scan 20 DINT arrays. If the arrays are greater than 1000 display the value. How do I...
Replies
4
Views
1,706
Hello all, I have a question in regards to RSlogix 5000. I am having issues with the program force closing when I try to make online edits. We...
Replies
0
Views
95
Greetings ... someone sent me a request for some student handsouts that I developed ... turns out that I had this hosted on my business website...
Replies
0
Views
109
Thank you for any and all responses/help. I have an RSLogix 5000 v20 and a Cognex In-Sight v5.9 spreadsheet (8502P). I can not figure out how to...
Replies
0
Views
101
Back
Top Bottom