Hi people,
I'm a pretty fresh RAPID user (this is my first time, in the past 3 years I only used Motoman and Kuka), while getting to learn how stuff works in ABB robots one of my colleagues came out with "how life was easier with Second Home Position button in Motoman robots"; he's right, I usually struggle a couple of days trying to teach operators the basic how-to's of robots, even with a Motoman, but at least after 2 days they know which menu and which button to press to get the arm in position.
Does anyone know how to setup something similar in RAPID?
I was thinking about, while in manual mode, keeping pressed one of the prog-keys could make the PP jump over, from basically any point, to a line in the Homing routine, checking a couple of conditions and then going home with a Move instruction.
But how to continously monitor one specific simulated output, which will trigger the motion directly and out of nowhere?
I want this to be just a baseline for something "safer" to come, I already have a backup code which is working in another way, but the management here went like "mmmeh... that's too complicated, why can't we do this by pressing a button and the robot goes in home?".
I have Multitasking in a couple systems but, I'm a real newbie and there's actually no time for some trial-and-error; the only thing I could read about is that there's one motion task per mechanical unit, so i should do something different with a semistatic task, but how do I "jump" inside another task?
Cheers
Posts by varda
-
-
Hi,
had no doubt on it, resetting the system to factory is always a good choice if you have no idea about what happened.
I was looking for a good reason NOT to do a factory reset, actually...... but eventually I had to
That works indeed, on another multimove cabinet with an IRB1660ID AW I had a little trouble in signal configuration regarding the power source (very similar to enagy's case, the alarm occurrence was dated days before the moment it was coming out).
Right now, best answer for the topic: I-Start will do the magic. -
Hi enagy,
same darn issue here. I really have no clue on how I'm supposed to proceed.What happened here? Basically this multimove setup I'm working on is really unlucky, FP dead and gone after 2 months, 1 week later we had a fresh one, 1 more week and it started to give strange errors on boot... found out a couple days after it was stuck on shutdown and not saving data, eventually an ABB tech came here (last saturday) and got it up and running again swapping the flash memory.
Long-Short story: new flash had RW6.05.2005, this system and the other two completing our line had RW6.05.0129, lots of issues about PNET configuration, lost communication with PLC after the upgrade. Looks like the GSDML v2.33 was needed, we ended up asking a new empty flash and do the downgrade to keep all systems aligned. Today I downgraded successfully to RW6.05.0129, Profinet is up again; the only issue, restoring backup to have all my stuff back inside gave me an error (that one regarding IOVIEW_BLOCK) on MMC.cfg, so I just restored files one by one except that one, got it to work again but randomly I get this 120013 Error.
I saved this MMC and found out IOVIEW_BLOCK shouldn't be there and it is not, it's inside the MMC I saved from RW6.05.2005, on any of my previous backups (prior to upgrading/downgrading) there's no such line.
This is my first time with ABB Robots, and first multi-robot controller, I'm gearing on very well but all these things happening just destroy my feelings
System is IRC5 Multimove Independent with 3x IRB4600-20/2.50 Type D
Any help would be really appreciated.
Regards. -
Solved.
Alarm 4400 was due to a CALL JOB for closing/opening the gripper, it was right before one of the MOV instruction.
I just moved it some lines before. -
Right, that was my first thought.
I was thinking about S1D262, which in my case is 2 because I use the arm interference check.. does it affect position/variable calculation time?
What does exactly mean subcode 4? I have the alarm list and I know the text but not the meaning, what could affect the pre-reading process? -
Hi everybody,
I'm getting Alarm 4400 [4] - NOT READY (ARITH), always on the same job and line number.. gets stuck on a MOVJ like forever while testing with INTERLOCK+TEST START, if I release the buttons and try again it rings the alarm.. resetting it and running once more makes the robot continue..In some cases it gets stuck on an IF statement which should be already evaluated, releasing the buttons and pressing again makes it go on with the other instructions; this IF statement is into a job called by the previous, which opens and closes the gripper and verifies the sensors.
Moreover, on the same job it may also "wait" on a different MOVJ which was not completed, it just stops few millimeters below, and trying to restart with INTERLOCK+TEST START many times doesn't help; instead, using FWD completes the motion instruction, and eventually it would stop and fire the same 4400 alarm on the same MOVJ as mentioned in the first lines of this post.
Any idea on what could it be?
-
That's exactly what I was thinking about... but it didn't happen...
What happened is, despite the axis didn't move itself and wasn't moved manually (no power and no encoder, so brake engaged and dead encoder) putting that old value in the abso data again resulted in a completely wrong behavior.
Both robots behave the same, so I fixed by calibrating a new abso for L axis, the easy and short way (eventually I got a value which was nearly double the previous with a small difference, around 5000/6000 pulses less than double, which makes more or less 2.5° of error)Wrong or right, I may go for a shipping issue, because I can't guess other ways for this to happen...
Can anybody enlight me please?
-
By the way,
it's not a twin, there are 3 robots each with a DX200, and 2 of those have their L axis cables disconnected.What maybe seems unclear is, someone in my company disconnected ON PURPOSE the goddamn connectors, maybe overthinking and struggling about shipping issues (not up to him anyway, at least not THIS).
There's no damaged/defective servo, brake, reducer, drive for now.
-
Hi, thanks for the reply,
the axis works fine according to the guy, he was able to jog it as usual.The point I'm missing is - do I have to jog it to the alignment mark manually and then re-set (overwrite) the home value?
I know how to recalibrate an entire robot but my question is if that previous absolute value was lost after disconnecting the cable, or if it's just something I can handle writing the previous value, check position with zero pulses, done...? -
Hi people,
I'm experiencing a "data loss" on two identical robot systems, one MH180 with DX200, both come up at power on with:ALARM 1325 COMMUNICATION ERROR (ENCODER) [SLURBT]
and
ALARM 4107 OUT OF RANGE (ABSO) [SLURBT] while the other robot says only [SLURBT]From what I already know, 4107 is not to be considered because I can just do a "confirm position" in work-home-position (or second-home, never remember...), while the 1325 on L axis means that there's either no communication or a loss of communication between encoder L and the controller.
I'm not on site, but I've been on the phone for an hour or so with a mechanical technician explaining the situation, tried to give some directions to restore the system to normal operation... at a certain moment he just yells "CONNECTIONS TO THE L AXIS ARE TOTALLY MISSING!" and he confirmed that both connectors for power and encoder were hanging freely in the air
What I told him to do so far is:
-Shut the controller down and wait 5/10 minutes
-Unplug 1BC and 2BC cables
-Plug power and encoder connector to the servo
-Plug back on 1BC and 2BC
-Fire up the controller and check alarm occurrenceWhat happened after that is:
-Controller booted nice&clean
-Got ALARM 4107 highlighting L (again, and that's what I was expecting)Under ROBOT, HOME POSITION, all axes had their abso value except for L.
Few minutes ago, under "some" pressure, I told the guy on site to write the missing absolute value (looking at the calibration one in the cabinet) in the HOME POSITION menu.
What I'm missing, since I had no possible contact with my local Yaskawa dudes all day long, is:
How do I fix the darn problem? I mean - what does it take to get back to that moment before disconnecting the L encoder?
I could guess a CMOS restore in maintenance mode but I don't remember if this is allowed in management or safety mode...
And..
Is it correct to just write the missing abso data? The robot has been standing in transport position since its arrival so I'm thinking that what I've done it's wrong because he starts again form zero and not from THAT known position, and maybe I should have done that after putting L to mechanical zero... -
Hi Paolo,
maybe Gamma's idea is to transmit anyway a positive integer, translating it to a negative one using a constant value common to the plc.Like this, say you want to send -11 to the robot, to make it positive or at least zero, you'll need a constant whose absolute value has to be >=(value).
Suppose you will send -1 to -19, your constant can be >=19, let's say 20.
Now, (-11) + (20) is 9, and you transmit 9 to the robot.
Distinguishing negative and positive value transmission can be done with a flag or something like that, a bool variable which is 0 if positive and 1 if negative (or whatever).
Into the robot program you can read the state of your flag and decide to subtract you constant to obtain the negative value ---> 9-20=-11This doesn't solve your Modbus problem but at least you can go on working I suppose.
Regards
-
Hello,
you should boot in maintenance and then under SYSTEM -> SETUP -> OPTION FUNCTION you will find VARIABLE ALLOCATION; ++ will increase, -- will decrease.
Then you will probably have to reinitialize all P vars.Cheers
-
Guys are you integrators?Dx200 Yaskawa mode in motosim without going into mainteinance mode is possible is just a password.
I'm asking if you're integrators because Yaskawa can give you the password only if you really needed for your work.
Regards.
Well, that could be for personal use if I decide to buy a DX200 controller with any robot, my home-nurse making me "torque-controlled peanut butter and jelly sandwiches" and coffee in the morning would be a total win
For my purpose, I asked for a short day-class to upgrade my knowledge in MotoSim, and then I just said it would be beautiful to have a Y mode code also on DX200, and the guy just told me there's one, but it works only on MotoSim (exactly because those who know the way can easily access functions that would require TIME to get activated by someone else... according to me time is precious, and if I'm working abroad it's even more precious).
I'm ok with keeping it as a "secret" but I could even show it to the world and nobody would do anything with it; what will people do, sell fully-activated simulations instead of real cells? Well, there are companies which actually sell simulation sofware and sell customer-specific simulations, but you don't really need Y mode to access all parameters in MotoSim, it's ankwardly simple to do.
-
Hi,
I think you won't need to wire to the MXT but only to CN308 (should be the one with reserved signals).
Well, if you look up at the Installation and Wiring manual, you can see that there are a couple of free spaces like 20011, 20014 and 20017.... you can wire to one of those to input the Servo ON command, and you can wire to 30011 (A1 on that board) to get the Servo ON state out to the plc.
Probably you will have to write down to the ladder program something likeSTR #(the input address you chose)
OUT #(the specific input for Servo ON)while the part to output the state should be already there.
-
Use internal Ladder program, all the signals you need to know are in "Concurrent I/O" manual.
Example: EXT.HOLD is specific input signal #40067 so,STR #20xxx
OUT #40067will hold your robot, where #20xxx is the universal input of your choice, but I strongly suggest you to read the Concurrent manual before doing anything into the ladder if you're not familiar.
-
Hi,
here you go
https://www.robot-forum.com/robotforum/yas…-override-menu/
it is explained in this thread.You should use an input group IG#(xx) instead of an M register to do so.
-
Had a different problem which gave me different alarms, but it was about EAXA21A board, and what Gilbailey10 is pointing at could be one of the reasons.
I had this brand new DX200 which every now and then was going headsh*t with 2 alarms occurring after servo power was applied (AL1680, AL4379); found out later while checking harness and connectors on EAXA board, it was CN509 (plug side), which provides 2x24V to the board, and at least one of the pins was too loose so I hat to replace it.
Pressing the DSW generates a vibration from the contactors which sometimes disconnected one of the 2 lines, losing dual channel operation and generating the alarms.I would suggest to check all harness and connectors there on EAXA board and related connections to other boards before replacing it; keep in mind that Yaskawa can't really reproduce all errors because sometimes it's a superposition of effects and things going on at the same time or with a specific timing, they were not able in any case to reproduce the error I experienced until I told 'em what was the problem.
-
Yes they're identical.
-
SOLVED! I'm a f*****g idiot I forgot an empty line in the code
Besides, I was used to DX100's syntax in structured language, in DX200 "IFTHEN" is "IFTHENEXP" (EXP=expression I suppose) and so AND is ANDEXP, OR is OREXP. Also WHILE was changed to WHILEEXP.
I was writing lines using old syntax.
Still, no syntax errors coming out -
IGH#(xx) is half of a byte IG#(xx).
Since IGH is half, starting from IG#(1) you have that IG#(1)=IGH#(1) + IGH#(2), so IG#(10)=IGH#(19) + IGH#(20).
So far I never needed to use half bytes because usually I use whole bytes or words to transmit and receive data from plc.
You can try using IGHs withAttached the INFORM II manual, look at I/O instructions and you should find a table with the tags explained.