Further educating myself...

[Davek0974]

That's making sense, I'm liking the idea of controlling the cutter via the clamp, I was working the other way round.

However, I can see no way that code will hold the cutter in the out position between feeds?

The action should be feed-clamp-cut(cutter moves out)-feed-clamp-cut(cutter moves home)

It's tricky, sort of had it working with a flip-flop but I dropped that when I tried to move to state-sequential control.

 

[Davek0974]

Ive just had a light-bulb moment

I think this one of the rare cases when making the cutter valve a latching bit is called for, this should then fit in with my state control, each time it asks for a cut and the cutter is home it would latch the output, this would then hold the cutter out until the next cut call when it would notice the cutter is out and then release it and so on.

It looks good on paper, reads like it will work, hopefully try it tomorrow if I get time on the machine.

Easy to unlatch the bit if we go into a stop when the cutter is out, should never be out when stopped as it's dangerous due to the way it will jump back home when the light guard is broken.

 

[dginbuffalo]

That's making sense, I'm liking the idea of controlling the cutter via the clamp, I was working the other way round.

However, I can see no way that code will hold the cutter in the out position between feeds?

The action should be feed-clamp-cut(cutter moves out)-feed-clamp-cut(cutter moves home)

Confused a bit again (don't really know this type of machine). Do you mean hold the cutter valve or the whole assembly in the out position? Wouldn't the assembly stop at the "cutter out" sensor after the cut forward command and then wait for another cut trigger to enable the cut reverse command? I guess I'm assuming this is cutting while traveling in each direction?

I also thought about using some latches based on what I've picked up and even going back to some sequential logic. Just haven't been able to wrap my head around the exact sequence of events.

 

[dginbuffalo]

Thanks but not yet.

The cut valve is a single solenoid 5/2 so energise for out stroke, de-energise for home stroke.

To stay at out position, valve must be held on while clamp releases for next feed, then clamp needs to come on while valve is released.

As explained above- does the clamp need to come back on again even while waiting for the cut signal to return to home? Or can it come on as soon as it gets the reverse (home) signal?

 

[Davek0974]

The clamp must be on whenever the cutter is in motion. The cutter is a linear slide operated a single solenoid 5/2 valve so it's power on to move out and power off to come home, it must be kept energised to hold it in the out position.

I think the latch idea will solve it, added to the state-sequence design, it means that once latched it will hold the cutter out between all othe cycles without having to put multiple AND contacts on every state but one. It also nicely handles the fact that it will not move out at the early states on a fresh start cycle, having the multiple AND contacts would need more logic to skip the first cycle.

Seems a really good case for a latched bit.

Thanks for looking by the way

 

[Davek0974]

My light bulb moment was indeed true.

Managed to get a few minutes on the machine, uploaded my latest test and 99% success, cutter works, feed ok, clamp ok, stamping ok, sheet counters not????

The major change I made was to bring the whole auto process into one subroutine, before I was trying to share the cut / feed cycles with the manual code - bad idea, it's a sequential process and it seems happiest when run as a sequence.

The counters - there are two, one is a batch counter(C1) the other counts how many cuts per feed we need(C2), usually one but can be three. Neither counter is incrementing.

They are both triggered on the the final state (S9),when the cut cycle completes it jumps to S9, in S9 I test to see if C2/DN if yes then loop to start, if no then loop to feed start so we get a series of feed-cut until C2/DN is true.

Obviously without the counters incrementing, it loops endlessly.

The auto run sequences are in a subroutine and the states/outputs are in the main ladder, I did this because I need access to the various outputs from the manual sequences.

Possibly a scan cycle issue I am not seeing?
Its definitely hitting S9 but the counters are not moving.



Edit...

I have just re-read my code and the S9 rung has an OSR in it, would that upset the counters?
I am guessing it will, it's not needed any more as the states take care of the pulse so I'm pulling it out.

Will not be able to test until January now but I am very confident now, especially so as the rest of the sequence worked perfectly.

I can write the manual sequences at home over the break, at least I know what goes on now.

 

[dginbuffalo]

Glad it's coming together. OSR and counters are usually OK. Could be your losing your trigger to the OSR before it has a chance to fire.

 

[Davek0974]

Glad it's coming together. OSR and counters are usually OK. Could be your losing your trigger to the OSR before it has a chance to fire.

That was exactly my fault - the input to the rung was true for one scan, the OSR skipped a scan and by the time it came around again, the input was false, something like that anyway, probably similar to putting two osr's in series.

I've pulled it out and will continue to finish the manual sections, I'm off work now for the break so no rush

Confident it will work, I was most impressed when the rest of the auto run section worked exactly as I read it should work

 

[dginbuffalo]

Good to hear it's coming togehter! Enjoy your break.

 

[Davek0974]

Pulling the OSR out of the counter rung cured the problem, the counter being one state of the sequence controlled the pulse itself so no OSR needed.

The whole process is now far better due to the state control method, it has a sequence for each operation-
Manual feed and cut,
Manual stamp,
Manual cut,
Auto run with multiple cuts,
Auto run with single cuts.

The auto run with single cut is the most common sequence and this is the one that now cuts at the same time as printing, this saves a lot of otherwise wasted cycle time and therefore increases speed at no cost.

All the different sequences converge in the output control area of the main file where the various sequences combine on each physical output.

All inputs and outputs are mapped to internal bits so changing the machine will be easy just by altering the mapping.

I also picked up exactly what I was doing after a lengthy break so I'm fairly confident the code is pretty easy to understand, although I have now commented pretty much every line of code.


Thanks for the help