Speed Issues with Data Parse and String Compare

[DaveE]

Good Evening

I have a program that I am trying to write, well its written but doesnt work properly.

I am using RS232 communication to connect to a Microscan Camera

I am taking in the details from a 2D barcode and then breaking down the data into the following sections

GTIN

LOT

Expiration date.

I then get back from the Microscan, a long string, in which I have put separators to make the data parsing easier.

The string also contains the OCR of the text after the barcode

 

The string looks something like this

101234567891712345620123456789

where the first 2 digits are the identifier (10)

the next digits 123456789 are the GTIN code

the next 2 (17) are the identifier

the next 6 are the date (123456)

then the 20 is another identifier

and the123456789 is the lot/batch code

 

so basically what happens then is that the OCR strings do not have the identifier and I have to compare those to what is hidden within the barcode.

As I said it works, I can do the data parse, but with the compare vector functions I am using as well the whole thing takes about 1.3 seconds to complete and that is way too slow, Im sure it should e faster if I knew what I am doing

 

I would really appreciate any help with speeding up my program

 

The vlp (well part of it) is here https://www.dropbox.com/s/xos46oheg0azkfx/for%20forum.vlp?dl=0

The data parse and compare are all within the main routine

I am using a V350 plc

 

Thanks for reading

 

 

[Alexander]

The ladder should process in a matter of milliseconds depending upon how large the program is.

 

How is it taking over one second to process? Is it possible that the barcode takes a few seconds to scan and send from the camera?

[DaveE]

Alexander

I am working on putting a timer in from the start of the process to the end of the process...(Hate timers)  THanks

Will let you know

[DaveE]

Alexander

I put a timer in from the start of the process (rise in MB2) and the fall of the MB2 and its really fast, I cant get the timer to start!

If I take the end of the MB2 out I know the timer starts, dont  know what else to say!

[Alexander]

In the program that you previously linked, the subroutine is not being called from the main routine. This means that none of the ladder is being processed.

 

Also, it is recommended to have all power up tasks, such as configuration added to the main routine. This could be why the timer was not starting.

 

Also the MB you are timing only turns on once a message has been fully received. In order to time the whole process you would need to start when the function in progress bit (MB1) turns on, and finishes only when the message session bit (MB 2) turns on.

[DaveE]

Alexander

The program I sent was one small subroutine, that is in fact the main routine in the PLC. Everything else is called from that

I have placed the total project here....https://www.dropbox.com/s/h1yohqckc2b03s3/Version%2012.vlp?dl=0

I think everything is being called. Its normally the main routine that is running and then I jump of to subroutines when things go pear shaped!! (i am growing my own orchard)

 

I set the timer up as you suggested with the positive edge of MB1 starts the timer and the positive edge of MB2 turns on. I proved they are both working by adding counters and well the timer doesnt star (it does if I force it in online test). Therefore I have to guess its fast?

[Alexander]

It is likely that MB1 is only on for a very short period of time which would cause the timer to not complete. A TD timer only works when the powering condition stays on. So if MB1 turns off in less than the shortest time period available, 10ms, than the timer will not continue to run. This alone may prove that the ladder is processing very quickly and the barcode is being received quickly.

 

One other test you can perform is to use a utility program, such as Hercules, where you can see the incoming data from he barcode scanner. This would let you visually see if there was data that lagged behind.

 

How did you originally determine that there was a processing time of 1.3 seconds?

[DaveE]

Alexander

I have used, hyperterminal, and also Termite, and it would appear that the data is not lagging.

At the end of my string I have an end of text also, so I assume (probably wrongly) that the MB2 would not go high unless that end of text was received. I found this out by not putting the correct end of string and I never got a barcode string put into the relevant MI's.

 

My timing of 1.3 seconds was simply calculated from the start of the input trigger to the time until my output reacted.

If anyone of the compares do not match then I throw on an output to blow the box off the conveyor, and with the set up I have the output was not being set until the box had moved past the blow off. I am moving at 60 feet a minute and know how far the physical distance is, so its a matter of math.

[Alexander]

I'm able to get your program to receive a code, though I would need to know what process you are following that triggers the delayed output. Is there a certain series of steps I should follow?

 

What barcode are you sending to the controller? Has the code already been taught (Does this need to occur)?

 

What screen is displayed?

 

What output is supposed to be triggered when the barcode is received?

 

Once I have this information I will be better suited to test for the issues you are experiencing.

[DaveE]

