Better design or coding?

Davek0974 · Nov 25, 2014

I am making massive headway into the PLC replacement i have mentioned in various threads, its all running and even the AB stepper drive was easy in the end.

The troubles appeared when it came to stopping and restarting or just starting simetimes

It will occasionally start in a zombie state where the cutter will cut out of step or other odd things happen.

The machine is a printing process consisting of PRINT - ADVANCE MATERIAL - CUT steps, when the cut instruction is made, the next PRINT cycle starts.

I'm just a bit baffled as to how to de-bug the process or to simplify it. Its all written in 48 rungs of code but is pretty complicated in places which makes me think I wandered off in the wrong direction possibly??

Any ideas for easy to understand design or how compartmentalise a series of steps??

Davek0974 · Nov 25, 2014

Is there a possibility here to use a seperate file for each stage and use an input trigger bit then wait for an output reply bit?

The main SYS ladder would then contain the stop, start and sequence control only

Just thinking....

James Mcquade · Nov 25, 2014

Davek0974,

it sounds like you have a timing issue in which the print cycle is started when the cut cycle is started.

several suggestions for you.
#1 if this is a dual cutter, look at each cut command. maybe something is different on one cycle.

#2 can you install sensors at the end of the cut stroke and use that signal to start the print cycle?

#3 insert a time delay before the print command. i don't recommenmd this step since there are air flow and cylinder variables that come into play when someone adjusts the air flow or replaces the cylinder.

regards,
james

Davek0974 · Nov 25, 2014

James Mcquade said:
Davek0974,

it sounds like you have a timing issue in which the print cycle is started when the cut cycle is started.

several suggestions for you.
#1 if this is a dual cutter, look at each cut command. maybe something is different on one cycle.

#2 can you install sensors at the end of the cut stroke and use that signal to start the print cycle?

#3 insert a time delay before the print command. i don't recommenmd this step since there are air flow and cylinder variables that come into play when someone adjusts the air flow or replaces the cylinder.

regards,
james

Hi, yes it is a bidirectional cutter, it parks at either end but the anomaly appears regardless of which end the cutter starts from. It does have sensors at each end, these are used to tel the process that the cutter has parked after a move.

It does seem to be timing related, something is not rock solid in the logic maybe and it lets the sequence start wrong?

I might try a re-write using more compartmentalised structure, focus on each section then join them together?

James Mcquade · Nov 25, 2014

which plc are you using?

if this is an older slc500 series, then I would look at the following rules I have gone by.

1. no more than 20 in series commands. the initial program manuals said 14.
2. no more than 10 parallel branches.
3. no more than 8 nested branches in the logic.

I had a 5/03 that worked perfect until I went from 10 to 12 parallel branches. I then got erratic results as you are describing.

if the code looks ok, I would insert a time delay on each cut cycle. say .01 or .02 sec. just enough time to let the processor scan a cycle or 2.

regards,
james

ASF · Nov 25, 2014

James Mcquade said:
which plc are you using?

if this is an older slc500 series, then I would look at the following rules I have gone by.

1. no more than 20 in series commands. the initial program manuals said 14.
2. no more than 10 parallel branches.
3. no more than 8 nested branches in the logic.

I had a 5/03 that worked perfect until I went from 10 to 12 parallel branches. I then got erratic results as you are describing.

if the code looks ok, I would insert a time delay on each cut cycle. say .01 or .02 sec. just enough time to let the processor scan a cycle or 2.

regards,
james

I think we might be putting the cart before the horse here. Before you get too far into changing your code, you should debug it. If you just keep changing it until something works, (a) that will take a long time and possibly not work at all, and (b) you will learn nothing about why it wasn't working, or how to debug it next time it stops working.

You may even find that there's a physical level problem, in which case no amount of rewriting code will help you. The "change things until something works approach" is useless for effective troubleshooting. It's like using a shotgun where you should be using a scalpel.

Davek0974 · Nov 25, 2014

That is, it's on a 12 year old SLC5/03 unit.

I have been doing some armchair coding and looking at using subroutines for each critical process step, the subroutines would be called by a set of checks -
print one image,
is image printed?
If Yes then advance the web,
Has the web finished moving?
If yes then make the cut,
Has the cut finished?
If yes then back to 1st step.

