Programming Advice

[dwoodlock]

So I have been working on a project for the past couple months. we bought 2 machines, and basically I was to interface the two. One Is simply a feeder for the main machine. No issues here.

Later they decided that I was to add vision to the main wash machine. I am relatively new to programming, and actually still finishing my last few classes of tech school. The main machine has a slc-5/04 which is fine because nearly all tech schools teach based on AB.

So to the programming, I have 2 cameras inspecting for vision, and I am trying to keep track of the inspection results for 5 index cycles down the belt until it reaches my gripper assembly. Each Index moves 6 parts, at varying speed, and when it has moved 5 indexes I have mounted a 6 gripper assembly, and based on inspection results it can remove any number of parts between 0 and 6 during the length of time the belt dwells.

My issue at this point is inspection result tracking. I have used a BSL instruction, and I am triggering the instruction based off each camera having completed and evaluation, and the evaluation result is what im using for the bit address.

problem im encountering is, if the camera trigger is not activated because a part is not there, no evaluation is completed, so therefore there is no shift.

My first idea to get around this issue is, I branched around the evaluation completes that are primarily initiating the shift, and I added a sensor thats shooting a beam through the belt holes, and then put a timer in front of it that is enabled by the inverted trigger input, so that if the trigger is not pulsed for whatever the preset is, the /DN bit is set and it enables the shift to be initiated by the belt hole sensor since there is no part there to trigger a snapshot therefore leading to an evaluation.

Hopefully this is clear enough, if not I can post the program later.

Love to hear some input from some veters. As I said, This is my first project programming something of this style, so i'd love to hear some ideas, or alternate ways.

-Thanks in advance

 

[cwal61]

If you know index cycles then why can't you make your determination from that. Use the index cycle for your shift.

Not sure we have a clear enough picture of your process. It sounds like each index can move up to 6 parts by camera's for inspection? But if you have an input per index and each index constitutes an inspection. Then I would start there.
Every Index = how many good parts 0 to 6? And shift results.

 

[Jim Mo]

Depends on why there is an empty. If the feeder is sending an empty, than have the feeder send a signal and use that to trigger th BSL. If the part is being removed by prodution people, you might have to add a manual input for the main machine to use to trigger the BSL.

 

[dwoodlock]

If you know index cycles then why can't you make your determination from that. Use the index cycle for your shift.

Not sure we have a clear enough picture of your process. It sounds like each index can move up to 6 parts by camera's for inspection? But if you have an input per index and each index constitutes an inspection. Then I would start there.
Every Index = how many good parts 0 to 6? And shift results.

the two cameras are at 90 degrees from eachother, one is doing an ID shot, and one is doing a profile shot. When the belt indexes, assuming that you have all 6 parts in the belt, the cameras will each shoot 6 pictures. There is no guarantee that all 6 of those parts are good, the evaluations are finished typically between 100ms to 200ms because these cameras are cheap, but its fast enough for the time being.

so say, i only load the belt once, There are 6 parts in the belt, those 6 parts will trigger the shift by evaluation.
after those 6 have been evaluated, Im not sure the best way to do the shifting.

another consideration is that the feeder has been known to misfeed for whatever reason, so you may only feed 5 parts rather than the full load of 6. in this scenario, I still need to insure that the shifting is done accordingly even though one of our parts somewhere in the 6 part index may have been MIA.

 

[cwal61]

If your PE thru the holes in the belt and Timer give you 6 evaluations every time. Then I would do something like this to Shift Results. See Attached.

 

[OkiePC]

INstead of shifting a bunch of data, use a pointer that moves with the conveyor, track it to the conveyor with an ecoder if possible, or roll your own to account for actual speed include accel and decel for best reults.

Then you don't move data, just a pointer in an arry.

Example: The belt is at a position of 25.3 feet, my inspection results are 4 feet from the end, so I drop my results into a UDT array at element number INT(25.3-4).

When I need what is at the end of the belt, I simple look at the array in the area where the pointer is presently caulculated. Usually I end up with a range that needs ot be checked.