Alexander
The process is that once the trigger has been activated, I have to wait a certain length of time that gets the barcode in front of the box.
Once that time has elapsed then the the barcode is read. I am sending a GS1 barcode along with some OCR Values that comprises of the following.
01057800902676101234567890*17063017
 This is the hyperterminal view of the incoming code https://www.dropbox.com/s/q8jxe6haxi7a5yi/IMG_3219.jpg?dl=0

and this is the microscan camera view of the code.

https://www.dropbox.com/s/qvl6dfq1r6xx5kn/IMG_3220%281%29.JPG?dl=0

Translation of what this is is
01057800902676  is a GTIN number (the first 2 digits are an identifier and need removing) this is a fixed length
101234567890* is a batch number with a character at the end that the barcode adds to let us know the field is ended. Its not a fixed length so I have to recognize this character and work out how long and what this field is, it also has the first 2 characters which are identifiers and need removing.
17063017 is a date code. Again the first 2 characters need removing, but is always a 6 digit code after the stripping.
These codes are set into MI's for comparison.
 
The string that the camera sends is 01057800902676101234567890*17063017@057800902676^063017&12345678904
The part after the @ is the OCR values that the camera has seen and needs comparing to what is within the data string.

(This is where I have to apologize for the code, I know its messy, but I was trying to reduce the number of lines that were being processed by the PLC)

All of the string is placed into MI 100 when it comes into the PLC. . During the RUN this code is changed. In teach mode, yes it needs to be taught it is taken from MI100 and copied into MI1000

 

If you look at the TEACH subroutine then the comments as to what is happening during the subroutine are still there (or what should be happening)

 

so to continue.the last digit of the code shown in the hyperterminal is the quality digit code.

 

To further answer your questions . The routine that runs when the code is being scanned and not taught is the main routine. The screen that is shown is the RUN screen.

Once the barcode is read and received by the PLC MB2 is the bit that goes high.

 

Once the barcode is read by the PLC I would then parse out the data. and do the comparisons to what was taught and what was read.

Just to confuse maters further, there are 2 compares for each part of the barcode (above) one is the actual data in the barcode and one is the data in the OCR string. However they should match each other if the printing and coding is correct.

[Alexander]

I am able to teach and receive the code. It received the code so quickly that the timer isn't able to decrement past it's starting value. Yet I see that the function in progress (MB0) and the session complete bit (MB2) have turned on and off. Since you are experiencing the same results it seems as if your barcode scanner itself does not seem to be the reason for the delay.

 

Once this code is received where is the output that it turns on/off for your conveyor belt?

 

Can you specify a particular subroutine/rungs of ladder that control this output. I would be surprised if anything in the ladder was preventing the output from changing states.

 

Are you also basing you delay from when the barcode is scanned (on the scanners hardware) or when it is received by our controller? Since I am unsure what hardware you are working with it is still possible that the barcode scanner may take a second to process what it scanned and then send it to our controller. Have you been able to contact the scanner manufacturer to see if this is the case?

[DaveE]

Alexander

The conveyor is running all the time.

the comparisons that I am doing are turning on/off the bits.

Rung 47-79 in V12 is the comparisons

For example if the code is a no read it matches the "no read code" in MI78 then the comparison bit MB 41 goes high

If the OCR GTIN bit does not match then bit MB91 goes low

there are several more there.

When these bits change state the blow of output bit MB 114 is set and then on the leading edge of the I3 the blow off eye the low off starts (rung 65)

 

The barcode reader is simply sending out strings, it doesnt do anything more than that, so I would have thought that as soon as the MB2 bit is set high then the barcode scanner has finished its job, and its sitting there waiting for the next scan to happen.

The scan can only complete at the end of the string from what I understand. and as you said yourself the session complete bit is really fast. Thats why I thought and still think the comparison bits are slowing me right down, which doesnt make sense either

 

The issue is that on the comparisons the bits are so slow that the blow off happens after the I3 has been made.

 

The hardware itself is a Microscan GMV-6800-1006G: Vision HAWK smart camera,  SXGA Mono, C-mount, Visionscape+AV+Verification/OCV along with your V350-J-T38:PLC

[Alexander]

I did see that you had two separate ways to set MB 114 in both rungs 68 & 69. This causes the parallel statements to cause a conflict, since the bits are controlled by their last state, which would mean that only rung 69 is causing the condition.

 

I would recommend combining these nets so that all the conditions that could set MB 114 are within the same net.

 

 

When is the blow off eye triggered? Does it always happen after a scan? I just want to know how you determined how MB114 is being set after I 3 is already being triggered. If this occurs then the output will not be shut off at all.

 

I also saw that the output (O4) has two sets of timers that need to complete before the output is shut off. These two timers are both 250 milliseconds which can account for 0.5 of the 1.3 second delay you are currently experiencing.

