Tripper Programming Help

[drbitboy]

I can't do all your thinking for you I would expect it would be obvious

What is obvious in the code as you presented it in post #19 (see update below) is that


1) if there is continuous coverage for the tripper sensor so N7:0 will always be 1 or 2 or 4 or 8, then the positioning provided by the code will be so broad as to be useless.


2) if there is discontinuous coverage for the tripper sensor so N7:0 will be 0 between stations, then eventually the code will go into an infinite loop.


3) If there is continuous coverage, with 1/2/4/8 at stations 1/2/3/4, respectively, but the N7:0 value is summed between each station e.g. N7:0 = 12 = 4+8 between stations 3 and 4, then again it will go into a loop.



Any of those ways will not work.



[update:


That is all correct, but irrelevant, because there is a typo in your example.


you meant to use N7:2 for [Source B] in the GRT on rung 0002 and in the LES on rung 0003.



Heh, I like what you wanted the PLC to do; what you actually told it to do, not so much.

].

 

[GaryS]

As I stated, I did not write all the code necessary but then the other code is not all there either. I just wanted to give you the general idea of the concept
question is 0 less then 1 ?
N7:0 is updated continuously on every scan so as the tripper moves off the switch N7:0 will value will be 0
yes going the other way you will need to latch the output on until the ii position bit is set
if you want me to detail and finish the project for you then let me know.
I assumed once I got you started you could finish it out. Think of it as school project
Like I said I have been using the value compare since the early 90's with the PLC2's or maybe even the SLC100, it sure beats all the lines of code that would be necessary otherwise.
if for example you if had a 25 position turn head on a grain handling system 25 position limits coming back to the PLC. You would have to verify each input to be sure of the position and then you still have to handle the motor controls with out the compare you would easily have over 100 rungs of code to do what can be done with just about 10 rungs.

 

[drbitboy]

question is 0 less then 1 ?

Better question: what integer is between 1 and 2; because without that integer the code as written (i.e. with the typo I found) will not work.

 

[GaryS]

Actually 0 is a valid number in a computer it stores and compares 0

I don't know how to explain it any better
Read the full text of my post
PM me maybe I can explain one on one

 

[parky]

First of all you are assuming the inputs for the switch & the sensors are in the 1st nibble of the PLC Inputs this is highly unlikely so a shift will be needed after the MMV. Secondly You will have to latch the route in in case bubba decided he wanted to change the position while it was moving you could have the scenario where it was at station 4, he selects 2 so it moves, when it gets between station 3 & 2 he switches so you have no reference of where it was i.e. you are moving from 4 to 2 then you are moving to 3 but it is already past 3 & it is looking for 2, this will not find 3. so it ends up at the overtravel limit, not a big problem if this is also the travel limit but very good practice. thirdly (I forgot about this one). You need to put a slug delay to allow the operator time to switch from say 1 to 3 or 4 as it will pass through 2 first and assume that is the next move. this would have to be achieved along side a change in value of the variable (route).
I did use similar code as Gary at first, however, I did set the route so once it was set could not be changed. to avoid the situation above, I also on the earlier code with the equivalent of a masked move delayed the switch change to allow switching through from 1 -4 & vice versa. but forgot it in the rather lengthy versions.

 

[parky]

This is my first one I did, it was remarkedly like yours Gary, but then there is only a few ways to skin a cat, I have added a few refinements like manual control, Selector delay as discussed in previous post.

 

[richleva]

Thanks everyone for the input
It helped alot

 

[drbitboy]

Thanks everyone for the input
It helped alot

Under the arrogant assumption that I am one whose contribution helped: you're welcome.


If possible, please post the code when you are done; I made a lot of guesses about your process so it would be interesting to see what the real thing looked like.


Also a log of the process you worked through would be neat (e.g. "type X prox sensor was useless in dusty evironment; vendor Y never called back") and possibly helpful for future readers.


That's a lot to ask, so it's completely at your discretion, of course.

 

[parky]

