rslogix 500 compare longs

[zachary.wilson]

Howdy Everyone,
We are working on a project in rslogix 5000 where we are using an rfid reader to read the barcodes then if they are on a list of Dints we use a file search/compare and if the barcode is on the list of autorized users it allows them to reset certain faults stuff like that. We have one machine that we need to do this project on but it is 500, i don't think it has the FSC like 5000 does, the only way i can think of to do it is, have a whole bunch of lines and everyone one of them have a equals line to, so if it is equal to it, it moves a 1 into another integer and then we can go from there. Is there another way of doing this? just seems like it would be alot of lines to do that, plus with people constantly leaving or starting, updating the program to accept these other people. in 5000 we are pulling from a list in ignition that constantly downloads to it so it keeps the list up to date. thank you.

 

[drbitboy]

LBL and JMP can do it in one rung, but you might need to avoid a watchdog timeout. If the list is sorted, then a binary search, still in a loop, would solve any speed issues. Also, you could set it up like a MSG instruction that starts the search by assigning a value of 0 to a DONE bit, then doing one or a few steps of the search on each scan, assigning a value of 1 to that same DONE bit when either the search Long is found in the list or all elements of the list have been checked with no match.



Maintaining the list and its length (FIFO?) is probably the bigger problem in 500, not to mention that 500 is limited to 256 in any single list (but you can have multiple lists; also there may be a hack where I believe you can read past the end of a Data File via indirect addressing).

 

[lostcontrol]

You could consider moving the lookup function to ignition.
That way, you don’t have to worry about maintaining the table inside the PLC.

Yes, there will be some latency compared to doing it in the PLC, but if it just for login etc makes more sense to me.

 

[zachary.wilson]

Howdy Thank you for the quick reply,

drbitboy, so are you saying using the jmp and lbl to pretty much keep it scanning there until it is happy? then once it is happy let it out of that area? Sorry i am not use to using the jmp and lbl features in plc. I have used them in robots but not here. We will only do this about once a day (hopefully never unless there is a fault).
Really at most there will be maybe 10 people assigned to this list who are authorized. I figured i can just always keep the lines scanning and if they equal, it will move a one into an integer and then that will start the sequence. I just don't know if that will cause speed issues using the longs like you were saying.


lostcontrol, initially that is what we were going to do, unfortunatly our connection to ignition is out of our control (IT controls that) and is not reliable at all(another IT issue), that is why we wanted to download it to the plc and use it that way


I attached a screenshot of what i was thinking, just don't know if that will work, or will horribly slow down the machine, plus if there is a faster/better way of doing it i am all ears. looking for these big numbers all the time. THanks again.

 

[lostcontrol]

No attachment..

Considering the low count of FRID users, is there any pattern to the received no?
Can you just identify them by the LSB of the code? That would solve a few issues with the RS500 side maybe

 

[drbitboy]

No attachment..

Considering the low count of FRID users, is there any pattern to the received no?
Can you just identify them by the LSB of the code? That would solve a few issues with the RS500 side maybe

Ooh, this is good: user 0 is INT 1; user 1 is INT 2; user 3 is INT 4; etc. i.e. user N is 2^N. So up to 32 users with a Long.

Then you have a mask for various permission levels, do a bit-wise AND with the mask, if the result is non-zero, then they are allowed to run rampant.


Check out my LBL-JMP loop that will be posted shortly in this thread.

Loops are not often used, except by dilettantes like me who are comfortable with them, in PLCs, because an error could fault the PLC and cause real process problems, injury, death, etc. And to be fair, for ten users, by the time you read this you could have had it coded.


If the list changes from over time so re-coding would be cumbersome, then you could set up ranges of numbers with extra room for future users, and each range gets a specific set of permissions. E.g. even with half of a 16-bit unsigned INT you could have e.g. 32 different permission sets with up to 1024 users in each set, that would be five different yes/no permissions. Or 64 different permission sets with up to 512 users in each set.

 

[zachary.wilson]

Yeah sorry about the attachment, It allowed me to send the message, but not the attachment from work. When i tried to send a follow up message saying that, it wouldn't even let me send that.
No they just give the next number in order, so no clue if it is salary, hourly, maintenance, IT, HR, it has no set of numbers.