This approach takes more calculations of pointers and is an abstract concept so comment heavily if you use this style...on the up side, it is pretty bullet proof as long as you are precise in your math and measurements or have an encoder.

Once the heavy lifting is done and you wrap your brain around the concept, it is easy to move and add stuff...each new device gets a pair of range pointers and the units can be real world and easy to measure and adjust.

 

[dwoodlock]

Update:

One of our contract programmers what we use for our high end stuff was in house one day, and I asked him for advice seeing that his experience was far greater than my own.

His suggestion was that I trigger off the holes in the belt rather than the parts because that way I will get a consistent shift execution. He suggested for a 1 to represent a good part and a zero a bad. This made sense, and I had to rearrange some things in my program, but it ended up working good........ until

Now the issue became that this machine has a camco index drive, and various delrin guides throughout for the belt to run through. Guides wear over time changing belt tension. Also it seems the belt tension variations through its circumference can cause slight movements while it is in dwell because of the belt memory, and perhaps work hardening.

because of these slight movements, I was occasionally getting a false triggering. After being stuck at this point I decided to experiment with using a time based camera trigger. There is an index timer, and once I figured out the percentages of that time value that I needed to snap photos, I used a series of 6 branches with compare instructions to trigger my photos. This value can be updated every cycle, or at intervals, so it actually works out kind of nice, and you can adjust belt speed and after a index cycles, you are ready to load parts again.

Problem now is that if the scan cycle takes too long it can overextend the window that I have specified for any given output pulse to trigger a photo.

Basically At this point I am begginning to wonder if I should go to an encoder as OKIEpc suggested (which the machine was available with from the manufacturer, but someone{not myself} opted not to go with). I've never used a HSC/encoder with programming, so its foreign to me. Kinda at a point where im not so sure what to do. I'll be checking for peoples advice and I'll update with what I go with.

Thanks in advance.

 

[Lancie1]

...after those 6 have been evaluated, Im not sure the best way to do the shifting.

His suggestion was that I trigger off the holes in the belt rather than the parts.

If there are missing parts in some positions, then you cannot use parts to trigger your bit-shifting.

I think you have a great deal of confusion about WHAT the bit-shift REPRESENTS. You can try to make it mean a lot of things, and exactly WHAT depends on the situation.

The most successful method is to let a bit in PLC memory that moves from 1 place to another (a bit-shift register being triggered by external physical movement) = a real physical object moving from 1 position to another. The best systems mostly use an encoder on the converyor that sends a pulse to the PLC each time the belt moves XX inches. The movement in PLC memory from bit position 0 to bit position 1 should be scaled to represent some real physical movement in your system, either belt travel, part travel, or a group of parts traveling some X distance.

Once you decide what 1 bit-shift MEANS, then you must make all logic use that same definition. You should not try to use "belt travel distance per encoder pulse or per second" at one place, then use "holes" at another place, or "parts" somewhere else. Everhthing needs to be working on the same definitions of what a bit-shift IS.

If the holes on your belt are not always the same distance apart, then you might need a more accurate method. Probably you need a conveyor encoder and then use the encoder output as your bit-shift trigger.

 

[dwoodlock]

I do understand what the bit shift means and represents.

Problem is more tracking it on a machine not designed with part tracking in mind.

Seems that the consensus is generally add an encoder.

 

[Lancie1]

I do understand what the bit shift means and represents.

Why then make an effort to use missing parts to shift a bit? Seems futile.

 

[dwoodlock]

I guess im not sure how otherwise I would shift it down unless i shifted and 6 bit array every index. I am new to this so bare with my ignorance and lack of experience.

 

[Lancie1]

If you create a valid basic definition for your particular bit-shift (what each bit represents), then the trigger to use will be almost obvious and not much else would work (for that definition).

