So we had some power issues that ended up with the pulse encode count being off and some files being corrupt, so I loaded and old image but ended up having the remaster the zero positions. This was the first time I had to do this so it's took a couple tries, so maybe there is something I missed. I ended up having all the position change which is expected but I am running into one major issue. so when I do a cartesian moves, I'll head well move forward (x+) when moving downwards (z+) accentuated at low end making move of J shaped movement. So this makes reteaching my place positions difficult. Previously the robot didn't do this, so I am wondering if this is something I missed or there is something more to it.
issue with cartesian moves post mastering
-
haightc -
October 11, 2023 at 7:53 PM -
Thread is Resolved
-
SkyeFire
October 11, 2023 at 7:58 PM Approved the thread. -
As far as I know, it feels like it is something wrong with the base frame. I would say you can try messing around with your base frame (Mostly uframe 0).
I think you can goto Uframe0 > {METHOD} > Direct Entry Method and try entering W 180.0 S 0.0 R+180.0 .
-
You have answered yourself, if robot moves incorrectly on cartesian movements and does a curving motion while jogging on cartesian this can be caused either because you have incorrectly calibrated the robot or you have restored an incorrect image on the controller.
If you have loaded an image of an incorrect controller that has not the same mechanical unit type, the kinematic model will not match and linear movements will not work ok.
If you have very bad calibration, the same will happen.... have you moved the robot to 0 marks after doing the calibration and checked that it was exactly at 0 on all marks?
I suggest you to check the original mastering data and restore it manually if you can, this will only work if the encoders have never lost power or battery. Original mastering data usually cames with the robot after you receive it, where I work we usually make a copy of the document and store it inside the controller cabinet.
If you have the data and it is still valid, it's better to restore that data than to remaster the robot again yourself, as it will not lose precission.
-
As far as I know, it feels like it is something wrong with the base frame. I would say you can try messing around with your base frame (Mostly uframe 0).
I think you can goto Uframe0 > {METHOD} > Direct Entry Method and try entering W 180.0 S 0.0 R+180.0 .
I am not sure how to get to uframe setting... if I choose setup > frame I just get the tool from. I can find a uframe offset but my options from that are just program line options line and it set to whole range.
In the tool frame, there is just one for the gripped and all values but Z are zero. I am guess this is just to set the z offset the gripper.
With a M1iA what are generally reasonable axis limits? I seem to get motion limit errors during moves that should be with in the range of motion. -
Active uframe or robot "world" being incorrectly set would not cause the robot to move on a curved way if doing cartesian movements, it only would cause to move on an incorrect direction, but the movement should be still linear, even if it goes in a diagonal direction.
If you are experiencing a "J shaped movement", I have given you two possible causes, forget about uframes, utools or cell frames until you can jog the robot lineary without strange motions.... if you jog the robot in world, user or tool it still should move lineary even if not in the correct direction, robot moving on a curved pattern or "falling" middle linear movement is not normal.
Regarding power loss, it is not a problem if the robot batteries that keep the encoders with power still have charge, these bateries are installed on the base of the robot and should be changed from time to time WHILE the robot is still powered on. These batteries are normal non-rechargable batteries that you can purchase on any shop.
If batteries got empty you should have received a "BLAL" alarm (Batery low alarm) or even a "BZAL" alarm (Battery zero alarm).
If you do not change the batteries after a BLAL you run the risk of losing mastering completelly if a power outage occours.
If this happens, the only way to fix it if to remaster each axis manually again with the zero marks, but it's very difficult to achieve the same precission on the robot as from factory when you do it manually... and you also say that robot has vision, that is the worst case scenario since a robot with vision needs to be very well calibrated in order to work correctly.
I repeat, have you checked if robot goes to 0 position AFTER mastering the axis again??? To check it the better way would be to create a new program, record a new point, change it to JOINT representation with fine termination, modify all axis values to 0 degrees and executing the motion.
After doing that you should check if robot moved to zero marks, if not, master the robot again.
Lastly, I don't know if I understood you correctly with this statement:
QuoteThe imaged restored is from the same machine made earlier this year
If the image came from the same exact CONTROLLER, so you made a image backup from that controller and you restored his own image on his own controller, then mastering data was likelly lost since it should restore the original mastering after restoring the original image. What loses the pulse count after a power loss are the pulsecoders, so even if mastering is ok on the controller side, new pulse values will be generated on the encoder (robot) side so mastering data is invalid after a complete power loss on the encoders)
If instead you are saying that you restored an image from a similar robot (even if same mechanical unit) from another cell that was installed this year into this robot that is from 2013, this is probably the problem.
You should never restore a image from a controller into another, as all options, data and even mastering from the robot you extracted the image will be restored, and mechanical units all have different mastering data, even if they are exactly the same model.
-
If a pulse mismatch alarm is posted, you do not need to remaster. Just reset the pulse coder alarm from the mastering page by pressing F3 for RES_PCA. Then cycle power, set $DMR_GRP[1].$MASTER_DONE to TRUE, and calibrate from the mastering page.
If the robot post a message that it was calibrated, verify the mastering by jogging in world and confirming that the moves are straight and in the correct direction.
If that does not work, you should be able to quick master, but again, that should not be needed.
-
M1a mastering is a bit different than other robots did you follow the manual?
-
If a pulse mismatch alarm is posted, you do not need to remaster. Just reset the pulse coder alarm from the mastering page by pressing F3 for RES_PCA. Then cycle power, set $DMR_GRP[1].$MASTER_DONE to TRUE, and calibrate from the mastering page.
If the robot post a message that it was calibrated, verify the mastering by jogging in world and confirming that the moves are straight and in the correct direction.
If that does not work, you should be able to quick master, but again, that should not be needed.
It was kind of a wall of text but that is what I did when I said cleared the fault but everything was wrong.
-
M1a mastering is a bit different than other robots did you follow the manual?
Yep, took me a couple times. First I took me a minute to to figure out which mark was the mastering mark. the master marks and thin little scratch lines which were easy to see and normally the machine runs in an enclosure. What I ended up doing to to resolve the weird j movement issue was jogging it around the work area several times and that seems to get the servos back insync when I ran the quick master again. One I was able to that settle I set the user frame again and retaught positions. I keep getting close to having the machine running again but running it issues with the program. I didn't write the program and editing on the teach pendant feels kind of cumbersome, I would be nice if I could just type it out like with a traditional programming/script language. I'm going to to make a new thread for some guidance on that
-
*problem solved for me.
I experienced the same problem with new robot.
First i noticed that when i move j2 joint, j3 was also moving but there was no change in j3 values in pos screen and encoder values.
Then i tried to move the robot in world coordinate system. Robot was not moving linearly in world coordinate system. When i close to center of robot, it moves like linear but whenever i go far from the center robot moves parabolicly or like j shape.
Also we did shift test. In program i shift the robot 1 meter but when i measured the distance it was like 1.8m.
We tried every mastering method but didn't worked because problem was not the calibration. Even init start didn't work.
When we bought the robot we took image backup. After that fanuc service loaded to robot new software with special options.
We tought that software could be wrong. So we loaded the first image backup we took then problem solved.
If you don't have that image backup, fanuc service can provide to you.
Menu>status>version id. You can see the robot model. Even the robot model is correct your sofware could be wrong. Because order number of robot could not be supported by that sofware.
Now we are waiting for new software with the options.
Advertising from our partners