So L11 would be the input from the RFID reader, and L12:1-10 (or however many i need) would be the pre entered numbers from ignition, and then if they match it moves a 1 into the n7:3 and that allows buttons to become visible and stuff to happen in the PLC. Like i said, not sure if this would cause issues in 500, or better ways thanks again for the answers.

 

[cwal61]

You could use an ADD instruction to create an indirect address for your lookup file. It would ADD 1 to an index tag each scan cycle. When index tag GEQ 11 MOV 0 into index tag to restart. So, it would take 10 scan cycles to cycle through the array. If you only have 10 tags of index value, 10 rungs of brute force would be solved in a single scan and actually be solved faster.

This is thread with a similar task. http://www.plctalk.net/qanda/showthread.php?t=111043

 

[drbitboy]

As @cwal61 suggests, the images below show how to do this with a loop in RSLogix 500.

The JMP/LBL loop will terminate during each scan when

• EITHER the NEQ evaluates to False, because the RFID matches an entry in L12,
• OR the LES evaluates to False, because all entries in L12 have been compared to the RFID

and even if the NEQ always evaluates to True, each time that happens the ADD will run before the JMP runs, which ADD increases N7:4 by 1, which must eventually cause the LES to evaluate to False.

So the loop is guaranteed to terminate in 10 (or L11:1) passes or less.

TL;DR

• Rung 0000 - Initialization
  • FLL assigns 0 to both N7:3 and N7:4
    • N7:3 being 0 means access will be denied unless a match is found
    • N7:4 will be the index for stepping through the L12 Data File entries
      • L12 comprises RFID matches that allow access
• Rung 0001 - Loop
  • LBL is the target of the JMP
  • NEQ compares the RFID value (L11:0) to the next entry (L12:[N7:4]) in the list of possible matches (L12:0 through L12:9)
    • If that NEQ evaluates to True, then that next entry (L12:[N7:4]) is not a match to the RFID,
      • In which case the ADD increments the index (N7:4), and
      • the JMP passes execution control back to the LBL at the start of Rung 0002, continuing the loop
    • If that NEQ always evaluates to True, because the RFID will not match any of the values in L12,
      • Then the ADD keeps incrementing the index (N7:4), and
      • the JMP keeps passing control back to the start of Rung 0002,
      • until eventually the LES evaluates to False when N7:4 (index) reaches 10,
      • after which execution control bypasses the NEQ, ADD, JMP, and MOV, and
      • passes to the next rung,
      • terminating the loop
        • with the initialized zero still in N7:3,
        • denying access.
    • If that NEQ evaluates to False, then that next entry is a match to the RFID, then
      • the ADD/JMP do not run, and
      • execution control drops through to the MOV, and
        the MOV runs, putting a 1 into N7:3,
      • after which control passes to the next rung,
      • terminating the loop,
        • with a value of 1 in N7:3,
        • allowing access.

 

[zachary.wilson]

Thanks again for the reply, i understand what you are saying for the jump label and how that would work, but i am not understanding what you are saying using the lsb of the code. I don't know what lsb stands for, In the last example (thankyou for that) they were number 0-29, are those just place holders for the higher numbers, or are you referencing the higher numbers somehow and using the lower numbers for speed? thanks again.

 

[drbitboy]

Thanks again for the reply, i understand what you are saying for the jump label and how that would work, but i am not understanding what you are saying using the lsb of the code. I don't know what lsb stands for, In the last example (thankyou for that) they were number 0-29, are those just place holders for the higher numbers, or are you referencing the higher numbers somehow and using the lower numbers for speed? thanks again.

LSB = Least Significant Bit (at least that is what I thought @cwal61 meant).

So this could be a bit-wise operation.

Users 0 through 4 are given RFIDs 1, 2, 4, 8, and 16, respectively.

All other users are given IDs that are integer multiples of 32 (so the low 5 bits, i.e. [1,2,4,8,16],are all 0s.

Then a simple [AND rfid 31 result NEQ result 0] rung would

• evaluate to True for users 0 through 4, allowing access, and
• evaluate to False for all other users.

This assumes you have control of the RFID values; if the RFID tags' already exist with random values then you are back to a loop.

Edit: Actually, now that I think about it, that is way more complex than what @cwal61 was suggesting. Instead give odd-valued RFIDs to users who get access, and even-numbered RFIDs to all other users. Then an even simpler [XIC rfid.0] evaluates True for the odd RFIDs, and evaluates False for the even RFIDs.