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 way
This 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.
Use Distance Before and set it to minimum value.
The robot model is irrelevant. What is the controller model and the software version?
The main problem with so old system is not its capabilities or spare parts. It may not comply with today's safety regulations.
How do you detect "small collision"?
If with collision guard, the program stops, hence any further code will not execute.
It would be interesting though to test the collision as the skip condition, to see upon the program resume whether the move instruction was skipped before the stop.
This approach only works with fine points. When you use continuous points, the register will change in advance.
But you can set a GO within every movement (that's done in the correct physical position), then use that GO for checking the position.
What do you mean by "set a GO within every movement "? DB?
That's true.
Unfortunately, the OP's "remember where it's at in a program" is not clear. I would restart based on "where it is in the cage".
This being said, it's unclear why abort the program if it has to be resumed/completed.
