'UI[6] Start' does resume from where the program was stopped.
If it is starting over from the beginning then you are doing something else such as:
1. Manually aborted the program
2. Aborted using 'UI[4] CSTOPI'
3. Using 'UI[18] Prod Start' instead
'UI[6] Start' does resume from where the program was stopped.
If it is starting over from the beginning then you are doing something else such as:
1. Manually aborted the program
2. Aborted using 'UI[4] CSTOPI'
3. Using 'UI[18] Prod Start' instead
Or OLPCpro. A cheaper alternative to roboguide. No graphics though besides the teach pendant.
Sent from my SM-G930V using Tapatalk
Well since the hold is a maintained button then it would be fine to do as you originally wanted.
I would do the logic like:
UOP start = start and hold
UOP reset = start and not hold
UOP hold = hold
*hold signal is on when ok to run
Sent from my SM-G930V using Tapatalk
Using BG Logic you could do some interesting stuff. I don't like the idea of start and hold at the same time, because it is unlikely that you will push and release them at exactly the same time so the program may for 1 scan get a start signal when you are not intending it to. A couple of alternate solutions:
1. Add another button for reset, this has the least amount of confusion
2. Make the hold button do a reset if held for more than 1 second, this is a safer alternative but my confuse a new operator
// = remarked out line, the program skips this line of code
(#) = an argument passed to the called program
AR[#] = argument register, this is an argument passed from the calling program
Remarks and arguments are common items in many programming languages, so if you search here and on Google you will find plenty of information.
Sent from my SM-G930V using Tapatalk
You don't set points programmatically. You just jog and touch up the point, or cursor over P[1] and press the 'position' F-key and directly enter. I would recommend jogging it close to where you want and touching up P[1] first, then modify with direct entry if needed. When you touch up it will fill out all data including the current UF and UT.
You need to look at both P[1] and PR[8] and ensure that all data is filled out. Not just xyzwpr, but also that P[1] has a UF and UT and config string. PR[8] will just have 'F' for the UF and UT values.
Also in one post you were using INC. Do not do this. You are replacing the function of INC with the Tool Offset.
Do you have to have a PLC to use this example?
No. There is no PLC in this example.
Sent from my SM-G930V using Tapatalk
If you only have 1 tool then you use that number directly.
-2 is used when you have a tool changer and need to change the active user model.
Sent from my SM-G930V using Tapatalk
Using CNT100 for your start and end points will cause the motion path to "round" off those points and will alter the shape of your circle significantly. It is best to use the lowest possible CNT value for those 2 points. Since you are welding this may require some trial and error to get right as indicated by PDL. The robot will not actually create a perfect circular motion if the start and end point are not fine termination (as stated by david), so this is a trade-off between path accuracy and smoothness of the weld bead at the end points. I would start with Fine as David recommends and only increase CNT value if needed.
The error you are getting is because your points are too far off from being on the same circle.
Look for numreg.va and posreg.va instead. Those versions are in plain text.
Sent from my SM-G930V using Tapatalk
The sensitivity ranges from 0-200.
100 is default. The higher the number, the more sensitive it is to disturbances.
Sent from my SM-G930V using Tapatalk
Your IT department needs to at least temporally give you admin rights.
Sent from my SM-G930V using Tapatalk
Fanuc has OLPCpro, which is their more basic offline programming software. It is a virtual robot and supports TP and Karel. Cost is around $2,500.
I don't think there is any other (cheaper) way to run Karel code. Could get a 30 day trial.
Or you could learn Pascal instead. It is free and you can create programs that run on your computer. It is a computer programming language and has nothing to do with robots, but will help you learn that programming style.
Sent from my SM-G930V using Tapatalk
There can be many reasons for a slow down. Changing user or tool frames, near singularity, motor speed limit.
When a linear motion has a tight rotation it often causes a motor to move very fast to maintain a linear TCP path.
Without seeing what you are doing it's hard to say, but generally you want to use a joint move when changing orientation.
Sent from my SM-G930V using Tapatalk
Ignore or skip. Then when programming, disable the icon editor too to use normal menus.
Not much has really changed besides faster processor and changed vision interface.
Sent from my SM-G930V using Tapatalk
It seem's plausible that you could do this, but has a couple issues:
1. How do you test this without causing a collision and damage? Seems like it would be difficult to get the speed and torque setting just right.
2. When a collision occurs or an over-current fault, the robot will stop and be pushed by the machine. That is not a great way to fail.
I think you would have better luck with a profiled linear rail and bearings instead of the bushings.
Sent from my SM-G930V using Tapatalk