S7-1200 Program Issues...

We installed a dual camera vision system a little over a year ago. The customer finally got around to using it recently. They called me in the other day because the trigger output to the first camera stops working. I revisited the program and found a couple of typos. I downloaded the new program, and everything seemed fine.

They called me today to say that it still isn't working. After it runs for a few hours, the trigger output for camera 1 stops working. If they power cycle the system, it will run fine, then stop again after the same time period. This is actually the same issue they were having in the first place, but they failed to tell me about the 'after a few hours' problem, so I thought my typos were the only problem. I will have to stop in again and see what's happening, but in the meantime, I thought maybe some of our resident Siemens gurus might have a look at my program.

The system consists of a conveyor mounted encoder, a product sensor, 2 cameras, and a reject cylinder. The encoder is a measuring wheel style that measures the distance the belt travels (1000 pulses per inch), connected to the high-speed counter in the PLC. The cameras are mounted on either side of the conveyor, looking at the front and back labels on a bottle. Due to the limited space, the product sensor is mounted slightly upstream of the cameras. The reject cylinder is located downstream of the cameras, and simply knocks off any bottle that fails inspection. Here's a short video I took of the system the other day. It is working properly in the video.

http://www.youtube.com/watch?v=9KkjUG8Z7B0

This was my first (and hopefully last) experience with the S7-1200 and the TIA Portal software. My explanations are often confusing (even to me), but here's an attempt at explaining how it functions...

Each time a bottle is detected by the product sensor, the current encoder position is loaded into multiple queues, and those queue pointers are incremented. I can have up to 2 bottles in the queue (there will never be more than this) between the sensor and the cameras, and up to 6 between the sensor and reject station. There are never that many in the reject queue, but I left room in case the reject station gets moved father downstream.

The camera queues track the bottle(s) between the sensor and cameras. When each bottle reaches the camera location, it turns on an output to trigger the camera. The cameras aren't directly opposite each other, so I have separate queues for each camera.

The reject queues track the bottle(s) between the sensor and reject station. If the camera gives a "PASS" result, this latches a bit associated with the current reject queue position for that bottle. When each bottle reaches the reject location, I query the "PASS" bits for that bottle. If either is OFF, I fire the reject cylinder.

When I wrote the original program, I started with just one camera subroutine. When I had it all working properly, I just copied this logic into a new subroutine for the second camera. I then went though that subroutine and changed the registers from 'camera 1' to 'camera 2'. This is why I find it really strange that the trigger stops working for camera ONE! If I had a typo or something, it should be in the camera 2 subroutine...

Since this takes hours to fail, I suspect it might be something like exceeding the maximum value in a register? The processor is not faulting though. It continues to run, just without the camera 1 trigger output. Camera 2 is triggering just fine. I am not looking forward to troubleshooting this system. I don't know enough about the S7-1200, and struggle with the software as well.

I'm hoping that a fresh set of eyes might notice something I've overlooked. I know there are probably better ways to write this program, but at this point, I'd just like to figure out why this one doesn't work for more than a few hours.

A bit too big as an attachment, so here's a link to a zipped version of the program...

http://www.dericn.com/files/DualCamera.zip

And a PDF printout of the ladder if you don't feel like firing up TIA Portal...

http://www.dericn.com/files/DualCamera.pdf

Any ideas?...



-Eric

P.S. I found a thread I started back when I first programmed this system. Might help in understanding how the system works.

http://www.plctalk.net/qanda/showthread.php?t=59595

This is why I find it really strange that the trigger stops working for camera ONE! If I had a typo or something, it should be in the camera 2 subroutine...

Click to expand...

What if, after several hours, the belt stretches a little, or the Camera 1 mounting bracket expands a little, so that the encoder loaction for Camera 1 Trigger is now 899, instead of 900 as set by %MD2?

Are there any heat sources (high-wattage lamps, heaters) near the Camera 1 mounting bracket?

Thanks Lancie, but I don't see how the physical locations of the cameras could have any effect on the program. The trigger locations only determine when (or in this case, where) to fire an output. If the location moved, it would just trigger the camera at a different location. The worst that could happen is that the image the camera takes would be wrong, and it wouldn't give a "PASS" output. The only feedback from the cameras is this "PASS" signal. If it turns on, it simply inhibits the reject pusher for that bottle. If it stays off, the reject pusher fires for that bottle. In fact, if I removed the cameras entirely, it would still work (although it would reject everything!).

