BWD won't execute logic instructions backwards-- only motion instructions. Sorry.
Posts by SteamPunkstress
-
-
Do you need to grip it the same way every time?
What type of EOAT are you using to grip the part?
It looks like a lot of your 3D data is purple, which means it is being ignored when it comes to the plane calculation.
If you're using the GPM locator tool + Plane Locator tool combo, the X, Y, and R are coming from the GPM. The W, P and Z are coming from the Plane Locator.
Make sure that your reference position is taught to the exact part in the tray that you think you are referencing. Ex: take all parts out of the tray except one and do a fresh snap/find/set ref pos. process and then touchup the positions in the TP program.
-
I am working on a simulation in RoboGuide wherein I need to prioritize picking/placing parts based on the status of part present sensors (PPS).
I know that these are dependent upon Simulation programs.
My issue is that when I hit the run/play button, my cell (that used to work back in June) seems to no longer trigger changes in the PPS inputs on my robot, so it keeps looping the same pick and place instead of indexing to the next station for picking/placing. If it helps, the parts also were not appearing/disappearing when I ran the simulation.
When I ran in Teach/Step and forced the appropriate PPS I/O after each pick/drop, the program ran correctly and as expected.
Insight on what settings to verify are appreciated! I'm more of a real-world robot girl myself. I can fight with a real PPS with the best of them, but I am just not as familiar with their functionality in the virtual world.
Thank you in advance!
-
Haha. Mine was slightly more PC than than, but apparently not enough. lol.
-
Hello,
I'm a robotics instructor and I'm looking for any tips on how to get students to remember the right-hand rule. I had a saying, but my bosses decided it wasn't politically correct enough (they were probably right in their decision as I'm now working in a professional environment rather than a shop floor, but now I'm without a witty saying that helps students remember).
Particularly students like to get X (pointer) and Y (middle) fingers mixed up.
Anything that rhymes or is memorable would be appreciated!
-
Thank you. I was wondering where to stick that particular line of code, but I think I figured it out in CLINFRTN.
I made the offset an R variable too so it can be altered if need be. -
Hello,
I'm working on a PalletPro robot and my issue is that the EOAT needs to pick 2 different types of product. Although the vacuum cup configuration is close to where it needs to be to successfully pick both products, I do need to shift one of the unit loads' infeed pick position by about 10mm to ensure that all of the cups make a solid seal. (The infeed pick position is perfect for all of the other unit loads, so I don't want to change it for all ULs.)What would be the best way to remedy this issue through the robot (re-engineering is no longer an option).
Thanks!
-
Hello everyone,
Is there an industry standard regarding the direction of the red arrow pallet in PalletPro cells? (Should the red arrow be in the farthest corner or the closest corner to the robot?)
Thank you for your insight!
-
Cartesian.
$WORKSPACE[1] {X..... X1= 250, Y1 =250, Z1 = 250, X2 =-250, Y2 = -250, Z2= -250, MODE #OUTSIDE}
SIGNAL $WORKSTATE1 $OUT[6] -
Hello,
I'm having a lot of issues figuring out how workspace monitoring works on a KRC4 4-axis KUKA.
I have moved my robot to a "Home" position.
I taught the Workspace 1 origin using the actual position of the robot at "Home" referencing Base[0] and Tool[5], with the "Outside" setting.
I taught the Workspace 2 origin using the actual position of the robot at "Home" referencing Base[0] and Tool[0], with the "Outside" setting.I taught a program that moves the robot in a triangle where the 2 points other than "Home" were outside of the 250mmX250mm dimensioned cubes.
The first triangle of points referenced Base[0] and Tool[5].
The second triangle of points moved to the same physical positions, but referencing Base[0] and Tool[0].When I ran the first triangle of points (Tool[5]), my Outputs for Workspace 1 AND Workspace 2 were ALWAYS high.
When I ran the second triangle of points (Tool[0]), my Outputs for Workspace1 would go low, and Workspace 2 was alway high.The outputs triggered during the first triangle just seems wrong (one or the other should have go low at some point).
The outputs triggered during the second triangle seems backwards, based on the Tool # being referenced.Does anyone have any insight on this?
I'm used to Fanucs, which have you teach to origin and dimensions of the workspace in reference to the world coordinates, but then it checks it against whichever tool number is active. This doesn't seem to be the case with KUKA, and I'm puzzled.
Thanks!
-
So the RETURN command would require a "fault" flag that would need to be evaluated at the next level higher-- that sounds like it could get really messy really fast.
I have a program that gets called at the top of the MAIN.src called Return-home.src that evaluates the position of the robot. If it is within one of the defined position monitoring cubes returns home without incident, and if it isn't it spits a fault message that it needs a manual jog home... what would the code and syntax for the CWRITE-CANCEL or CWRITE-SELECT look like?
Code;Make sure that the tool currently attached to the 100kg master is Tool 1. IF TOOL-ID1 <> TRUE THEN ;FAULT ;Send specific error message output to PLC/HMI DOUT[177] = ON CWRITE-CANCEL ENDIF
Hopefully then the operator would fix the cause of error and then upon restart re-select the MAIN()?
-
As my post footer says, my primary robot experience is with Fanuc and Motoman-- both of which have an "Abort" function (or equivalent), which cancels the current program and prevents further motion/action of the robot until the Main program is re-called.
All I've been able to find in the KUKA documentation is the HALT command, which isn't "strong" enough to accomplish what I'm looking to prevent (an operator being able to just restart the program on the next line). For example in my tool changer program, if the Tool ID of the currently attached EOAT isn't Tool ID 1, then I don't want to try and drop off the tool, I want to throw a fault message and then prevent the operator from continuing to run the current program:
Code;Make sure that the tool currently attached to the 100kg master is Tool 1. IF TOOL-ID1 <> TRUE THEN ;FAULT ;Send error message output to PLC/HMI DOUT[177] = ON ;"ABORT" ENDIF
I could do something messy with flags and GOTO commands, but I'd rather just "Abort".
Thanks for your insight!
-
Oh! That seems kind of complicated. For our current application I think it might be better for us to just send a signal to the PLC/HMI which robot is in need of response and make the operator burn the extra calories to get there! ; )
But, this is good to know for the next time the subject comes up and the customer decides that the operator walking to the specific robot is NOT an option.
As always, thanks for imparting your robot knowledge!
-
Using the example code generated by panic mode:
MsgDialog(nAnswer,"Does this look simple enough?","R2D2",,"Maybe","No","Yes")
Is it possible to "push" the buttons to satisfy the message from a PLC/HMI/other remote source? (So the cell operator doesn't have to hunt the specific robot down and push the button on the TP, but rather have the central HMI present the operator with the options)
Can just populating the nAnswer variable remotely satisfy the message dialog?
I have basically the same question about the ability to acknowledge a MsgQuit from a remote source.
Thanks!
-
I would guess that maybe you need to make the motion before you call the new frame a FINE motion.
It could just be reading ahead too quickly-- but I don't have a Fanuc on hand to test for you.Let me know if this helps.
-
Is this code (from the KSS 8.2 Meldungen V1 en) how I would deal with the input?
Code
Display More1 decl KrlMsg_T msg 2 decl KrlMsgPar_T par[3] 3 decl KrlMsgOpt_T opt 4 decl KrlMsgDlgSK_T SK[7] 5 int nHandle, keynumber 6 ... 7 msg = {modul[] "MyTech", Nr 7, msg_txt[] "Continue?"} 8 SK[1] = {sk_Type #value, sk_txt[] "yes"} 9 SK[2] = {sk_Type #value, sk_txt[] "no"} 10 ... 11 nHandle = Set_KrlDlg (msg, par[], SK[], opt) 12 IF (nHandle > 0) THEN 13 while (Exists_KrlDlg(nHandle, keynumber)) 14 wait Sec 0.1 15 endwhile 16 switch keynumber 17 case 1 18 ... 19 case 2 20 ... 21 case 0 22 ... 23 endswitch 24 ENDIF
It seems rather different from the Star Wars setup. Am I comparing apples and oranges? -
Ah! Okay, I didn't know the "nAnswer" portion functioned like that. Thank you!
-
Regarding the Star Wars code example you gave, panic mode, is there a way to link the soft keys to different functions?
Ex:
yes --> call MoveHome()
no --> abort
maybe --> retry?
-
Ah, that would make sense why it has changed between backups then.
Thanks.I suppose that means my issue lies elsewhere... hmm...
-
Thank you!
The KUKA documentation we have lists PUBLIC as a key word, but then doesn't list any examples on how to employ it.
That seems to have solved my issue.