[DaveE]

If you look  at rung 65 and 66, these are what causes the setting of MB 114. (all possible compare failures)The I3 will only work if MB 114 has been set, ie if its a good read then MB 114 will not be set and therefore I3 will not be triggered, and the O4 will not become active at all

at that same time MB 134 is set, and the positive edge of that bit resets the MB114 to allow for the next box to trigger if a fault occurs.

With regard to the O4 in rung 68 - 72

If the MB114 has been set then the eye makes, I delay a time (in fact that time is set in a recipe) after that delay time I trigger the O4.

I need to hold that output on for a length of time therefore I have an output hold on timer, but by the time that is finished everything should be reset

[DaveE]

I have also replaced the program, because I want to make sure we are looking at the same numbers!

https://www.dropbox.com/s/h1yohqckc2b03s3/Version%2012.vlp?dl=0

[Alexander]

The logic you have for Input 3 and MB 114 won't be triggered unless MB 114 is set first, but I'm not sure what triggers I3. When or how is this input activated?

 

What you can also test with is putting the unit in stop mode when online. Then there is an icon in the online test window to perform only 1 scan of the ladder. I performed the following test.

 

Put the controller in stop mode

Send the barcode the controller (it will reside in the buffer)

Press the icon to execute 1 ladder scan

All of the ladder triggered to receive the barcode, compare it, and it activated MB 114 all in a single scan

 

It should not be the comparison that is causing any problems as it activated within a single scan of receiving the message

 

Do you get the same results?

[DaveE]

I3 is a photo eye that detects the boxes as it goes down the conveyor, after the scan (its called the blow off eye)

[Alexander]

So the scanner is physically first on the conveyor, followed by the photo eye? It should be able to have the information processed in time as long as the scanner can transmit in that period of time.

 

I would again recommend contacting the scanner manufacturer to verify how long it takes them from scanning the code to sending it to our controller.

[DaveE]

Alexander

Thanks, I am working on both of your last posts now

[DaveE]

Alexander

I did your test above and I get the same thing as you.

I have been talking to the manufacturer of the scanner and they tell me that it can take up to .75 of a second to get my result, so thats half the delay I was looking for. I am still looking for the rest....

[Alexander]

There were the 2 timers in the program, each 0.25 seconds that had to complete before output 4 was reset. This added to the 0.75 second delay would result in a 1.25 second delay.

 

After the first time it sets output 4, then it resets output 4 another 0.25 seconds later.

 

Is the time calculated from when the output is turned off after the second timer?

[DaveE]

Hmm

I have an issue then

I want the timer to come on to delay the turning on of the blow off, I also need that blow off to stay on for a length of time so I know the box was blown off, how do I do that without causing a delay (In fact the time for one of them is down to 0 (its set in a recipe)

 

(I do have a verify sensor to check that the box did get blown off)

[DaveE]

Alexander

the bit is started with a rise of the input from the photo cell

that rise causes MB134 to be made

while MB134 is true I run the first timer, when it times out I turn on O4 and reset MB134 and turn on MB135

while MB135 is true I run the second timer, when it times out I turn off O4 and reset MB135

 

I wish I knew how to post thumbnails!

[Alexander]

The process as far as I can tell is this:

 

1. The Box passed by the barcode scanner and is read

2. Up to 0.75 seconds passes before the scanner sends the information to the PLC

3. The PLC receives the information and if the scanned code is incorrect, turns on specific bits to eventually activate the Blow Off output

4. The photo eye detects the box. As long as the blow off bit (MB 114) is active it will set a bit (MB 134) to set a 0.25 second delay.

5. After the 0.25 second delay the Blow Off output is turned on.

6. The Blow Off output is turned on for 0.25 seconds also, then is shut off by the second timer.

 

Using this sequence that requires the delay between the photo eye and turning the Blow Off output on, I do not see how to shorten this time. It's dependent upon the scanner to send the information to our PLC and the delay after the photo eye to enable the Blow Off output.

 

The information from the scanner should be arriving and being compared all within a single scan, which only takes 8ms in your program. You can check the scan time by monitoring SI 0.

 

Is there any other way to modify your program? For example have the conveyor temporarily stop until the bar code is read and then continue with any necessary delays?

[DaveE]

Alexander

I just want to let you know after a 20 hour rewrite session, using 2 FIFO's (that I had to learn how to do) , a reconfigure of the conveyor and total minimization of using timers it appears that I have succeeded in getting the speeds I require.

I really appreciate the assistance that you gave me in this time of total chaos.

 

Thanks