Tripper Programming Help

GaryS said:

Wow all that code to do one simple task

Click to expand...

Is this code golf now?

GaryS said:

I would set the mask as DEC 15

Click to expand...

Yeah it's a mask so FH makes more sense to me; potayto potahto.


And it doesn't matter: even when I enter 15 RSL changes the display to FH; so RA agrees with me, that probably means I am wrong (as usual).

Yeah I don't have A MASK MOVE so have to do a bin to int with an index of 4 so I thought this would confuse him. as probably the Mask move may.
I actually started to do that but junked it. I do not have RSL.
I must get my copy loaded & find the licence, I have it somewhere but can't find it. I do have it on an old XP machine but took the licence off onto usb it must be around somewhere.

Program

I just completed the program
5 rungs
I did not know what processor you have so used a 5/05 processor
2 16 point inputs and 1 16 point output

GaryS said:

I just completed the program
5 rungs
I did not know what processor you have so used a 5/05 processor
2 16 point inputs and 1 16 point output

Click to expand...

OP says ML1400.


Maybe I am not understanding how your inputs are triggered, but what happens when the target is station 1 (bit value 1), the cart is between stations 4 (bit value 8) and 3 (bit value 4), and the MVM puts a 0 in N7:0?


I am missing something in your code.



If it's code golf, I can name that tune in 10 instructions and 4 rungs:

I'd be less worried about making the program smaller, and more worried about making sure it is set up to cope with the ever-present real world things like inputs "bouncing" and drive train breakage. Where are the debounce timers? Where's the travel time limit?

if your ripper is drifting while in use then you have other problems as well
It should stay in position if not then you will need to address those
as simple move the in position value to the a storage word and compare that word
maybe stop the feed or correct the position
jus a few more lines of code would handle that
the ML1400 has a MMV function you just need to look for it

I did it both ways: assume inputs are reliable; assume they are not and have debounce, etc.




GaryS: does your program assume there is always exactly 1 bit being set in the MVM, no matter where the cart is? If yes, then how does it decide where to stop in each zone? If no, then your MVM will move a zero into N7:0 when the cart is between stations, which will cause the cart motors to go forward even when they should go backward. I am missing something, I am sure.

OkiePC said:

I'd be less worried about making the program smaller, and more worried about making sure it is set up to cope with the ever-present real world things like inputs "bouncing" and drive train breakage. Where are the debounce timers? Where's the travel time limit?

Click to expand...

Yes I did that, and then GaryS said "Wow all that code to do one simple task" so I went the other way as well. This minimal approach would involve making the hardware fail-safe so the code does not have to handle every anomaly.

drbitboy said:

Yes I did that, and then GaryS said "Wow all that code to do one simple task" so I went the other way as well. This minimal approach would involve making the hardware fail-safe so the code does not have to handle every anomaly.

Click to expand...

Sorry, I honestly didn't even look at yours...got busy for a bit, just jumped in with my opinion after seeing the thread turn to the goal of minimal code.

For a classroom exercise and for learning, the minimal code methods can teach good concepts. For real world applications, I probably would not even used a masked move.

I would try to make it easier to read for the end user who is trying to figure out what is going on when a slug of grease with metal shavings get stuck on one of those prox switches.


If this thing travels at a constant speed, coding to estimate the position using that rate of travel and then comparing that position (with a limit window to tolerate some variability) to what the switches tell you would be useful.

Think of it as a parallel model of the machinery so that the system can have two perspectives to work with to safely halt and present alerts etc. when there is a large mismatch between the two sets of info.

I had exactly the same problem many years ago.

Initially the tripper carriage had a 5V encoder and position control was based on encoder counting - total FAIL, the tripper would move about an inch due to noise induced into the 5V inputs from the motor wiring in the caterpillar cable tray.

The problem was solved by using a single proximity switch on the tripper carriage, with "targets" welded to the walkway.

