Power-up stage

Hey guys I am fairly new to RLL (including Stage programming), I was wondering if there was an easy to include in my program a start-up section that upon powering-up checks whether all input and out devices are operational, is there a standard procedure (i.e. checking word bytes). Thanks.

Tenbaum

Most PLCs have a power up or first scan bit. If they don't its a trivial matter to make one yourself. You can use this bit to then perform whatever initialization you need.

I'm curious what criteria you are proposing to use to check if input/output devices are operational? Are you refering to the IO cards, or are you refering to field devices? Most IO cards (unless you are using a primitive PLC) return operational status information to the processor already and the PLC will check out the cards as a part of its normal housekeeping.

Tenbaum...

You CAN NOT do what you want to do!

Even if a sensor is configured as normally closed, and you "see" that it is Closed... how do you KNOW that it is in fact ready for use?

For example, you might have a limit switch that is normally closed... it is not being acted on, so there is a signal... however... what if the operator-arm has broken off? Is the limit-switch really ready?

And then there is the case where you have a normally open limit-switch that IS being acted on... is it on BECAUSE it is being acted on? Or... is is on because the "Sourcing" sensor-output is shorted to hot... or the "Sinking" sensor-input (input? output? Hmmm???) is shorted to ground?

You CAN NOT KNOW the reliability of the system until the system begins running! Then, after it begins running, YOU need to "tell" the program what to expect! If things happen as expected, then things are apparently OK... else NOT!

It's one of those damnable "after-the-fact" kind of things!

You don't KNOW you have a problem UNTIL the problem occurs!

Lets find out first exactly what it is Tenbaum wants to do as there is considerable ambiguity in the first post before telling him he cannot do it.

There are PLC cards which can check the integrity of the circuits attached to them. Those cards won't detect a problem like a stuck limit switch but it sure will detect a loose connection or a blown fuse. Based on the post I don't think he is refering to these kinds of cards and I suspect that some tutoring about the difference between real IO and an IO image table may be needed, but until we get some clarification...

None the less, Alaric...

There are PHYSICAL considerations that CAN NOT be accounted for!

Unless, of course, you have sensors monitoring sensors.

Yes, I do some tutoring it would seem. These are the main connections I need to check for: ac torque motors, optical interrupter switches, tension sensors, fiber cutters, stepper motors, ac variable voltage drives. I want to check before running the system that all these components are functioning. Thanks for the help.

Tenbaum

Thanks for the clarification.

There are some things you can do. And at Terry pointed out, there are some things you cannot do. Many motor drives for example will provide fault/ready status bits back to the PLC, either over a network or by directly wiring discrete signals back to PLC inputs. Here is where you are going to have to do your homework and specify drives that have these features. Likewise, some input devices, such as optical sensors provide multiple outputs or operate over a network such as device-net. Many manufacturers provide these so once again you are going to have to do some homework. Some analog sensors use a live zero signal. This means that when the sensor is reading 0, it will output a non-zero signal. 4-20mA sensors and 1-5V sensors are examples of these. A value of less than 4mA will indicate a sensor fault. But be warned that not all faults are detectable and some devices such as discrete limit switches have no diagnostic capabilities at all. It will be up to you to design a machine that is safe when components fail. Be aware that components can fail at anytime, not just before the machine is started, but while it is running as well.

As pointed out, most PLCs have a First Scan or Power Up bit that can be used in your program. I generally reserve these bits for loading default parameters into the PLC, things like default setpoints, COM port parameters, or initializing certain logic.

In your case you would be better off creating some type of ‘Start-Up’ logic. You would perform all the checks you need to do and then enable a bit such as ‘System-Ready-To-Start’. Depending on your logic, you might use the First Scan bit to initialize your ‘Start-Up’ logic.

There are a few reasons you would be better off creating your own Start-Up logic. First the First Scan bit is only on for one scan, this might not be enough time to perform the operations you need. This is not to say that the PLC can’t perform all the logic you place in the First Scan, but rather it might take an external device (like a drive) a second to power up before it can send a ‘ready’ signal to the PLC, in which time the PLC would have already completed the First Scan. A second reason is you will more than likely want to perform your Start-Up logic more often than only when the PLC is powered up, like in the case where a machine is stopped, you might want to perform the Start-Up logic again before allowing the machine to run.

Hi Tenbaum,

What I do in RLL Stage Programming is have a stage S0 called InitializeStage. You use the ISG (initial stage) command rather then the SG since they come on right when the CPU goes into run mode. Do your checks in that stage and then you can JMP to the next stage once everything checks OK.

Cheers,
Tim

Thanks okay but how do I actually do the checks of the various physical I/O devices?

Tenbaum said:

Thanks okay but how do I actually do the checks of the various physical I/O devices?

Click to expand...

Exactly what checks do you want/need to do?

Terry and Alaric gave you excellent information, I don't understand what you are looking for beyond that.

Depends on your needs. There is no standard way of doing power-up checks. Some systems don’t require it, others require limited checks, still others require a lot of checks.

Start making a list of the items you need to check then add criteria that must be checked.

"ac torque motors"

If this is controlled by a drive... you might be able to verify that the drive "thinks" it is ready... but that is all!

You can only verify that the drive "THINKS" it is ready!

You will not KNOW that the drive AND MOTOR is really ready... until you, in fact, try it!

"optical interrupter switches"

You CAN NOT absolutely verify these! Unless... you have another sensor that verifies that the Optical Interrupt Sensor is, in fact, where it belongs!

BUT... even then... if the output of a PNP Sensor is shorted to hot... or the input of an NPN Sensor is shorted to ground... you can not KNOW that the sensor is really ready!

You can't KNOW any of this stuff unless you go through the exercise of a real-time simulated run! That is, until you actually send the process into a dry-run to see that the various devices respond as expected!

"tension sensors"

Same as the Optical Interrupt Sensors.

"fiber cutters"

I expect that these are outputs... you need to exercise the device to verify its' action.

"stepper motors"

Same as the AC Torque Motors... All you can do is verify that the Stepper Controller THINKS it is ready! You won't really KNOW, until you try!

"ac variable voltage drives"

Same as the AC Torque Motors and the Stepper Motors.

What you are asking for, in some cases, is absolutely impossible! In other cases, what you are asking for is damned near impossible... without a great deal of built-in support from the manufacturers.

If you want to absolutely verify that all of the devices are ready... you need to run the process through a dry-run. I would call this a dry-run-simulation.

You need to develop a "model" of what should happen.

Then, when you begin the simulation, you need to verify that things unfold as indicated in the "model"!

If so, then all is well.

Otherwise, if something doesn't happen as expected... then post a message indicating that there is a problem with such-n-such.

Your "simulation-model" needs to provide simulated input activity for the various sensors. Those simulated-input activities should be time-based and somewhat (very) similar to real-time product activity. As each step carries on, as expected, keep carrying the "OK" flag forward. However... don't believe that all is "OK" until the simulated sequence is, in fact, completed with the "OK" flag still held high!

Your model has to take into account the possibility of a false-positive!

That is, you need to verify that actual inputs, those affected by your simulated inputs... which drive real outputs, respond AS THEY SHOULD! That includes actual-inputs, which should respond to actual output activity, are going ON AND OFF... WHEN THEY SHOULD!

It is not difficult to build a "model"... you simply have to KNOW YOUR PROCESS!