When you install RoboGuide it allows you to select what controller software versions you want to include. I don't think it goes earlier that 6 on RoboGuide. You could try that or possibly there is an older software available.
Posts by HawkME
-
-
The W,P, and R angles are actually Euler angles. They are not always going to be an intuitive value depending on the orientation of the robot.
Can you tell us your what you are trying to accomplish by reading the angles? Maybe there is a different solution.
-
Not enough information.
-
A condition handler looking for that specific error code would probably be the most reliable way to catch that.
-
I use a combination of TP Programming on the pendant and using the same TP programming language in a text editor.
I agree with Lemster68, first and foremost you need to be able to work on the pendant. Then if you do offline, it's best if it's the same language as the pendant so you don't have to context switch.
When an assembly line is down, operations doesn't care if you know ROS or c++, they care how quickly you can get the machine running again. The fastest way to troubleshoot a down robot is through the pendant.
-
I have seen that before and think it is a bug in RoboGuide. I don't know a way to fix it, but you could store user frames in PRs and then have a small program to set a UF = PR. Then you can have many frame definitions saved that you can load as needed by calling that program.
-
Your order is good. User tool, user frames, vision, then run slow in teach mode and touch up as needed.
-
That's good.
Still start by taking image and AOA backups of each robot.
Then you can restore from the other completed robot.
After that you will want to load the correct mastering counts. If the new robots were already mastered you can simply load the sysmast.sv file from your AOA backup. If not then you should enter them manually from the original data sheet. After mastering, take reach robot joint to 0 degrees to verify mastering is correct.
Then go into the system variables and enter the correct robot F#.
After that is completed you can do your list of things above (tool, frames, vision, etc).
-
Is it the exact same model # of robot and controller? Does it have all the same options and hardware in the controller?
-
Why are you restoring a backup?
Before you do so, take a new image and AOA backup. Then you can undo the restore.
-
Do what you think you will enjoy more.
In my region of the US it seems that in demand trades sometimes make more money starting out, but engineering has a higher top end and more flexibility to move into different career fields.
Engineering also tends to involve a lot of other non-technical aspects, such as project management and people management. While Robot techs and electricians tend to stay much more focused on technical hands-on work.
-
You can only load the binary version of that file.
-
A search algorithm, like Hermann mentioned will work but can be somewhat slow on a Fanuc to process. A lookup would be better.
You could create an array of position registers where the index # is the search value, and the X and Y value of the PR are your two return values. It is kind of a trick to get a multi-dimensional array. You would need to go into a controlled start to increase the number of PRs available, then enter them all. Alternatively, you could do the same with regular points in a dummy program.
-
You could do a bunch of cnt 100 points but it would be difficult to get the timing right.
Another idea would be to control the program override % in the background based on current position system variables.
Either way is not exactly cut and dried.
Can you control the deposit rate at all besides controlling robot speed? What about your rpm of the wheel? Maybe you can approach it the other way around. Robot speed is what it is and you control the other devices. That's how sealant dispensing is done.
-
By trapezoid I mean the graph of robot TCP speed vs time. It ramps up to the commanded speed, then stays at that speed for a while, then ramps down to stop at your end point. If you draw that out on paper your actual speed makes the shape of a trapezoid.
-
Why can't you go the other way. Send the 2 indexes of that table to robot registers and then it is easy enough to lookup the value using a simple pointer formula.
-
Agreed, always set the quick master ref when you get a new robot. 99% of the time I do it with all axes at 0.
-
UO[6] is a digital output. That is the solution, just use it directly.
-
That's a tricky problem to solve. Theoretically if you get the ACC set correctly you could do it in a single move. Try ACC 50 and see what happens.
Also due to the trapezoid shape of the robots motion profile, you may need your starting point to be before and ending point after the circle. The robot will be starting at 0 speed, ramp up to your commanded speed, then ramp down to 0 at the end point.
How precise do you need to be? I think with a robot this will be more of a trial and error type of solution. If you need very precise control, then a stand alone servo would be a better fit.
-
It may be the J2/J3 interaction limit. Is the arm closing on itself when this happens?