The adapter configuration in the robot says connection size 1 word, that is 16 bits=2 bytes.
The connection size in the PLC MSG is set to 16 bytes.
See also:
http://www.robot-forum.com/rob…saging/msg42526/#msg42526
The adapter configuration in the robot says connection size 1 word, that is 16 bits=2 bytes.
The connection size in the PLC MSG is set to 16 bytes.
See also:
http://www.robot-forum.com/rob…saging/msg42526/#msg42526
I doubt the BG logic supports timers, and it definitely does not support Call.
It may contain only assignments and calculations, conditional or not.
Emulate the timer in BG logic only:
R[300:FREE 10ms]=($MOR_GRP[1].$STILL_CNT)
R[299:FREE 1sec]=[300:FREE 10ms] DIV 100
IF ((D[299:FREE 1sec]<>D[298:LAST FREE 1sec]) AND RO[5:SpindleFWD]), D[297:Runtime secs]=(D[297:Runtime secs]+1)
D[298:LAST FREE 1sec]=D[299:FREE 1sec]
You did not specify any detail, such as the robot, the controller, speed and the necessary precision of pickup.
Anyways, I strongly doubt you can succeed this way.
Consider stopping the conveyor for pickup when vision detects a product.
After complete stop, the capture may be redone to obtain precise pickup position.
Stopping the conveyor will also prevent conflict of the robot stalled for any reason, with items on moving conveyor.
The COM1 jumper on the servo board determines the polarity of RIs (and has nothing with ROs).
ROs are sourcing.
The jumper in the A position means RIs set for PNP sensors (sourcing signal).
The XHBK input, however, is not configurable, and is always for PNP.
I would start from the machine tool side.
What is its protocol and format to receive data?
And are you able to make the lathe properly process the data received?
Access to robot registers is impossible directly. For the robot, data on Ethernet/IP connection is group of consecutive bits.
In the transmitting device, you must programmatically encapsulate any data to be sent.
The receiver device must programmatically interpret the received data and write them to proper destinations.
In the robot, these tasks may be done by the application itself or in background logic.
Be aware, that data format for robot Group I/O is unsigned integers.
Automatically disable/enable UOP when TP is On/Off:
$OPWORK.$UOP_DISABLE=(UO[8:TP_Enabled])
The instruction must be created as Registers ...=(...), not as Miscellaneous>Parameter Name.
The background program must be set (in its Detail) to ignore pause conditions.
Yes, in BG Logic program. I never mentioned PLC option.
Execute in background logic: $OPWORK.$UOP_DISABLE=(UO[8:TP_Enabled])
The instruction must be created as Registers ...=(...), not as Miscellaneous>Parameter Name.
The background program must be set (in its Detail) to ignore pause conditions.
Even simpler then, since you need the ROs to be active only during program running.
You only need RO[0]=(F[0] AND UO[3:Running]) in BG Logic.
... should re energise on pressing hold again or when program instruction asks for RO on
The first part makes no sense, because pressing the Hold button again does not resume the program execution.
For the rest, there is no need in Karel. Do the following:
- Replace the desired RO in the program with flag or DO.
For example, replace RO[0] with F[0] in the program.
- In BG Logic, drive the RO[0] based on the F[0].
F[100]=(F[0] AND !F[102]) (One shot pulse of F[0])
F[102]=(F[0])
IF (F[100]), RO[0]=On (Set RO[0] when F[0] activates)
IF (!F[0]), RO[0]=Off (Reset RO[0] when F[0] is Off).
- Add the RO reset under desired conditions.
For example,
IF (!UO[4:Paused]), RO[0]=Off (Reset the DO when the program is paused,
either by the Hold button or by releasing the Deadman switch).
- Do similarly for each desired RO.
Well, so you want to do it by software, and you specified the RO de-energizing conditions.
But when should they re-energize?
I Know with Fanuc you can monitor the pendant keys.
Off topic, but I am very interested in monitoring Fanuc pendant keys.
Do you really know how to do this?
I appreciate your wit. So use it to solve programming problems.
What is the intended goal of such hiding?
Why not use the existing passthru between 24-pin ASi connectors?
Your question is not clear.
Do you need to disconnect a RO on certain events that shut off the robot servomotors, but need to do it by hardware circuits, not relying only on software?
Or you simply do not know how to do this by software?
Fanuc Robotics Original eDoc Documentation CDs For Sale.
All in new condition.
Each US$70 or CAN$80, shipped to continental US or to Canada.
Shipping to other destinations possible for extra cost.
Payment by PayPal. No returns.
MCRMTRIAC06071E Rev.I, 2011 R-30iA Mate Controller Documentation, 2 available
MCROCHT77040101E Rev.D, 2011 R-30iA V7.70 Handling Tool Documentation
MCRMCM3IA060101E Rev.D, 2011 R-30iA & R-30iA Mate M-3iA Operator (Robot mechanical unit) Documentation, 2 available
MCRMC12M207081E Rev.I, 2012 R-30iA/R-30iB ARC Mate 120iC/M-20iA Mechanical Unit Operator Manual
MCREBCNTR04121E Rev.C, 2013 R-30iB Controller Documentation, 2 available
MCROB81HT08121E Rev.B, 2013 R-30iB V8.10 Handling Tool & R-30iB Mate V8.13 LR Handling Tool Documentation, 2 available
Connect light curtains and/or cage doors to the fence EAS inputs, and connect only e-stop buttons to the EES e-stop inputs. Use the e-stop buttons only in emergency.
The "fence open" stop is controlled stop with deceleration.
Be aware, however, that the robot will be functional in T1 mode even with the fence circuits open.
You can also try EGS inputs, for controlled stop in any mode.
http://www.robot-forum.com/rob…12627.0;attach=4462;image