For example, if my parts are on a belt, lined up 3" center-to-center, then I might DEFINE my bit-shift trigger to be when one part position moves 3" on the belt. Then I could use an encoder output that pulses each time it sees the belt drive pulley move the equivalent of 3" of belt travel. Then anywhere that parts are added or subtracted, I insert a 1 into the shift register if a part is Present or gets Added to the belt, or a 0 if there is no part or one gets removed from the belt. It doesn't matter to the PLC if a part is there or not - it still tracks the empty-or-full position and knows where it is from start to finish.

If the parts move in a line one following the previous, then your bit-shift should be based on individual part movement, not on groups of 6. On the other hand, if movement is always in groups of 6 (maybe in a grid of 3 x 2 rows of parts or 2 x 3 rows), then each bit shift must represent the movement distance of the group-of-6. Use one or the other of these tracking methods, but not both, and not one at one point, and the other method at another point.

If you use the group-of-6 bit shift, then you will need some additional logic to determine how many parts are present/missing from each group-of-6 at places where parts are added or subtracted from the groups. With a group-of-6 bit shift, your PLC will know where each group is located, but it will not automatically know where each part is within each group. Perhaps you could use a second level of bit-shifts within each group, riding on top of the first group-of-6 bit shift?

 

[dwoodlock]

If the parts move in a line one following the previous, then your bit-shift should be based on individual part movement, not on groups of 6

This is my situation. I am using my cameras both saying they've evaluated something to shift the result(good or bad) with a timer actuated trigger to tell the cameras to take pictures at different intervals during the index.

 

[dwoodlock]

heres my vision rung, dont burn me down too hard lol

 

[Lancie1]

Dwoodlock,

I am pretty dumb, and have been trying to figure out your program. There are some things that I cannot figure out.

1. Okay, you are setting your Bit Address B3:10/0 in Rung 007 to 1 for a Good Part. That is what your shift registers represent, the physical locations of Good Parts (1's) and Bad Parts(0's) on a conveyor.

Bit Address is the location of the bit which will be added to the array. Rockwell Software

2. As the conveyor moves these Good and Bad Parts from Positon 0 to Position 1, your shift register should move Bit B3:10/0 to B99:0/0. In other words your Bit Shift Left input should be triggered by the conveyor moving one position. However best I can tell, it is triggered by B99:4/4, which is turned on when "ID Eval Completed" AND "Profile Eval Completed". I think these are inputs from your camera, not from movement of the actual Good and Bad Parts. Do you see the disconnect here? Your BSL is set up to track the movements of parts on a conveyor, but is instead tracking the actions of a camera. Your BSL is then conflicted - it is trying to use apples to produce oranges.

You might get it to sort of work, IF the Inputs I:2/13 and I:2/14 only happen when the conveyor has moved 1 part for 1 position. If not, then it is improbable that it will work very well. A good indicator of that is all the extra rungs you needed to insert to do various tasks. Normally if the BSL is defined and set up properly, you only need to use the bit at the appropriate position in the shift register (B99:0/0 to B99:1/15 in your case) to perform some action. For example, if Bad Parts need to be kicked off the conveyor at Conveyor Position B99:1/15- the last tracked position of your 32-length BSL, then I could merely do this:

|                   BAD PART     |

| DIVERTER          DIVERTER     |

| POSITON           SOLENOID     |

| B99:1/15           O:8/15      |

|---|/|--------------(OTE)-------|

|                                |

Then when a Bad Part arrives at the Diverter (Location B99:1/15), I simply look for a "0" there and if found, activate the diverter. Simple and easy, and the reason BSLs are widely used.

But I don't see address B:99/1/15 used in your program, or any other of the 32 bits between B99:0/0 and B99:1/15 being used ANYWHERE in your program. In other words, you have a BSL, but you are not using any of the bits that are being shifted by your BSL for ANY purpose. Instead you use a bunch of other external addresses such as counters and timers to control your cameras. It appears that the BSL, at first look, is not helping you at all and could be deleted.

I could be wrong, but my thinking right now is that unless at least one of the bits between B99:0/0 and B99:1/15 is used for SOMETHING, then the BSL is not doing anything useful.