I don't know if it's similar than micrologix 1400
Neither do I.
Never worked with Micro.
Posts by Sergei Troizky
-
-
No, it does not work the way you described.
The search by skip is typically done as follows:
- Move to the search start position.
- Define the skip condition, if not yet defined earlier.
- Move to the search end position with skip option.
- When the skip condition is satisfied, the move stops, and the next line of the code is executed.
The PR defined in the skip option will contain the robot position at the moment of skip. It may be used in the program, but not necessarily.
- If the search move ends unskipped, the program jumps to the label defined in the skip option.
Keep in mind that stop by skip is not immediate stop, but deceleration to stop. Slower the search speed, shorter the deceleration distance and more precise found position in the PR.
-
If there is a laser sensor on the robot, measuring the height, why not directly measure each part tbefore pickup, instead of some precalculations.
-
Is there anything in $UI_CONFIG.$PROG_COMMON[1–3] ?
-
Unless the PC is on the same physical network segment, I would verify the Gateway address (referred as Router in TCP/IP menu).
-
The attached file is rar archive (changed the extension to zip because of the forum limitations).
Note the separate message instructions for read and write.
The assembly instances are decimal 15n for writing (output) and 10n for reading (input), n being the connection number in the robot Ethernet/IP setup.
No messaging is necessary to/from Configuration instance 100.
Note: writable assembly instance cannot be written using explicit messaging
when an active implicit connection to the instance is running (if any).
With the connection working OK, the robot permanently indicates
PRIO-230 EtherNet/IP Adapter Error (1) and PRIO-231 EtherNet/IP Adapter Idle.
To suppress these errors, go to the robot SETUP>Error Table.
Enter 13 for the FCode, set the ECode to 230, and then under Erlog set it to NODISP.
Repeat for 231 on the next line.
-
3. When the robot is booted with dead batteries, the value of the encoder is visible...
As I said before, such encoder would not need to "establish pulse count" by moving before mastering.
-
Try:
Output Assembly 100, 2 Bytes
Input Assembly 101, 7 Bytes (with diagnostic information), or
Input Assembly 102, 3 Bytes (without diagnostic information)
Configuration Assembly 0, 0 Bytes
If no success, try Configuration Assembly 110, 130 Bytes
Remember, 1 robot word= 2 Bytes.
-
Vendor ID, Device Type, Product Code are irrelevant.
It must be something with the assembly instance number(s) and/or connection size.
Can you attach the eds file you used? -
I'm starting to think that the encoders/pulsecoders don't have any "zero-flag",..
Since Quick Mastering restores mastering precisely within the motor turn, the encoder has to have zero reference position within turn, a.k.a. zero pulse.
Otherwise, there would have to be a finite number of mechanical positions from where the pulse can be established, and then it would "only" be a matter of having the robot's axes in the correct mechanical position when supplying power to the pulsecoders to be able to establish a pulse.
The maximum displacement to find the zero mark is one motor turn.
This is not that much of the axis displacement.
-
Motor absolute position is number of full turns from certain zero+ position within turn.
Many absolute encoders are absolute within one turn, but require battery backup for multiturn counter. Such encoder would not need to "establish a pulse count".
The need to "establish a pulse count" by passing the encoder zero mark indicates an incremental encoder with battery backup. After "pulse count established" the zero mark is not in use.
After "pulse count establish" the zero turn reference is different, and the new master count, after correct quick mastering ,will be different from the old one by exact multiple of full turns.
Disclaimer: These are my own conclusions, not confirmed information.
-
Usually i just do:
PR[i] = LPOS
PR[i, j] = PR[i, j] + L
L PR[i] speed FINE
But maybe there is another wayThis will work correctly only after full stop.
During uninterrupted transition from the previous motion, e.g. with CNT , its target must be used as the initial position for modification:
L PR[n] speed CNT100
PR[i] = PR[n]
PR[i, j] = PR[i, j] + L
L PR[i] speed FINE -
Are you trying to configure the robot as scanner or adapter?
-
Without analizing your logic, I want to remind you that in BG Logic the pulse condition must remain true during entire duration of the pulse.
-
Not clear whether you want to do it manually or programatically.
If programatically, will you allow robot movement for that, and is the frame origin physically reachable?
-
Why not use SKIP in the move instruction(s)?
-
I wonder, why this must be done in BG logic and not in called-on-demand subroutine.
-
With v9 robot software, and assuming the subject frame is active, this should work in BG Logic:
R[x:Active UF X]=($SV_INFO[1].$CART_POS[1]-$SV_INFO[1].$CART_POS_UF[1])
Since the position reading in BG logic has certain lagging during the robot motion, the most precise result will be on non-moving robot.
-
Don’t know if this suits your application but I’ve used the Wrist joint modifier on linear moves to pass close to singularity before.
This is just another way of distorting linear movement, probably even more than by singularity avoidance.
-
RTFM!
SPOT-003 Water saver OK fault %s
Cause: The water saver input is low.
Remedy: Check the input from the weld controller, and reset as necessary.
Advertising from our partners
