Hello,
did you uninstall any Technology Package?
Hello,
did you uninstall any Technology Package?
Thank you for the clarification!
This is a very good idea, Panic Mode. Thank you. I had wanted to make use of the Multisubmit on our test cell for a while now but our versions did not permit it. I will go through those steps and upgrade. While waiting for the approval to do so, I would like to ask if there is any difference between using MultiSubmit or calling various .sub files from the main sps.sub.
Oh my bad, I forgot to mention: KRC4 and KSS 8.3.2
I used EKI for the communication. Confirmation if each operation is complete was implemented in each state where necessary and many more. Having many LOC I tried to remove ones that are not particularly related to my question. SendString and RecvString routines were included to show where the string was later used in the code and the execution never reached any of them when I began using a variable and Msgnotify() to follow it. In this case I could only check the content of strBuf[] after the line SWRITE executed, and it was empty. If it is done hard-coded way by writing a dummy string directly in the routines it worked. So I thought the problem is the SWRITE line.
I can not use Multisubmit because the version does not meet the minimum requirement for it. I will surely try what you guys already suggested on Monday. Thanks a lot.
I needed to send and receive strings between robot and Keyence 3D vision sensor for Bin-Picking. I often send the trigger scan signal as soon as robot is outside the container area so that sensor controller has enough time for the calculation of the next part(s) to pick during the time robot is doing other jobs like placing in the machine etc. When robot is back in Home position it will request the calculated next pick-positions from sensor.
This time because of a very small cycle time robot needs to obtain the next data from vision sensor as soon as possible in advance for background calculation during other jobs. I have created a state machine in a .sub file for background communication using submit interpreter.
Here is my problem:
Each time a string should be written in buffer strBuf[] but the buffer is always empty after the command is run.
Running the same program with robot interpreter works fine but at cost of time(up to 2.5 Sec), but by using a submit interpreter:
SWITCH subStep
.
.
CASE 4
bOk = STRCLEAR(strBuf[])
nOffset = 0
SWRITE(strBuf[], state, nOffset, "TPR,101,0,%d,1", nLoopCnt)
subStep = subStep + 1
CASE 5
KeySendString(strBuf[])
subStep = subStep + 1
.......
CASE 6
KeyRecvStringSub(strBuf[])
.
.
ENDSWITCH
Display More
My first thought is, it needed more time to perform this than cyclic time submit interpreter allows so no string is received after executing KeySendString(strBuf[]). Is there a way I can get this done correctly?
Thanks
My usual approach is to plot out the fence lines and corners on paper or CAD, relative to $WORLD, and create my Cell Perimeter and/or Workspaces from that. Then, test in T1 by attempting to run into the fence or breach a WorkSpace, and making adjustments if the zone boundaries are too tight or too lenient. That part's not too hard.
I also use this classical approach, but sometimes the safety/working zones in some cells are complex, so much time is need to everything setup. In such case I will recommend defining these zones with Process Simulate software if you are familiar with and have access to it. You can visualize and test everything in simulation (apart from velocity and acceleration). It is very easy to export the parameters into robot controller after. With this method you dont have to adjust the zones each time.
But where I keep having trouble is the velocity reductions. I often have setups that work fine in T1, with what seems like plenty of margin, but will show unexpected slowdowns near the boundaries that only show up in Auto. And the entire process of making a change, waiting for the robot to reboot, then testing in Auto again gets cumbersome.
With the velocity, testing the zones in Auto/Ext modes and T1 are not completely the same, especially if you have more PTP motions close to the boundaries.Variables to consider in the custom.dat are $SR_VEL_RED=TRUE and $SR_WORKSPACE_RED. The variables can be used to activate/deactivate the unexpected-slowdowns when approaching the zones.
The main thing I'm interested in is this: is the a better way to predict the "slow zones" in advance? The SafeOp documentation talks about this, but only in the most general terms. To avoid the slowest parts of the trial-and error way of testing? Heck, if I could just get a warning when the robot is in T1, it would make adjusting the boundaries much faster. Has anyone figured out a more clever testing method, or even a better "rule of thumb" for this?
One way is to configure some $WORKSPACE[ ] monitoring in custom.dat to monitor where the robot is in order to predict in advance when robot in approaching the "slow zones". You will need to define those boxes close to where you want to predict. The combination of those box-zone monitoring and program-override variable $OV_PRO has done the job for me in the past.
Remote connection is not possible in this case as the communication, IP address setting are not ok. The usual way is to check with monitor. The monitor must display something. Has this controller functioned before? Have you recently changed a component in the cabinet?
Hello
This is well covered in KUKA training program. There is also a set of tutorials which KUKA has prepared for beginners and this is included in it. On the KUKA download center you can get this .zip file named KUKA.WorkVisual_V4.0_Videotutorials. The sample program include basic palletizing.
Thank you guys. Load data is correctly set. $ADVANCE is left as default. The robot is KR 180 R2500 extra (with KRC4 and KSS 8.3.2) and not Absolute accuracy robot. There is no message concerning the movement. The positions are calculated but the calculated positions are already assigned in the arrays before the subprogram containing the circular motions is called. At up to 50% speed in Auto Mode the movement is smooth, but it changes as the speed increases.
I already tried to use CONTINUE before the next loop and it did not help.
When I get to the cell today I will try to trace with $PRO_IP if it helps
Using the Spline is like more Centrifugal force is applied to robot perpendicular to the path of inertia before returning to the circular path (around 1.5 - 2mm deviation).
@Funibi can you please explain what you meant by circ angle instead of approximation?
Hello,
I want to use iron brush to smoothen the edge of rings. Classically I used
This has a pause after each movement in the loop so it create uneven pattern/trace on the ring. I want the robot to execute a smooth movement.
I have tried with SCIRC spline movement but robot slightly move about 1.5mm out of the path and thereby create another pattern on the ring. Is there a way to eliminate the uneven movement?
Thanks
KRC4 and KSS 8.3.2
Did you teach the positions at the reference point in such that at the reference position, both proximity switches are activated and deactivated the same time by the actuating tool finger?
Hi,
there are interesting posts in this forum concerning your question. You will need to search. For example, a recent post on KRC4 (though yours is KRC2) may be helpful:
[ftp=ftp://www.robot-forum.com/robotforum/kuka-robot-forum/software-options-for-interfacing-with-kr-c4/]https://www.robot-forum.com/ro…r-interfacing-with-kr-c4/[/url]
Hi,
Option one: On Workvisual, under the Extras go to Options. Among Options are Rules for Code Generation. Uncheck the option that prevents code generation if not all options are installed in the necessary version.
Option two: Install this option on your WorkVisual. On the robot's D:\KUKA_OPT\ directory, there is a subdirectory for TP installed in the robot. Copy files to your computer and install the Option Package in WorkVisual. First close the active project and the option to install the package will be enabled.
I think somehow your $ROBROOT values in your machine.dat have been changed. This has to do with your robot world coordinate system.
Oh. That was my mistake. I meant to type 8.3.30.
Thanks Panic mode. I would like to try it on KSS 8.3.2, and I will ring KUKA about that during working hours tomorrow.
I read sometimes ago that Multisubmit package can be downloaded freely. I checked KUKA website and searched online but no success. Does anyone know how to obtain this? Thanks
Hello,
try to connect the controller to external monitor. Restart the OS and see what the error appears to be.
Torque monitoring can never prevent collisions, but can be used to minimize a damage. This means the robot can react faster after collision is detected. Reaction depends on many factors, such as the speed and velocity, payload, inertia, everything robot is carrying. So to answer your question, increasing the sensitivity of the robot axes will only make the reaction quicker after impact.
Hi Francis O'farrell,
I read your post more than two times but could not understand it. You may read the pinned post "READ FIRST", give details, mention your goal(s) precisely and what you have tried (or understood). These give better understanding to those who can provide some clues.