Stand Alone Machine code examples

[timryder]

Hey would anyone be willing to share some of their programs they've created for stand alone machines? I have been doing my own structure of code for a very long time now and am just looking to see what anyone else does different from me so we can all learn.

I'm just looking for RSLogix 500 or RSLogix 5000 samples.

I've posted mine for the same purpose, I'd love to have some open discussion on technique.

Thanks.

 

[OkiePC]

See post #5 in this thread for a very simplified example:
http://www.plctalk.net/qanda/showthread.php?t=52654&highlight=state+engine

I cannot see the acd file you posted, if it is short enough a pdf report version might help those of us without access to software, thanks.

 

[bce123]

ver. 20.12

 

[Ron Beaufort]

I'm too swamped to look at it right now - but I had time in between calls to print it out ...

.

 

[OkiePC]

I'm too swamped

Good.?

I had time in between calls to print it out ...

Thanks!

 

[Ron Beaufort]

Good.?

yes, indeed ... I'm about to be blessed to death ... God is good ...

 

[OkiePC]

yes, indeed ... I'm about to be blessed to death ... God is good ...

Amen to that, glad to hear it, not the death part obviously, but you know what I mean!

 

[timryder]

Love seeing fellow brothers in Christ doing well in life

Any thoughts on technique that you see differ from yours?

Has anyone ever used Sequence bits to control a program?

 

[OkiePC]

Yours is concise and organized, what I call "straight logic" sequence control, 3 main retentive steps, right?

My example omits i/o mapping which I always use. In reality, there would be two more state engines, one for mode control, another for fault/recovery I like them separate, so I can resume the main process more easily where possible.

Your's is easier to follow, until many steps or branches are needed, after just a handful, my method is easier to follow and concise. This is my first scan opinion, I find your style very nice.

 

[timryder]

Thank you for the compliment I very much appreciate it.

Do you have any other sample programs that you would be willing to share? If you don't want to make it public to the forum, maybe by Email? My purposes are purely educational. I am intrigued by your explanation of the technique you program in and I'd love to have a look at it!

Thanks anyways

God Bless

 

[JordanCClark]

Here's part of a program for handling a bolt driving assembly station. (The rest if the program has to do with other assembly stations, so I didn't want to confuse the issue.

I use an integer to keep track of the sequence of operation. When each step is finished, I set the integer to perform the next step. Normally, I run in increments of 10 (a throwback to Old-School BASIC line numbering). That way, if steps need to be inserted, process faults handled, etc., then there is plenty of room with very little rewrite.

Another advantage (for me, anyway) is that I can use a multistate indicator on the HMI to let the operator or maintenance know exactly what the machine is attempting to do, or what the machine is waiting for if it's waiting for the operator, or what fault state it's in.

 

[daba]

Here's part of a program for handling a bolt driving assembly station. (The rest if the program has to do with other assembly stations, so I didn't want to confuse the issue.

I use an integer to keep track of the sequence of operation. When each step is finished, I set the integer to perform the next step. Normally, I run in increments of 10 (a throwback to Old-School BASIC line numbering). That way, if steps need to be inserted, process faults handled, etc., then there is plenty of room with very little rewrite.

Another advantage (for me, anyway) is that I can use a multistate indicator on the HMI to let the operator or maintenance know exactly what the machine is attempting to do, or what the machine is waiting for if it's waiting for the operator, or what fault state it's in.

I do like the shorted branch on rung #8 (page 3).

For me, the numerical sequencer, in its various forms, is by far the easiest for the typical maintenance guy to comprehend. One of the key advantages of the numerical sequencer is that it can only ever be on one step, because an integer register can only contain one number.... i've seen bit sequencers "go astray" (bad programming, usually, but can be caused by an untrained tech toggling bits he shouldn't).

Usually each step of the sequencer code starts with an EQU instruction that tests what step the sequencer is on - this is a highly visual aid to debugging.

If the functional spec is available to the tech, he can easily see the relationship between what is supposed to happen on that step, and what the code is testing to see that it has happened.

example....

F.S. says "Step 55 - Open Valve AV123"

The sequencer code would simply be....

EQU Seq_Step 55, XIC AV123_Open, .....

The end of that rung would be whatever logic you employ to move the sequencer to the next step, or could be a MOV to jump to a step.

 

[JordanCClark]

And if it keeps the 2am calls at bay, so much the better.

The shorted branch leg is from our debug phase. In fact, we started debug this week. Something to see if it works as well without as with. All part of the streamlining...