Tripper Programming Help

[richleva]

Hello,


I'm involved in the programming of a conveyor tripper.
For those who are not sure what this is.

See this video:
https://www.youtube.com/watch?v=LI_Kgbr5kc4


This tripper will have 4 different locations to dump material.
We plan to use a 4 way selector switch for the operator to decide witch location the moving cart needs to dump


We're are using proximity sensors to detect the 4 different location, "we are not using encoders". These proximity sensors are installed on the moving cart and not at the different locations.


Example:

If the cart is at location 1 and the operator selects location 4. The cart must not stop at location 2 or 3. it must continue moving to location 4. I'm assuming we need to use combination of counters and math instructions? If it need to go back to location 1 how will it know to go into "reverse"



Can anyone assume or foresee any problems with this setup?
Or should we make the recommendation to have the sensors installed at the locations? would it facilitate the programming?




Can someone provide ideas or examples for the programming on this?


*We're using Micrologix 1400 and RSlogix
*And we are not using a VFD for the motor just a size 0 motor starter with a contactor.

 

[OkiePC]

With only four locations, I would think that you could positively identify the correct location with 3 proximity switches and by placing flags to trigger them in such a way as to encode them:

px1: ON in every valid position
px2: ON only in positions 2 and 4
px3: ON only in positions 3 and 4

So if px1 is made, stop and have a short delay (max of a couple seconds)

Then if no other switches are on, you are in position 1.
If px2 is on and px3 is off, you are in position 2.
If px2 is off and px3 is on, you are in position 3.
if px2 and px3 are both on, you are in position 4.

If when moving between positions you can't afford to stop at all locations you could bypass stopping once you know where you've been, but I would program it to require that a known position has been established before allowing the system to skip that step and unlatch that condition on first scan. Skipping past positions would be based on time of travel between known points or counting triggers from px1 or some combination of both.

I would also want some sort of extra hard wired over-travel limits.

Those are my first thoughts.

 

[drbitboy]

I would expect the bulk of the code will be handling the edge cases.

• over-travel limits, as mentioned by OkeyPC
• operator overrides
  • manual stop, forward, backward
  • home to either over-travel limit
• this looks like a solids handling application, so is it likely that prox sensors will be affected by stray material?
  • this is actually not too complex to model, but keeping the PLC model in sync with the physical process will be a problem if the sensing fails
  • parity bit to detect a false positive?
    • does it stop and wait for operator intervention?
  • three sets of voting prox sensors at each location?
  • physical brushes to keep sensing locations clean?
  • failed sensor detection
• alarms, and HMI in general (if any)
• how do you resolve which direction is toward the target station?
  • OkiePC's encoding has a straightforward conversion into integers, so if the cart is at position N, it goes forward for targetN > N and backward for targetN < N
  • but what about if it just left N for N+delta1, and the operator switches the target to be N-delta2, or N?
• does a change in the switch position start the transition right away, or is there a momentary "accept switch value as next target" button?
• How accurate does each station's position need to be?
  • does it need to be the same from either approach direction?

 

[drbitboy]

Can anyone assume or foresee any problems with this setup?

I would be very paranoid about getting loose material on the sensed locations - they would be offset as much as possible from whereever the Y diverter is at each station. I would even consider switching to a distance sensor from the end that never sees material to get position: then this becomes a "simple" position application (if such a thing as simple exists).


Some sort of debounce and/or pulse extender around the station detection logic makes sense as well.

 

[drbitboy]

Can someone provide ideas or examples for the programming on this?

Look up some of [parky]'s posts about sequencing and steps.



There are only a limited number of states: (moving forward OR stopped OR moving backward); (at station 1 OR 2 OR 3 OR 4 OR in between 1&2 OR 2&3 OR 3&4 OR at over travel 1- OR 4+); (manual OR automatic).


3 x 9 x 2 = 54max. And the number of transitions is likewise limited.

 

[drbitboy]

...by placing flags to trigger them in such a way as to encode them: ...

Just make sure to never use the word encode or encoder to describe this; otherwise whoever said "we are not using encoders" will torpedo this approach.