Maybe that will work easier?
Can't hurt to do some practice I guess

James Mcquade · Nov 25, 2014

ASF,

you are correct.
I was wanting to point out a possible problem that I had
with a 5/03 in the mid 90's.
he might have a similar situation.

thanks for pointing that out.

james

Lancie1 · Nov 25, 2014

I am making massive headway into the PLC replacement i have mentioned in various threads,

It could be that someone would have solved your programming problems by now, if you had:
1. Put all your posts about this program in the same thread;
2. Posted a print-out of your program.

Trying to tie it all together:
http://www.plctalk.net/qanda/showthread.php?t=91418
http://www.plctalk.net/qanda/showthread.php?t=91466
http://www.plctalk.net/qanda/showthread.php?t=91499
http://www.plctalk.net/qanda/showthread.php?t=91525
http://www.plctalk.net/qanda/showthread.php?t=91535
http://www.plctalk.net/qanda/showthread.php?t=91574

Maybe it was best to separate it out into chunks...

Davek0974 · Nov 26, 2014

Lancie1 said:
It could be that someone would have solved your programming problems by now, if you had:
1. Put all your posts about this program in the same thread;
2. Posted a print-out of your program.

Trying to tie it all together:
http://www.plctalk.net/qanda/showthread.php?t=91418
http://www.plctalk.net/qanda/showthread.php?t=91466
http://www.plctalk.net/qanda/showthread.php?t=91499
http://www.plctalk.net/qanda/showthread.php?t=91525
http://www.plctalk.net/qanda/showthread.php?t=91535
http://www.plctalk.net/qanda/showthread.php?t=91574

Maybe it was best to separate it out into chunks...

Thanks for that and apologies for not doing so, the issue i have seen in the past with mega-threads is that they tend to die rapidly as it rambles on, response drops off. I was hoping that by keeping each issue alone would give me concise answers and it has until now, this forum is excellent.

But yes, as this is more a general issue, I really should have linked, thanks for doing so.

Davek0974 · Nov 26, 2014

Step too far?

Could someone please explain why this rung would not function inside a subroutine??

BST XIC B3:0/11 XIC B3:3/6 NXB XIC B3:2/12 BND BST OTE O:4.0/12 NXB OSR B3:3/2 OTE B3:3/1 BND

If i trigger B3:2/12 nothing happens, if i trigger O4:12 it moves the ram as expected.

The subroutine is unconditionally called in the main ladder.

Thanks

PeterCs · Nov 26, 2014

Davek0974 said:
Step too far?

Could someone please explain why this rung would not function inside a subroutine??

BST XIC B3:0/11 XIC B3:3/6 NXB XIC B3:2/12 BND BST OTE O:4.0/12 NXB OSR B3:3/2 OTE B3:3/1 BND

If i trigger B3:2/12 nothing happens, if i trigger O4:12 it moves the ram as expected.

The subroutine is unconditionally called in the main ladder.

Thanks

maybe you overwritng b3:2/12 in some other rung?

Davek0974 · Nov 26, 2014

PeterCs said:
maybe you overwritng b3:2/12 in some other rung?

No it was far more stupid than that

I had mistyped the subroutine number so the one i was calling was not running, D'oh!

HarleyHetz · Nov 26, 2014

Haha, I HATE when I do stoopid S*%@ like that, but it sure is rewarding when I find it!!

Davek0974 · Nov 26, 2014

Yep, as they say, **** happens

I'm chewing on the next issue now, one setup option needs the machine to make one impression but three feed-cut cycles. For some as yet unknown reason, the first fed-cut sequence is 15mm shorter than the next two

This is odd as the feed length is set so is not changing, it can only be some sort of drive reset or setting that is different between the first full cycle and the subsequent repeat cuts.

On a good note though, my rewritten compartmented code seems easier and more logical, to me at least.

Better design or coding?

Davek0974

Member

Davek0974

Member

James Mcquade

Member

Davek0974

Member

James Mcquade

Member

ASF

Lifetime Supporting Member

Davek0974

Member

James Mcquade

Member

Lancie1

Lifetime Supporting Member

Davek0974

Member

Davek0974

Member

PeterCs

Member

Davek0974

Member

HarleyHetz

Member

Davek0974

Member

Similar Topics