Also, since I'm not checking for the bottles anywhere but at the product sensor, there shouldn't be any issue with the FIFOs failing to unload. They will always empty out automatically, whether or not bottles are added/removed after the product sensor. The (single) product sensor loads the FIFOs, and the encoder movement unloads them. If the encoder slips or stops, it would (err, SHOULD) affect BOTH camera FIFOs.

I'm hoping it's just a typo, or something stupid I overlooked. It might have to do with the scan order. If I had the PLC in front of me, I would try swapping the subroutine calls around (put camera 2 before camera 1) and see if the problem moves from camera 1 to camera 2. Perhaps it has something to do with scan order?



-Eric

FB3 network 1 looks suspect:

Bravo L D[AR2,P#0.0]!...

That's why a fresh set of eye was needed! I have been going over this program again and again, but failed to notice that. Apparently I 'corrected' it when I first duplicated the FB for camera 2, which is why camera 2 works properly...

I also found (yet another) typo in FB2, Network 6. The first contact should be the one-shot, not the one-shot 'memory'. This probably doesn't affect operation, but needs to be fixed anyway.

Slightly off the topic: Does anyone know why some PLCs require us to define the 'storage bit' for a one-shot. It's not like you would ever care about the status of that bit. You only care about the one-shot's output. Why not make it transparent to the programmer? It would help prevent mistakes like the one I just found.

Thanks so much!... :site:

I'll post an update when I make the change (probably next week).



-Eric

Eric Nelson said:

Bravo L D[AR2,P#0.0]
Slightly off the topic: Does anyone know why some PLCs require us to define the 'storage bit' for a one-shot. It's not like you would ever care about the status of that bit. You only care about the one-shot's output. Why not make it transparent to the programmer? It would help prevent mistakes like the one I just found.

Click to expand...

Well, the processor cares about it. And they all gotta be unique and be stored somewhere. I guess the software could make it transparent and just reserve unique internal places for them but then it would have to explain to you where all those missing bits in your free memory total went...

It would be handy for the software to automatically verify that you did indeed only use those bits once and give a warning if it found overlap or duplication.

I know it's late in the day for this, but had you used the stat area for variables and passed in/out the actual i/o for each camera then copying the FB would not have required the (error prone) manual edit.

L D[AR2 said:

I know it's late in the day for this, but had you used the stat area for variables and passed in/out the actual i/o for each camera then copying the FB would not have required the (error prone) manual edit.

Click to expand...

That would definitely be a better approach. When I wrote the program, I couldn't wrap my head around how that worked, so I just did it the only way I knew how...



-Eric

OkiePC said:

I guess the software could make it transparent and just reserve unique internal places for them but then it would have to explain to you where all those missing bits in your free memory total went...

Click to expand...

The majority of my programs are not very big, so I don't think I've ever bothered to look at how much free memory I have left, but I get your point...



-Eric

Thanks Lancie, but I don't see how the physical locations of the cameras could have any effect on the program.

Click to expand...

I do not understand the relationship between the camera trigger point and the encoder. If it doesn't matter where it is triggered, why use the encoder input as the trigger point? Oh well, I don't focus too well these days.

Still, I am glad LD found the problem!

Lancie1 said:

I do not understand the relationship between the camera trigger point and the encoder. If it doesn't matter where it is triggered, why use the encoder input as the trigger point?

Click to expand...

The product sensor is upstream of the cameras (see my ORIGINAL THREAD for a 'picture'). When a bottle is detected, I have to wait until it has reached the camera before triggering an inspection. In my case, camera #1 is 9" (900 encoder pulses) from the product sensor. A second bottle can arrive at the product sensor while the first bottle still hasn't reached the camera. This is why I needed a FIFO.

To complicate matters, camera #2 is 1/2" father down the conveyor, so it needs its own FIFO. If they were both at the same location, I could have gotten away with a single FIFO (and avoided these typos!).



-Eric

The trigger for the camera doesn't need to be 'exact', because the camera software will automatically center the image (within reason, of course).

Click to expand...

I did not remember that part - should have went back to the old thread first.