Manually moving from step 1 to 2 to...

Hi Guys!

I'm running in a system using a SLC 5/05 and with some customer specific program traditions.
I have several sequences build the old fashioned way:

x1 Step2 Step1
--I I----I/I----( )
Step1 I
--I I--

Step1 x2 Step3 Step2
--I I---I I-----I/I-----( )
Step2 I
--I I--------

This is how the end customer wants the program written.

Now I need to be able to move from step 1 to step 2 to step 3 to .... manually from the operator interface and back again 3 -> 2 -> 1. Preferably using 2 buttons (Step forward and Step Back)

Any suggestions on how this can be accomplished? With as few program lines per sequence as possible?

Best regards,

Michal_dk

I'm not familiar with SLC but could you not just use a counter and comparators?

"Step Forward" increments the counter and "Step backwards" decrements the counter.

Then some comparators... If count = 1 do step 1, if count = 2 do step 2 etc etc???

That is classic state machine programming. It is a sign that the customer is aware of program design.
You simply add the manual step forward and backwards as individual transitions.
You could try to ask for sample code from the customer.

That's the way I use to do it, but as the customer wants this type of programming and specifically told me NOT tu use registers - it's not an option with counters.

Usually when I do sequences I do like this:
x1
--EQU 0 to W1----I I-----------MOV 10 to W1--

x1
--EQU 10 to W1----I I-----------MOV 20 to W1--

This way I'm certain that only one step is active at at time and I can jump to each step very easily AND I can always see what step is active and the stepping function is easily done with an ADD 10 or SUB 10 command.

But as I said it's a big NO NO from the end customer :-(

Hi JesperMP!

Yes they are certainly aware of how they want to have their programs developed, but in my oppinion this type of programming is old news now that we have EQU and MOV instructions. And their experience lies in CTI (Texas Instruments) programming (the same as Siemens S5) which is, I guess, why they want it done this way.

If I use only one bit for forward and one bit for Back, I'll risk the sequence running through multiple steps before I release the button, using a oneshot it will still bridge my intire sequence in one scan or am I missing something?

Michal_dk

Re "If I use only one bit for forward and one bit for Back, I'll risk the sequence running through multiple steps before I release the button, using a oneshot it will still bridge my intire sequence in one scan or am I missing something?"

Of course, you have to put a oneshot on the condition to jump steps.
/edit: and you have to make individual memory bits for each states manual transition to other states.
When entering a step, I would also clear all other states with a couple of MOVs rather than just the previous state(s). That makes it less likely that you make a programming error and have several active states at a time.

At the top of the scan one-shot the transition condition. Let's say the resulting bit (which is on for one scan) is B3:0/0

Each transition rung would look something like this:

      Step1      B3:0/0                           Step2

----] [--------] [-----+----------------+-------( )

                       |                |

   Step2      Step3    |                |      B3:0/0

----] [--------]/[-----+                +-------(U)

The unlatch prevents other stages from triggering. It's okay to have multiple unlatches.

I can understand the customer's concerns for keeping the code simple, as they have had it before and are familiar with it.

It happens a lot, and getting some to accept a more modern, more flexible, numeric sequencer can be a hard, sometimes impossible, task.

The biggest drawback with the "latch-up" type sequencing you describe, is that it is non-retentive, and the sequence will have to restart from scratch if power is lost, or the processor is switched run-program-run.

You don't say how many "steps" your sequences have, but you would have to modify every single step logic to perform your functions.

A possible solution to your problem is to use BSL and BSR instructions to shift the bit that is on forwards or backwards as required, but it would rely on the sequence state bits being contiguous bits.

Something to work on, perhaps.....

Archie covers this perfectly.
http://www.youtube.com/watch?v=rCa_U6YATTA

That form of construction will meets the customer requirements. Those requirements, while they may be traditional, are going to restrict the capability of the end product. Bernie and daba point out two of those shortfalls.

This is where I like the code I use here:

http://www.plctalk.net/qanda/showthread.php?t=52654&highlight=state+engine

It is very simple to follow. It still translates easily and directly from a flow chart to ladder code, and that section of the code is easy to locate and trace.

So, you can sit down with the production folks and maintenance crew and go over a flow chart with them, and quickly make it exactly what they want, then go edit the ladder code in minutes and guarantee it does what the design document says it will do.

It also copes with the "1 state change per scan" issue nicely, and is flexible, retentive, and not too far removed from electrical relay logic to upset the inheritants of that code, even if they're skeered of math.

Paul

One thing to remember on the "Step Back" operations. Reversing Step 2 may not be as simple as turning on Step 2. If Step 2 is extending a clamp, reversing that step would be retracting the clamp, which could be a much later step.

So step forward may go 1->2->3 but reversing from that point may be 6->7->8. (Unless you make each step do different things based on whether it's going forward or reverse).

Still working on that project.

But we did get a solution to the stepping back issue - we don't do it!

If somethings do go wrong, the operators will stop the system and take out the messed up products and restart.

The company doesn't have much confidence in their workers.

Thanks for the examples, I did learn a few new things.

Michal_dk