Generate Fixed Length Serial Number in RSlogix 500 / SLC500

I have a simple problem, but a simple solution eludes me.

I need to generate a string with the last 5 digits being serialized each time the string is generated. For expample:

BYPASSED000000A0000001
BYPASSED000000A0000002
BYPASSED000000A0000003
.
.
BYPASSED000000A0009999

The string always has to be the same length. I've started with a string for the first group of fixed characters. I am using a counter to generate the serial number. I use AIC instruction to convert the counter value into a string. If I use ACN to concatenate the two strings, the length will vary because AIC does not create leading 0's.

I have a solution, but it seems like a long way around a simple format instruction to put in leading 0's. Am I missing an easy way to do this?

A couple quick questions and the beginning of an idea,

• How large will the serial number grow? It's easy up to 32767. A little harder to 65536 but much harder after that with a counter
• Is the string part at the beginning fixed?

I don't have the total solution here but maybe the easiest way is to have a series of counters that just count 48 to 57 (These are the ASCII codes for the digits 0 through 9). Each DN bit would reset that counter and increment the next higher units counter. I believe there is a way to MOV or COP the numbers into different positions in the string but I'm not sure of the addressing. You may also have to do a shift left by 8 bits on every other character as they are stored two characters to a word. Lastly, I'm pretty sure they are byte swapped that wouldh have to be accounted for as well.

One last issue is that you will have to be careful about upload/download of programs to the PLC after the run of serial numbers is established. On a download, whatever is in the PC will over write the PLC so you may want to have a way with an HMI to preset the serial number.

To the best of my knowledge there is no sting insert instruction in the SLC and there isn't a way to get at the individual bytes of the string. You could copy (COP) the string into an integer and work on it that way but that may be a bit unwieldy.

I'm at home and don't have anything to test this on. But I believe the ACN instruction uses the .LEN value to determine where the end of the Source A string is.
You could set up a base string with all zeros. Copy this to a working string and reset the .len field in the working string, which would be Source A, before triggering the ACN instruction.

Keith

kamenges said:

To the best of my knowledge there is no sting insert instruction in the SLC and there isn't a way to get at the individual bytes of the string. You could copy (COP) the string into an integer and work on it that way but that may be a bit unwieldy.

I'm at home and don't have anything to test this on. But I believe the ACN instruction uses the .LEN value to determine where the end of the Source A string is.
You could set up a base string with all zeros. Copy this to a working string and reset the .len field in the working string, which would be Source A, before triggering the ACN instruction.

Keith

Click to expand...

It's all in the addressing. Check out this thread:
http://www.plctalk.net/qanda/showpost.php?p=23039&postcount=6

Here is one solution I came up with.

ST16:0 is the fixed part of the string.
ST16:1 is used to pad leading 0's
ST16:2 is the counter's ACC value converted to a string
ST16:3 is the result

It seems like such a long rung to do such a simple task.

Go with Norm's idea. I didn't know you could individually address what I believe to be bytes in the string. That should make it pretty easy to insert the number wherever you need to.


Keith

Does it have to be completely in the PLC? Can you have part of the number on an HMI, and fill in the rest via PLC?

tomalbright said:

Does it have to be completely in the PLC? Can you have part of the number on an HMI, and fill in the rest via PLC?

Click to expand...

There is no HMI, so it has to be all done in the PLC.

Just a quick background:
The SLC 5/04 is on the very end of the assembly line controlling a box stacker. As the parts enter the stacker a barcode reader reads the label and stores it in the PLC to be retreived by a PC that is on the other side of the plant. If the reader does not read the barcode it will stop the line and require someone to scan the barcode with a hand scanner. In order to prevent complete backup of the line, there is a method of bypassing the barcode reading, but this has to be tracked. When barcodes are read by the PC and stored in a database, the query only retreives distinct records to filter out when a box gets scanned multiple times.

The idea of having the PLC generate a simulated barcode with a serial number is so the database query will report the number of times the barcode readers were completely bypassed. It will also eliminate the need to modify the PC software to handle exceptions because the PLC generated serial number will appear to be another valid barcode to the PC.

kamenges said:

Go with Norm's idea. I didn't know you could individually address what I believe to be bytes in the string. That should make it pretty easy to insert the number wherever you need to.


Keith

Click to expand...

Big Caveat here. The addressing in the string file is by word.

So:
ST50:2.1

Is the address in String File 50 of the 1st word in the 2nd string element.

BUT

That word contains two characters. That's why I talked about shifting the ascii codes.

I just rebuilt my laptop and don't have RSLogix installed yet so I can't do any tests right now but If you have few days I could try it out.

Tom has the right idea

tomalbright said:

Does it have to be completely in the PLC? Can you have part of the number on an HMI, and fill in the rest via PLC?

Click to expand...

I know this isn't any help except to say that you should get the right tool for the right job.
A C programmer could do this easily in one printf statement.
Mean while I will sit back drinking wine on my patio and watch you guys waste 1000s of dollars of collective time trying to solve this problem with the wrong tool.

kamenges said:

Just being cantankerous on a Saturday morning.

Click to expand...

What happened Keith? Your cantankerous wore off. I am canterkerous to the bone. You know that Tom and I are right.

Originally posted by Peter Nachtwey:

You know that Tom and I are right.

Click to expand...

I don't, actually. Sooner or later any 'right tool' you use needs to get information into the main control system and the data collection PC. Just use a digital input to the PLC to trigger the line to stop, you say? Sorry, we just burned that last digital input last week on a safety gate input. So we need to get a new input card for this. Well, then, just run it in through the serial port. Sorry, that would require me to give up my HMI, which uses the serial port to communicate. Well then just run EVERYTHING back up to the data collection computer and then route the stop signal back down to the plc. Now I have to jack around with the data collection computer, too. And I can think of no case where splitting the string development between multiple locations would make sense. Whoever gets it should do the whole thing.

Sorry, Peter. In this case I'll tap on that gear with a $5 hammer to pop it off the shaft instead of buying the $50 gear puller just because its the right tool. By the time I get the gear puller home I'd have the gear off anyway.

Keith

Hmm, Process in place, PLC in place. I'd find a way to do it in the existing hardware if I could. You know I'm an IEC 61131 proponent but this is not rocket science. Just some ascii and addressing stuff here.

Yes, Control Logix or some other system with Structured Text would work great but then everyting that exists and already works changes. The time saved on the s/n generation is lost on re-writing the whole program and debugging it.