Our tripper had about 15 "bays" it could be positioned over, so because of a lack of spare inputs, we used counting to deduce where we were located. A binary coding system with 4 inputs would have been preferable, but we had to go for counts.

The first rail unload was a total disaster, but only because the train drivers order of carriage contents did not match the inventory supplied by the quarry, so they got the wrong products into the wrong bays, but that was not a PLC program error, but SISO situation.

Anyway, once the tripper control system had finished the inventory, or recipe, it would return to "home" and all counts reset.

Now that was over 15 years ago, and never heard back from the client since, so assume it has been working fine ...

First I would use Pox switches one for each position
It should go without saying that there is only on Prox for each position
That way if one stays on then 2 inputs would be on and the value would not be correct
Remember the values are the bit values 1,2,4,8 each represents a valid position
If 2 switches wer on at the same time the value would be the sum of the 2 values
If inputs 0 and 1 were on at the same time the value would be 3 (1+2)
3 is not a valid position so the control would just keep going until it reaches the travel limit
At a travel limit you could program it to change directions and travel the opposite direction looking for the selected position.
No matter what way you chose you still need to handled a missing or stuck position switch
I would suggest that if the both travel limits are made without finding a valid position then fault it and shut it down.
As for debounce if you use a Prox they generally have enough debounce built in that you don’t generally need them just make sure your target is large enough to allow you to stop the tripper and remain on the switch
No matter what system you use unless you use a laser positioning system on power up you wll not know where it is so you will just have to run the tripper until you find a known position agan if it travels end to end without finding a valid position the it should fault anyway.
You should in any case have a Auto Run command, a Stop command a Manual For and Manual Rev
A good to have option would be to have a display showing the travel, and when it’s in position
The operator like to have visuals
No matter what you do you need to do the house keeping and safety checks

OkiePC said:

Think of it as a parallel model of the machinery

Click to expand...

You and I think about computers the same way. I often say that all computer programs are a model of some piece of the real world: the only real design choice is the desired level of fidelity; all subsequent design decisions flow from that.

GaryS said:

Remember the values are the bit values 1,2,4,8 each represents a valid position...

Click to expand...

yes, I understand how bits and integers relate, and bits and floats, and bits and anything; I am base-agnostic.

If you look at my tripper_drbitboy.* files here, you will see that I am comfortable moving between in bit- and integer-space



So I am looking at your code in post #19, and I am thinking about


1) the tripper cart at station 4, so N7:0 = N7:1 = 8.

2) Let's say the operator moves the selector switch to Station 3, so N7:1 changes to 4.

3) The next time rung 5 runs it unlatches IN_POSITION to 0, and after that next time rung 3 runs it sees N7:1 = 4 < 8 = N7:0, and set the MC_REV contact to 1, which starts the motor in reverse.

4) The cart starts moving from station 4 (where N7:0 is 8) toward station 3 (where N7:0 will be 4).

5) When the cart leaves the station 4 prox, N7:0 changes to 0, but it has still not reached station 3.

6) The next time rung 2 executes, it sees N7:1 = 4 > 0 = N7:0 and it starts the motor in forward, back toward station 4

6.1) Rung 3 is now irrelevant since its LES instruction evaluates to False.

7) The cart moves to station 4, N7:0 changes from 0 to 8, and we start looping from (3) above to here.

What am I missing? Does the code not expect N7:0 to be set to 0 between stations? Because, again, you stated this:

GaryS said:

Remember the values are the bit values 1,2,4,8 each represents a valid position...

Click to expand...

the only thin I did not include is the rollover / reverse at the travel limit
I can't do all your thinking for you I would expect it would be obvious
the tripper position motor will run until it finds a valid position or it faults out with both limits made without a valid position
as I said this is just one solution you can use or not it don't matter to me
there are may possible solutions, if it works then it's right
I have used this type of program many times gong back to the PLC2 when they first came out.
always works the key is planning