Posts by SAABoholic
-
-
Brand new cell or has it been in production for a while and this problem just started ?
(can't imagine it being brand new since the customer shouldn't accept the install as is, just thought I'd ask)
Which turn table is it, ABB IRBP-R/K or 3rd party ?
Is it a multimove cell or are they more independent ?
Sketchy weld ground ? Measure resistance from the powersource negative (-) to the work table when in position.
-
Not a Kuka guy so I might be off here but you have Test Case
TEST ThingToTest
CASE 1:
CASE 2:
CASE 3:
ENDTEST
-
Holy thread resurrection batman !
No need for a key or anything, you just need the module.
[Edit] and just in case someone thinks I'm a complete [insert profanity here], Iliyan and I have been emailing privately for probably 6 months on various topics getting his cell up and running with an Aristorob and now Smartac.. I did send him an old Smartac module I had from way back when.
2nd note... I never liked the Search_1D modules and the one that prnuk2003 mentions sounds like a much more recent version and/or home-brew.
The best one (IMHO) is probably one that I think was called SMA_2003 / 2005... it had built in ghost detection (false positives) and a few other tweaks that wasn't necessarily "official" but a great collective effort by a talented group of people.
-
How is it hooked up to the robot ?
If it's hooked up through DeviceNet then you should be able to use the EIO file from a Wolf backup to pull the signals that are controlling the welder, then it's "just" a matter of mapping each signal to the proc file. (when you created your system in RS did you select Standard I/O welder as your power source option ?
-
In a robtarget your POS (XYZ) tells the robot where in space it should go.
Your ORIENT (quaternions) tells it which orientation your tool should have when it gets there
Your CONF tells the robot which configuration your joints/axis should have at that position
Your POS can fail because the robot is incorrectly calibrated, booted as the incorrect robot type, etc.
Easiest way to check it is to simply take a tape measure and measure from point A to point B (ideally over as long of a distance as possible) and if the robots distance is the same as reality, then that's good so far.
Even if your orient is incorrect, the robot should still move 1000mm when you tell it to move 1000mm (without reorienting the tool between points).
Your ORIENT can fail because your TCP is bad/poor or the robot is incorrectly calibrated, re-orient your TCP around a fixed point in space, if it doesn't drift terribly (less than a mill or two - your program wont be any more accurate than what you see here)
Your conf cant really fail, except that you can fail to do it right.
A lot of people disregard this and when they cant figure out why they're getting joint re-orientation errors they just add ConfL\Off and all your problems are solved.
Weeeeell... it's not quite that easy... forcing the robot to go to a position with the wrong configuration definitely will affect accuracy. I've personally seen a difference of ~5mm simply by switching the conf values for J4/5 around. Not sure how bad yours is but it's work taking a look at.Granted if you're only moving 30mm I'd assume that both positions have the same conf values so that shouldn't affect it if that's the case, but if one is your reference point and the other is the calculated one then I guess it could be done that way if the programmer didn't take it into account.
-
They're both coordinate systems or references there of....
The object frame is dependent on the user frame and the user frame references your world frame.
So in your case, if you mistakenly referenced the object frame instead of the userframe, that means that you're basically doubling up on the position of the workobject relative to your world coordinate system.
i.e. your user frame is 339mm away from 0 and your object frame is 339mm away from that.
-
again, no one ever said that any single e-stop in a cell shouldn't stop the whole cell, I don't think that would ever be an "acceptable" solution.
Maybe the terminology is the issue here...
The output you're talking about is the one in the diagram in post #6
IRC5 Emergency Stop - Need to decentralize the robot's E-stop
The top highlighted portion is where the (relay) outputs from your PLC would go and the bottom portion is what would feed the inputs to your PLC.
-
A workobject consists of two frames... a user frame and an object frame.
The code is updating the user frame and as such the code is working as it's written.
Without seeing the same workobject / code from the original robot it's difficult to say if someone changed Wobj_R3_WL_LHD.oframe >> Wobj_R3_WL_LHD.uframe (seems unlikely since it requires a bit more knowledge than your basic operator would have) and/or how the data ended up in the oframe to begin with.
Wobj_R3_WL_LHD.uframe:=poseUpdate_R3_WL_LHD;
PERS wobjdata wobj_R3_WL_LHD:=[FALSE,TRUE,"",[[0,0,0],[1,0,0,0]],[[339.029,-535.441,1674.74],[0.0295868,-0.696639,-0.714709,0.0548686]]];
PERS wobjdata wobj_R3_WL_LHD:=[FALSE,TRUE,"",[[339.602,-535.121,1693.12],[0.0295224,-0.696099,-0.715246,0.0547515]],[[339.029,-535.441,1674.74],[0.0295868,-0.696639,-0.714709,0.0548686]]];
-
Didn't see the video until now...
What is the application ? (grinding - duh !) I mean, what is the purpose of grinding that edge is it surface prep, deburring, dimensional ?
Are you using a "flapper" disc or what disc are you using ?
I don't have a backup that would be any helpful because if the function is there already (i.e. it kind of works when you're "dry running") then the rest is all down to process... angles, discs, pressure etc. and that's a bit of a science (there's a reason why there's so few companies doing this) so a backup won't help you.
Depending on the purpose of the grinding, I would probably have tried the other method of FC machining (path based one rather than pressure) because I can see how it would jump all over the place with the current setup.
-
Nobody is saying that any e-stop shouldn't stop the whole cell !? Not sure where you guys are getting that from....
gpunkt is saying that he'd like to re-wire the pendant stop directly to the safety PLC and then have the safety PLC stop the robot, which is fine from a technical point of view
Personally I don't quite understand the purpose of doing so since:
A) it's more work
B) you're modifying a machine from it;'s original state
C) you can achieve exactly the same functionality using the built in external estop terminals (as intended from the factory)D) since safety is an obvious concern - you've now also introduced an additional point of failure in the robots own "internal" safety chain
Both ways will achieve exactly the same results (it'll estop the whole cell) and feel free to do it whichever way you want - I know which way I'd do it.
There's only been a handful of instances where I've seen the robots estops rewired the way you'd like to do it and that's been where the robot is a part of a bigger machine, like an IMM where I think even the Euromap standard dictates that functionality since the robot is considered peripheral equipment to the machine itself.
-
I think it might help if you let everyone know where you are located...
If you're in the US I'd suggest Easom or Preston Eastin
Also depends on which robot you're planning on integrating it with as those two (to the best of my knowledge) will happily supply you with the positioner but won't do much of the integration whereas companies like Wolf will do both at least if you're dealing with ABB or Fanuc.
-
Sorry, guess we needed to emphasize it was a safety plc and not just a plain ol' plc.
I guess you could wire the pendant estop back to the safety plc and have the flow as such that the pendant trigger the safety plc and the safety plc then kills the robot, but that seems a lot more complicated than simply using the external estop terminals since that's what they're for.
If you look at the safety chain in the documentation (if you didn't get any with the robot you're much better off ordering it) it's pretty clear...
Not sure if this is a 100% match to your controller as it's a year old but it should get you an idea of how things work...
https://abb.sluzba.cz/Pages/Public/I…0-011_rev11.pdf
-
I hope you're not (and I'm simply misunderstanding you) planning on keeping the pendant connected to the controller and bypassing the e-stop (wiring it to a PLC instead) that would be a big no no.
Not sure how much the controllers have changed recently but there should be an external e-stop connection point which is where you want to connect your PLC to.
Did you not get any documentation with the system ?
-
Depending on your setup (external axis etc.) you'd be best of to reboot it as a arc welding robot, but you skipping any option disks in the end and then simply use it as a standard MH robot.
If it's just a robot and no external axis you should be able to use it as is.
-
Very crude example for something I did many years ago... all they wanted was the ability of adjusting up/down via two push buttons... Replace the ISignalDI's with an analog interrupt and you should be on your way.
Designed to run as a background task.
Code
Display More%%% VERSION:1 LANGUAGE:ENGLISH %%% MODULE Correction !***************************************************************************** ! ! MODULE: Correction (Program Module) ! Version: Correction 1.00 ! Author: Saaboholic ! ! Description: Background task for handling path corrections while welding. ! ! Designed to run in a separate task. ! ! ! ! History: ! ! 2006-08-29 Created ! ! Remark: ! !***************************************************************************** CONST string stErrDetVer:="Correction, 20060829, rc1"; PERS num nKorrSteg:=0.5; VAR intnum intPosCorr; VAR intnum intNegCorr; VAR intnum intCorrDeAct; VAR intnum intCorrAct; VAR bool bTrapEnabled; VAR corrdescr hori_id; VAR corrdescr vert_id; VAR pos write_offset; PERS bool CorrDebugMode:=TRUE; PERS bool bReCorrActive:=FALSE; TRAP trapPosCorr write_offset.y:=write_offset.y+nKorrSteg; IF CorrDebugMode TPWrite "trapPosCorr"\Pos:=write_offset; CorrWrite hori_id,write_offset; ENDTRAP TRAP trapNegCorr write_offset.y:=write_offset.y-nKorrSteg; IF CorrDebugMode TPWrite "trapNegCorr"\Pos:=write_offset; CorrWrite hori_id,write_offset; ENDTRAP TRAP trapCorrDeAct IF CorrDebugMode TPWrite "trapCorrDeAct"; ISleep intCorrDeAct; ISleep intPosCorr; ISleep intNegCorr; IWatch intCorrAct; CorrDiscon hori_id; CorrClear; write_offset:=[0,0,0]; ENDTRAP TRAP trapCorrAct IF CorrDebugMode TPWrite "trapCorrAct"; IWatch intCorrDeAct; IWatch intPosCorr; IWatch intNegCorr; ISleep intCorrAct; CorrCon hori_id; !CorrCon vert_id; ENDTRAP PROC CorrEnable() IF CorrDebugMode TPWrite "CorrEnable"; IF bTrapEnabled DeleteInt; ! CONNECT intPosCorr WITH trapPosCorr; ISignalDI diPosCorr,1,intPosCorr; ISleep intPosCorr; ! CONNECT intNegCorr WITH trapNegCorr; ISignalDI diNegCorr,0,intNegCorr; ISleep intNegCorr; ! CONNECT intCorrAct WITH trapCorrAct; ISignalDO dotst,1,intCorrAct; ! CONNECT intCorrDeAct WITH trapCorrDeAct; ISignalDO dotst,0,intCorrDeAct; ISleep intCorrDeAct; ! bTrapEnabled:=TRUE; ERROR TRYNEXT; ENDPROC PROC main() TPWrite stErrDetVer; WHILE TRUE DO WaitUntil NOT bTrapEnabled; CorrEnable; ENDWHILE ENDPROC PROC DeleteInt() IF CorrDebugMode TPWrite "DeleteInt"; IDelete intPosCorr; IDelete intNegCorr; IDelete intCorrDeAct; IDelete intCorrAct; bTrapEnabled:=FALSE; ERROR TRYNEXT; ENDPROC ENDMODULE
-
Here's an example...
You could probably use the error handler in your code, capture the error, set your n_select to a number and use a "trynext" instruction to stay with your test case.
Or... in my case I made the menu a function and used that as a late binding (i.e. no reference errors)
plus it creates a fairly clean main routine (three setup conditions for when the OP hits PP to main and that's it.
Code
Display MorePROC main() rLoadPos; rProgTest; SetOPPerm; WHILE TRUE DO %Select()%; ENDWHILE ENDPROC LOCAL FUNC string Select() VAR num nSelect; stHeader1:=stCykel+SecToTime(nAWLogSTN,5); stHeader2:=stEmpty; stInfo{1}:=stBlank; stInfo{2}:=stOP1; stInfo{3}:=stOP2; stInfo{4}:=stBlank; stText:=stChMenu; stFuncKey:=[stMMFKTcs,stMMFKSettings,stMMFKService,stMMFKLog,stMMFKSwitch]; nSelect:=MenuTPReadFK(\Header:=stHeader1\Header2:=stHeader2\Info:=stInfo,stText,stFuncKey\Erase\BrkDI:=diOP1OK); WaitTime 0.5; TEST nSelect CASE 1: RETURN "rTscMenu"; CASE 2: RETURN "rSetup"; CASE 3: RETURN "rServiceMenu"; CASE 4: RETURN "rLogMenu"; CASE 5: RETURN "rSwitchMenu"; CASE 99: RETURN "rProduce"; ENDTEST ERROR IF ERRNO=ERR_TP_DIBREAK THEN RETURN "rProduce"; ELSE RETRY; ENDIF ENDFUNC
-
Use an error handler to capture the break (I can post an example tonight)
-
I haven't had a chance to play with RS2019 so I don't know how drastically different (if at all) it is.
That said, you can always try the RS6 platform, it does support RW5
https://robotstudiocdn.azureedge.net/install/RobotStudio_6.08.01_2.zip
-
I'm pretty sure it's machining ?
80N is quite a lot, is the grinder that unbalanced ?