Further educating myself...

[Davek0974]

Ok, thanks, good to know I'm on the right track, will add some more commentary.

I don't think I've been caught by scan specific logic yet, but good to be aware of it.

 

[Davek0974]

It appears that Rung 26 will cause a full Stop after 60 seconds, whether the machine is idle or not. It seems there should be a XIO bit on Rung 26 that inhibits T4:13 if the machine is not idle. (Maybe you are periodically resetting T4:13 at other places in the program. If so, disregard this post).

The Stop sequence will go like this:
Rung 17: At Auto-Start, Bit B3:0/7 Pre-Start goes ON in Rung 17.
Rung 26: Bit B3:0/7 runs 60-second Timer T4:13.
Rung 27: After 60 seconds, T4:13/DN triggers B3:0/10.
Rung 17: XIO B3:0/10 opens, dropping out B3:0/7 AND T4:3/DN.
Rung 18: T4:3/DN goes OFF, whcich drops out B3:0/11 BIT_MC-START, stopping the machine.

I've just checked and I have used a "RES" function on that timer each time the machine makes an impression i.e.running, this seemed the best way to me at the time, it works anyway

 

[Lancie1]

Great! Add a comment on rung 26:
"Each time the machine makes an impression, Timer T4:13 is reset on the following rungs: xxx, yyy, zzz, etc".

 

[cjd1965]

100% agree with lancie about comments. Even comment the obvious because next time you look it may not be obvious, and less so to a successor when u left for a better job etc

 

[kekrahulik]

The thing I have never liked about the EQU and MOV approach to state programing is the difficulty in remembering what the different values in the EQU statements mean. Adding rung comments can help, but I still find it difficult to read the logic quickly and easily.

Rather than MOV an integer into an INT or DINT, I prefer to make each bit of that INT a state. I can then thoroughly desribe each state with the bit description and use XIO and XIC instructions instead of the EQU instructions.

To accomplish this, each State rung has conditions for that particular state (same as the other appproach) which are followed by a CLR statement (sets the state integer to zero, which turns off all the bits in that INT) and then a latch to set a particular bit. That bit is the state. By doing it this way, only one bit of the INT can ever be true at one time, so the state concept is preserved. I now have clearly defined and easy to read XIC's and XIO's rather than the vague EQU statements.

My two cents

 

[Davek0974]

Interesting variations, thanks.

I managed to test my re-write today, Definately easier without the latching bits, and after a couple of hours debugging the new style it was all working and better than before.

I ran into the scan cycle issue for the first time, swapping a couple of rungs around fixed it but was very interesting to see what difference it made to the process, I guess it was hidden by the latching bits before.

A most rewarding exercise, thanks for the advice.

 

[Davek0974]

You're describing a simplified ladder-logic implementation of how Sequential Function Chart languages work.

Been doing some reading, a book called "PLC Programming for Industrial Automation". Most useful book, and it was a free download

I am slowly getting to see how SFC works and also how my method is pretty similar, my "start" register would be the SFC States and my "Done" register would be the SFC Transitions, I think

One main difference is the programming layout, SFC seems to be strictly-

Initial conditions
Transitions
States
Outputs
Timers
Counters

Whereas my version is all mixed and any function is used wherever I thought it best to put it, basically just stuffed in as I worked through the program mentally then shuffled around after testing.

Whether or not to try an SFC version I don't know yet, could be worth the exercise maybe?

 

[Davek0974]

Having watched my process run for some time with the operator, we can see there is cycle time to be saved and therefore a speed increase to be had for free by altering the cycle.

At present the cycle is sequential-
Stamp,
Feed,
Cut,
Stamp,
Feed,
Cut

But would be faster if we went
Stamp,
Feed,
Stamp+cut,
Feed,
Stamp+cut,

As you can see, by running two cycles together after the first impression is made, we can condense the process and increase speed, the cut cycle is always faster than the stamp cycle so it will finish in time.

This made me get the pen and paper out again but clearly this will not be possible with my current design which is purely sequential - there is no way two steps can run together, that was a previous design point.

What sort of control structure should I be looking at working around to enable this?

Using my current style, I would have to change from one register for start and one for finished to having one register pair for each cycle - getting messy again.

This is all feathers in the cap now, the machine is running and producing work all day so I have time to think.

 

[the_msp]

At present the cycle:
1 Stamp,
2 Feed,
3 Cut,
4 Stamp,
5 Feed,
6 Cut

