Koyo CLICK PLC Ladder Logic Architecture 1

[analogkid2digitalman]

Hello All:

I am in the preliminary design of a system to control various laser safety tri-color beacons utilizing a Koyo CLICK PLC. I have very little recent PLC experience.

The system will support multiple stations looking at various laser and shutter control signals to decode the proper lamp illumination in addition to controlling AC mains contactors and firing of a laser.
Have a question about the overall ladder logic architecture-

One feature I would like to incorporate is checking for for errors:
If a station interlock is not present (cable between PLC and station unplugged).
If the AC mains contactor auxilary contact shows contactor closed when it is supposed to open (contactor stuck closed).

My thought was the first few rungs would check for these errors. If an error detected set an internal register bit ON and load another register with an integer error code.
If error bit is ON then jump to a subroutine to flash lights in a specific pattern. Specific pattern to flash would be determined by the numeric error code.
Turn the AC mains contactor output OFF.
Return from subroutine.

Thus if there is an error I do not want to update other ouputs based on all the conditional logic specific to them.
Therefore would I just insert the state of my error bit (NC) in the first column of every rung?
This is what I was planning on doing, would this method be typical or can you suggest alternative methods or potential gotchas?

What about the internal SC bits such as SC26 (watchdog timer error) and SC19 (PLC errors)- should I monitor those too to be safe?
Have not yet detrmined what state the PLC outputs could end up in if the PLC errors out.

Thanks

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[itsmoked]

You generally put the logic and inputs at the top of your programs then at the bottom you put the outputs in one block. Usually separated and commented with some horizontal comment line stating "==OUTPUT=="

Normally you want no logic happening in the output block and each rung has a contact derived from your upper logic area that just repeats the logic result from above down to the output block. Like:

|
| --|PUMP1|---------(PUMP1_OUTP)--|
|

You can put an "error" contact in all the outputs you want inactive/OFF during a fault condition. That can make your logic more readable and maintainable and quickly helps you see why outputs are not active.

|
| --|PUMP1|---|FAULT_A|------(PUMP1_OUTP)--|
|

If you want to include checks on system bits pile them into on fault and add that condition to the outputs needed.


|
| --|PUMP1|---|FAULT_A|---|FAULT_SYS|---(PUMP1_OUTP)--|
|

Keith Cress
kcress -

http://www.flaminsystems.com

 

[analogkid2digitalman]

Keith:

I like the separation of inputs then outputs for clarity, but I presume mixing that up has no effect of program operation? Processor scans inputs, updates input table, updates output table based on logic , then writes to the physical outputs.

I think I understand your first example, PUMP1 would be an internal register bit derived by logic while PUMP1_OUTP is the physical output of the PLC.
So my intention of using the error bit in-line with the output in the second example looks like the conventional method.

Wonder if I can force the SC error bits in the software to see what happens with outputs.

Thanks

-AK2DM



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[itsmoked]

I think it might actually make a difference where the outputs are. I recall some vexing issues when I started out that were specifically caused by having outputs mixed with the inputs and logic.


Notably if you have, say, an output mixed in with the logic the output doesn't get evaluated until after the logic was already evaluated. This causes things that should've happened on the logic eval to not be updated or correct until the following scan. Any SET/RESET logic or single-pass-only stuff may not work as expected. It might mess up subroutines too.

Try setting any of those system bits and see what happens.


Keith Cress
kcress -

http://www.flaminsystems.com

 

[tygerdawg]

Not so familiar with CLICK. I would guess it would support a rung function that will enable/disable a range of rungs when a specific input contact is set. If CLICK programming has this, then could be used for logic & sequence control based on error state. This would save you programming & un-clutter your rungs.

TygerDawg
Blue Technik LLC
Virtuoso Robotics Engineering

http://www.bluetechnik.com

 

[analogkid2digitalman]

Keith:

Now I see where you are headed in terms of I/O segregation, mixing could lead to a situation akin to a race condition.
I verified one error status condition thus far, if watchdog timer times out, all outputs are turned off.
I'll tweak some bits next.

TygerDawg:

No condition disables available in the CLICK environment. I'll stick to my original plan.

Thanks

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[itsmoked]

tygerdawg; Yeah no such feature on these basic PLCs.
Analog; That's exactly it. You get race conditions that make it work sometimes and not others. Completely mind twisting. Avoid.

You can lump all the system bit tests into one line up in the logic section. Then what I do is add a NORMALLY CLOSED contact called.... |Test| or |DEBUG| or |ALWAYS_CLOSED| into that same system bits test line with a coil called something like -(SYSTEM_FAULT)-

Use the SYSTEM_FAULT to condition all those outputs you need to.

To test it all just whip out the Override window and force that |Test| contact OPEN.

BTW if you password protect the code you always have to be logged in to have the Override Window actually work. You can do everything on the screen but noting ever actually happens. You will contemplate going postal if you find yourself there. It's a bug.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[analogkid2digitalman]

Keith:

Looks like the SC bits related to errors cannot be overridden, they are read only. I'll see if I can force an error by rearranging or pulling some expansion modules.
I would expect when internal PLC errors are detected it will deactivate the physical outputs like it does for the watchdog timeout.
Nothing mentioned in the Help, I'll probably 'contact' Koyo to confirm.

Thanks for the tip on the override password bug. Since this is internal to our facility I will not be protecting it.
I do protect my macros in Excel that are used by various departments, but I inform all related parties that the passwords are in a sealed envelope in my HR file should I quit or have an untimely demise.

Have a good weekend!

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[itsmoked]

Hey AK2DM,
This is why I described putting them all on an Error Rung in series with a permanent Debug Contact you can use for testing every time you mod the code.

Cheers!

Keith Cress
kcress -

http://www.flaminsystems.com