We have a gripper that has lineair actuators for extending the size of the gripper.
For that we have two digital outputs : one for making the gripper larger and one for making the gripper smaller.
We have analog input for the actual size of the gripper. The movement that makes the gripper larger or smaller has two limit switches
to protect against mechanical damage.
We would program the logic in the submit interpreter.
Problem is, if the submit interpreter should shut down while an output for the enlargement of the gripper is active, it would never be reset to 0 when the limit switch is hit.
Is there a way to reset the digital outputs when the submit interpreter is shut down, so we wont damage anything?
It concerns KRC4 KSS8.3.
What is the cycle time of the submit interpreter? And what can be the cycle time variations?
Reset digital output if submit interpreter is not running
- SimotionD410
- Thread is marked as Resolved.
-
-
SPS cycle time is entirely dependent on how the SPS is written. The SPS is allowed something like 2ms of run time every 12ms. A tight, well-written SPS can loop multiple times in 2ms. A badly-written SPS, for example one that includes WAIT commands or massively branching code, can take longer.
For your specific issue, probably the simplest solution is to add a PULSE ($OUT[1], TRUE, 0.1) command to the main loop of the SPS. As written, this will pulse $OUT[1] TRUE for 100ms. As long as the SPS loops around and re-fires the command before the 100ms expires, the signal will stay True forever. As soon as the SPS is halted, 100ms later the signal will turn False. You can, of course, adjust these parameters to whatever works for you.
-
Ok, Thanks,
If my SPS is still running and I want to reset $OUT[1] (while the 100ms is still not elapsed), is it as simple as $OUT[1] = False, or will the pulse command force it at true for the full 100 ms?
In fact I am strongly thinking of connection the IO to a Siemens plc (which is already present for the general machine control) and letting the Siemens control the positioning, the robot can then give positioning commands to the Siemens. I don't know what the experiences are in 'robot world', with an application as I explained? -
Any explicit setting to a $OUT 'overrides' any previous command. So a PULSE TRUE 0.1 followed .075sec later by a $OUT=FALSE command will result in a "true" pulse only 0.075sec long.
Controlling the gripper from the PLC is probably feasible. You would need to define the PLC-Gripper interface, and the PLC-Robot interface, such that all parties involved get all the signals they need.
-
What is the best way to measure the actual cycle time of the submit interpreter?
-
Put some code into the SPS that uses a $TIMER, and maybe a counter, and logs data to a .DAT file array. Since the $TIMERs have a resolution of 12ms, you may need to collect data over multiple SPS cycles to work out an precise measurement.
For example, if you simply have the SPS record the value of $TIMER[1] every loop, and see that the value 120ms is recorded 7 times in a row, that suggests that your SPS cycle is roughly 1.7ms. The more data you collect, the more you can narrow that down.
Collecting data over long periods might be required if you're trying to track down changes in your SPS cycle, particularly changes that only happen rarely -- for example, if your SPS opens a text file and writes logging data to it once every hour, you might see your SPS cycle jump from 1.7ms to 150ms, but only briefly, once every hour.
Create an account or sign in to comment
You need to be a member in order to leave a comment