If the controller has rights management (AFAIK KRC4), you can disable jogging without sufficient access level.
Posts by Mentat
-
-
If I understood what you want, then StrToInt() should do the trick.
-
Hi, I doubt that the file actually looks like that as lines 3 and 4 don't look like valid KRL. What happens if you save this :
Code&ACCESS RVO &REL 1 DEF GripperLib() END GLOBAL DEF GripperOpen( ) $out[4] = False $out[1] = True END
as GripperLib.src and upload?
I suspect you added "Global" infront of the function that has the same name as the file it's in or there is no function with the same name as the <file_name>.src.
-
Interrupt subroutines work in command mode, meaning any changes to kinematics or dynamics are only applied until the interpreter exits the subroutine. If you change tool, base, speed, acceleration, etc., the changes are reverted upon exit.
-
Thank you for answer Mentat
But if I use a large APO.CDIS I start to have imprecision in the cornes of my geometries.
That's true.
The only way I can think of to have smooth and precise motion is to convert those motions into splines, that is, if that Kr C2 controller supports them.
-
This is definitely explained in the expert programming manual.
:IN - passes by value
:OUT - passes by reference
-
Could be that $apo.Cdis is too small?
-
To correct the trajectory as the motion is being executed or do a pass over and make corrections for next time?
-
You can read about it and find examples of in Cwrite manual, but it goes something like CWrite($CMD, Stat, Mode, "STOP 1"); Stat is of type State_T and Mode- Modus_T
-
My guess is interpreter does not have write access to $Drives_enable, so just find an alternative way to do what it is you want to do. Send "stop 1" to robot interpreter if this is running from submit, or if it's running in robot, then halt loop will do something similar.
-
I think that code has way too many continues and that command is being abused to hide any errors that could occur. Which, I suspect, is also what happened here. My guess is that Pos_rel is either undefined or uninitialized and the motion planner is told to create a motion to relative position with an offset of null. But it cannot scream in protest, being silenced by continue.
-
To add to what panic mode wrote, having a function for performing some IO is nice because sometimes the system changes and now instead of just setting some output, you also have to check some inputs every time the output is set. E.g. when moving a cylinder, check if/wait until it reaches end. Or maybe just add some wait time. It's a very simple change if you have that as a function.
-
Hes, it seems like you want a Proof of Correctness. That's a part of computer science and you can find a lot of info about it if you search
I only have the faintest notion about how that works, but to make checking of the code practical, the code is usually structured in a way to make it easier to check. Getting a proof of correctness for any random codebase at all is a tall order.
I am not sure if that's actually what you meant, but you wrote several times about testing "if the program pointer has passed that line ever or not". That would test if all lines in the program were executed at least once, which would likely be a subset of that code's configuration space.
E.g., if a function "SmallFunc", that has 2 branches, is called by function "FuncA" and both of the branches in "SmallFunc" are executed, all lines in "SmallFunc" are counted as executed. But if there is also "FuncB", that might call "SmallFunc", those calls will be counted as checked, because all lines in "SmallFunc" have been executed already.
The same thing will happen with any sequential branching statements. One of possible approaches is to build a tree with every branch and function call, then check if every bottom branch was reached and you are done. Except that some of the branches are never reached, because it's god damn impossible to get there.
It's a long and arduous path and you can never be 100% sure that any complex system will always work as intended. But I sympathize with your wish for something more reliable than a spit and a prayer. Some tips from my meager experience so far:
Don't try and verify whole codebase at once. Put some code in libraries, test the hell out of them. It won't mean that the system made of perfect parts will be perfect, but it's an easier start.
Verify your inputs. E.g. KRL will happily silently drop bits of any values above what can be expressed in 16 bits. Sometimes there is no different algorithm (short of making a BiggerNum library) and it's unlikely to get unworkable inputs anyways. If some functions don't work with all values, but won't fail silently, they can still be fine.'
Some things fail with very specific inputs, such that randomly generated values are unlikely to trigger. E.g. Lin motion when there is a difference of exactly 180 degrees in one axis.
-
Depending on how hard and where the robot was hit, maybe consider remastering the robot's axes too.
-
How do calculate the frames of points along the linear path including A, B and C ?
For example if I would try the INVERSE function for every 1° change in orientation.
example:
CodexStart={X 162.764755,Y 126.033981,Z 0.170230865,A -1.54621744,B -0.234725028,C -27.6503887,S 'B00010010',T 'B00101010',E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0} xEnd={X 162.764755,Y 128.033981,Z 25.1702309,A -6.54615211,B -0.203361109,C -0.631258070,S 'B00010010',T 'B00101010',E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0} or p
You will want to use linear spherical interpolation (SLERP), because use of simple linear interpolation on angles runs into some issues.
Overall if you are just learning, then writing a motion planner in KRL is ok, but if this is needed or could grow into something serious, then drop KRL and do these calculations externally.
-
If understood your question correctly, you are looking for something like "Wait for $in[_ChDI_SignalNr]"
Or maybe you are looking for Interrupts.
-
Quite a lovely article, good find, thank you for sharing.
-
1. Move the pellet tank away/ don't mount it on a6 and feed them through a tube. That way when they are all used up, the difference will be much smaller.
2. Either measure their weight (maybe indirectly) or calculate approximately how much is used up and change tool load during the program run.
-
also there are hardware dick duplication devices such as
The true marvels of engineering
-
Look into advance pointer and motion planning. You need a buffer of motions as big as advance pointer to have a continuous motion:
If your advance pointer is 1, then have three coordinates:
Point1
Point2
Point3
Just after robot reaches Point1, you can update it's value and have the desired effect.