Why don't you make it:
1 Stamp,
2 Feed,
3 Stamp+cut,
4 Feed,
5 Stamp+cut,

 

[kekrahulik]

My first thought mimmicks "the_msp" response to add another step "stamp and cut". In anticipating your response, I'm guessing that you might say that stamping and cutting happen at different speeds/durations/timings.

You may need to write several sequencers(I think in terms of states rather than sequence, but it really is the same concept):
- Stamp sequence/states
- Feed sequence/states
- Cut sequence/states
- System sequence/states

The system sequence now would be:
State 0 - Off
State 1 - Stamp
State 2 - Feed
State 3 - Stamp+cut

Depending on your conditions, the sequence could repeat 1,2,3 or just 2,3,2,3....

Now for example, if the system is in state 3, it triggers the stamp sequence and the cut sequence and does not proceed until each sequence is complete. The stamp and cut sequece may also be inter-related (maybe the cut waits until the stamp has begun).

Anyway, you can optimize a lot of wasted time out by defining different sequencers that get coordinated together. It doesn't have to be one long step by step sequence.

 

[Davek0974]

My biggest stumble seems to be visualising how the system is sequenced or controlled and then getting that down on paper.

It also needs to have the ability to make a single manually triggered stamp and likewise a manually triggered feed/cut, these are used when setting up.

Your state 1 and 3, would they completely separate sections of code or the same section multi tasked? If it's separate sections that are tailored to one job ie stamp or stamp/cut, what's the best way of controlling the single output function with the multiple source codes?

I think I need some more reading, it's this first step that I find the hardest - visualising the code and how it interacts, I also need to improve my state control method.

Maybe my idea of a state is too broad? In this instance would each state here...

State 0 - Off
State 1 - Stamp
State 2 - Feed
State 3 - Stamp+cut
State 4 - Feed + cut

be an isolated part of code? If not then transitioning would be difficult?

I am slowly (very) seeing how the transition logic decides which state comes next, based upon the machine being in auto run or manual set up etc.

Settling on a state control needs to be done, my current method has pitfalls that will stop it working properly unless each state is isolated because I use EQU and NEQ in some parts to make decisions, clearly if I'm using the same code for two different states, this will fail badly. That points to me that each state needs an individual block of code, all of which are tied to the same outputs at the output section - parallel bits seem the way there?

This simple little machine is proving most fascinating when pulled apart

 

[kekrahulik]

So I would have something like:

The system sequence now would be:
State 0 - Off
State 1 - Manual
State 2 - Stamp
State 3 - Feed
State 4 - Stamp + Cut
State 5 - Feed + Cut
State 6 - Alarm

Stamp Sequence:
State 0 - Stamp is Up
State 1 - Stamp Moving Down
State 2 - Stamp is Down
State 3 - Stamp Press Time
State 4 - Stamp Moving Up

So if the system is in manual, pressing the Stamp PB would trigger the stamp sequence to occur. I would not let the system sequence change from Manual while the stamp is sequencing.

The challenge of doing this well begins with defining all of your states well. This is done on paper (or whiteboard) - and I spend a lot of time thinking through it. I write all of the states on the board and then draw arrows showing which states can transfer to other states. For instance, if the system is in manual, maybe I don't want the Stamp sequence to have any press time - just go down and right back up - I would have an arrow that goes from state 2 to state 4 under those conditions.

I generally make a program file for each state sequence and then a program file for outputs. If you setup your states properly, each output is simply driven by an OR statement for the various states that would require that output to be on.

I don't know your details, but that's the general gist of state programming.

 

[Davek0974]

Thanks for that,

It seems I am not analysing my states deep enough, I was looking at the whole sequence only, I did not look at each state process alone in depth.

I still have a lot to learn here, how to apply each sequence in code for instance, and also how to trigger each state etc but that post was big help.

 

[Davek0974]

Kekrahulik, or some other kind soul , is there any chance you could show me a snippet of ladder code that would illustrate your methods?

I understand the way you have broken down the stamp process and that is almost exactly what happens so we are on similar track

I am struggling to grasp how the overall sequence/states is controlled etc and the general design of the program. Having the working model here is a great help but it's not written in any specific style so easy conversion is not on.

Once I get going I should be ok I hope.

Many thanks

 

[duckman]

"even more so as it works better now than it did when running on the original plc/program"
How have you evaluated that your new program is more "betterah"