That's not arrogant drbitboy, we are here to help & why not accept some of the glory. Like you say, we have to make assumptions, and often we don't know the level of knowledge of the OP.

 

[shawn_75]

Be sure the conveyor belt is either empty of material or you need to reverse the conveyor belt when the thing is traveling in the direction of the ramp or you'll end up with material all over the floor.

 

[drbitboy]

I added a simulator to the four-rung minimal_tripper.RSS here:

https://github.com/drbitboy/PLC_tripper
​

The simulator and tripper control code use bit patterns 1/2/4/8 (0001b/0010b/0100b/1000b)for stations 1/2/3/4, but they could be changed to a more robust scheme e.g. two bits for station ID, plus a bit for parity, plus a bit for [at a station].

It is also robust to some edge cases:
- over-travel at the ends
- where the selector switch sends a zero
- where the cart is in between stations and the selector switch is changed to any other station, including being set to the last known station.


Gary was right: KISS is better.


I also added some of those features to GaryS's implementation; see tripper_GaryS_fixed_plus.RSS at that same Github repo.

 

[parky]

Just one last point in the masked move, the code assumes the inputs are on the first nibble of the input 16 bit boundaries, this is probably unlikely so either a shift is required or use other integer values for example 2,4,8,16. not that it matters that much. I did not have that problem as Mitsubishi have a function to copy any bit location into a word.

 

[drbitboy]

Just one last point in the masked move, the code assumes the inputs are on the first nibble of the input 16 bit boundaries, this is probably unlikely so either a shift is required or use other integer values for example 2,4,8,16. not that it matters that much. I did not have that problem as Mitsubishi have a function to copy any bit location into a word.

Yeah, I have MicroLogix 1100 so I had only 10 inputs: four position; four selector; two over-travel. Shifting is trivial as you note; I had to shift the selector bits (DIV by 16).

Obviously the MVM is not the only way to get inputs into the INTeger, just the most fun.

 

[parky]

Yes I agree, I suppose you could just make the bits = the input, only 4 rungs but not so much fun. (not that you can do that in Mitsubishi as you cannot address at bit level directly on word registers).

 

[drbitboy]

OT: Brute force vs. coding

OT


I am looking for opinions and rationales on the following question: when designing a system that executes the same atomic operation over multiple values, at what size process would you choose to switch from a brute-force approach to an algorithmic approach? And the followup (or alternative) question is how and/or why and/or in what situations would you make that choice?

Thanks in advance for any response.



For example

If I was doing a one-off design then I might consider it straightforward to use brute force all the way up to 16 stations and beyond, and to make it easier for maintenance to debug down the line. But if I worked for a company that built, installed, and commissioned tripper conveyors, I might lean toward the algorithmic approach because I could then write the code with an integer containing number of stations stored in the program, and all I have to do for each installation is change that number to match the local process and voila the code works at every installation with minimal effort beyond the I/O check.


Specific case - the current tripper conveyor

The code below shows two ways to transfer the raw inputs for this thread's process, which are in bits 0 to 3 of N7:0, into integer buffers. The top case does it in rung 0002 and writes either a zero if multiple bits are set, or the single-set-bit N7:0 value, to integer N7:10; the bottom case in rungs 0003 and 004 uses a loop and writes the same result to integer N7:20. I chose the GaryS-style inputs* for simplicity, but this question could apply to any input scheme**. With only four inputs, I would think the top method is preferred: it is certainly cleaner***.


At how many stations, or in what situation(s), does it make sense to switch to the bottom method. Or is the bottom case just too ugly and/or such a maintenance headache that it is better to assign the coding of the brute force method to next summer's low-wage intern?




* N7:0 = 1/2/4/8 for stations 1/2/3/4, respectively, i.e. exactly 1 bit on, and the other three bits off, when the cart is at each station; all bits off when the cart is between (or beyond) stations.


** E.g. if the environment was so dusty or noisy that single-bit errors were not rare in between stations, then a system where two bits give the position, plus a parity bit, plus an at-station bit, could be implemented to make a more


*** not that I think I wrote the cleanest looping construct, but for the sake of argument assume I had.