also see some of the papers that show up here: https://www.google.com/search?q="belt"+"tripper"++"positioning" - apparently the positioning can automated and optimized.

 

[kamenges]

Dude's got parallel threads going. I posted in the wrong one. RATS!!

Keith

 

[GaryS]

There are several ways to do this
4 Prox switches 1 for each position
bring all 4 inputs in a single input word 0,1,2,3
masked move the input into a tag
compare the tag to select tag if they equal then you are in position
don't forget to include travel limits at both ends to prevent a crash

 

[Geoff White]

I would still do some position feedback to make the positioning more responsive Even if it were just a counter on a sprocket or motor shaft.

As everyone has said you need definite limits (fail safe) to prevent it crashing.

Keep track of position like this:
Position
0 -ve limit
1 between 0 and 2
2 First station
3 between 2 and 4
4 Second Station
5 between 4 and 6
6 Third Station
7 between 6 and 8
8 Fourth Station
10 +ve limit

Assign positions 0,2,4,6,8 based on PX feedback
Transition to odd numbers when driving off the sensors (depending on direction)
That way it is easy to determine direction required to move.
If the feedback changes by more than one then a px has failed.

 

[drbitboy]

Here is a straw-man, first-cut approach to tracking the cart state:

https://github.com/drbitboy/PLC_tripper


This implements a form of the ideas* mentioned by OkiePC and others, and from discussions with my brother who programmed an AGV once: four prox discrete inputs at each station (two bits of position, a parity bit, an at-station bit), plus a couple of in-motion discrete inputs (forward and reverse).


This does not implement the operator selector input or moving the cart; this addresses very few gotchas: over-travel; schmutz on sensors; etc. This has none of its tags assigned to actual files, so it's all conceptual.


Disclaimer: this is only intended as a straw-man to demonstrate a possible approach; it is in no way intended to be used without extensive review and revision.


* Good coders borrow; great coders steal

 

[parky]

When you say sensors on the cart are you referring to 4 sensors (so that each location uses a separate sensor i.e. arranged at different levels so a "FLAG" at each different station is also at the required height ). or 1 sensor.
We need more information for example is the operator going to select a station then the cart will go to that location and stay there until a new location is selected.
Simple logic i.e. it is currently at station 1 operator selects station 3
and 1, selection 3, set go forward
At station 3 and selected reset go forward
Operator selects 2
And at 3, selector at 2 set go reverse
at 2 reset go reverse.
I suppose you could use combination i.e. fwd/rev. latch with the combinations ORED to set the latches.
If you do this on one shots to avoid operator selecting while moving in other words if moving then ignore new switch position. It depends on what is needed create a spec. For example:

If at a station and new station selected, go to that station.
If new selection while moving keep original move and wait until in position or change immediately to new location. These require different types of programming so being a little more specific could help.

 

[parky]

Here is some code, note: This does not allow for starting in a non location so if in between sensors you need to add some home logic to take it to a sensor.
The arrow in some of the contacts is the equivalent to a oneshot rising (OSR).
The one block is doing it in ladder, the other block is doing it using a sequence word.
The sim block is just something I used to simulate it by turning on the sensors every 10 seconds using an up/down counter
There is no error checking and assumes once a selection is made it goes to that location before another selection can be made, there is no time delays to prevent sudden reverse of motor should another selection made a the same time as it reaches it's intended location.

 

[GaryS]

Wow all that code to do one simple task
Masked move the inputs compare the input word
move the tipper
Pos 1 input 0 value 1
Pos 2 input 1 value 2
Pos 3 input 2 value 4
Pos 4 input 3 value 8
this checks for correct position and gives you travel direction at the same time
any missing switch or duplicate input is an invalid value and control will not find the position

 

[drbitboy]

Masked move the inputs compare the input word

Had trouble with the syntax; I could have sworn [MVM I:0.0 000FH N7:0] would not verify the first time I tried it.


Ah, must have tried I:0/0 instead of I:0.0.


So much to learn, so little time.



Thanks!

 

[GaryS]

I would set the mask as DEC 15
but it should work I have used the MMV many times it saves a lot of code