Posts by Reintz

You can do V-groove search with Yaskawa robot!

Most likely you will have to make the search JOB yourself or find someone to do it for you.

A search job such as shown in the second video (starting 1:52) can easily be made, but I doubt there are any instructions by Motoman how to do it. As far as I've seen the few simple Search jobs that come with the robot are quite useless when it comes to heavy or complicated searches. Nor do they help you save time by being flexible. So in the end it's best to modify them or make your own that suit your needs the best.

The one shown in the second video - as you are using DX200 and can use arguments with Call Job instruction, I'd make the job so that the step length with which it goes across the plate is set my an argument. That way you can make it longer where the groove is wider, thus saving time. And make the steps shorter when the groove is narrow in order not to jump the groove. You can also make the Search job give you the groove width. That way you can use adaptive weaving or just change the welding speed according groove width - for that it's best to calculate your welding speed into a variable and use it with Speed instriction before welding movement (MOVL speeds undefined for the weld so it would use the speed defined by previous Speed instruction) or just define the welding MOVL speeds by the variable carrying it.

I don't have a robot nor MotoSim at hand to take a look, but I'm 99% that you can get the value from R to D using SET instruction. You might need to multiply (MUL) the value by 1000 before you do that to get a correct value to X or Y of a P-variable (using SETE instruction).

I have done such calculations on a DX200.

Don't know if they have changed the voltage of ComArc boxes, but in 2015 they were 200V. If they have lowered the voltage, it's a shame - even with 200V primered surfaces can be tricky.

If you have no way to up the voltage (and I don't see how you can without changing hardware) there are a couple of things you can try:

- If the gas nozzle of the torch is not isolated from the wire, you can do touch sensing with the nozzle instead of wire. With a coated surface the wire might get bent if there is bad contact, in that case nozzle will give you much better results.

- If cycle times allow, modify your search jobs - lower speed while doing the search move will give you more accuracy. You can also write the jobs so the robot executes each search movement twice - after getting contact it pulls back a few mm and does a second search movement for the same direction. After that there should be a part that calculates the difference and stops or researches if the result is off.

If the surface if coated occasionally then I'd write the search job so it does these slow/double searches depending on a value of some designated variable. This value can be set at the beginning of the cycle with dialog instruction for example.

- As you have a DX200 you can use arguments in a job, so you can write a job that comapares two P-variables (defined by an argument) and does something if the result differs more than allowed (also defined by an argument).

This comparing thing you can write into a seach as well.

I use all of these, some with laser sensing. But as I use ComArc my favorite is to use a job at the end of a weld that calculates a shift value from the difference between the weld end point (taught) and where the ComArc has guided the robot (actual). Works a charm when you need to make short welds on a long staightish line.

Quote from liujj05

After some study I found maybe most of the JBI files use "PULSE"，only if I use relative job the part will change to "USER"，is there any other kind?

Thanks very much!

Yes, if you use relative job the positions are defined by some frame (a user frame in your case) and the positions are stored not in pulses but positions in that frame.

In a pulse job, such as yours, the positions (steps, refp) are defined by pulse values. So for them the Position Type (POSTYPE) is pulse just like in your picture.

But for POSTYPE USER I would guess you were saving some P-variables and those were in USER frame. Though in that case the line would not be CXXXXX=... but PXXXXX=.

To answer you question we'd need to see an example of POSTYPE USER as well.

In a 3h cycle, it doesn't really matter if I slow a 3cm weld down. I'd do it right away if I knew the speed at which it can go through the corner with all possible P-variable shift values.

There is a third option as well - I can just use the P-variable value to shift not the robot, but the base axis (it's a gantry with 3-way base) - that would still shift the weld but would keep the robot movement constant.

At the moment I'd like to know if there is a parameter (or other setting) that can avoid the Excessive Segment alarm by limiting the speed where needed.

Hi

Welding robot DX200.

In one of the jobs there is a tight corner the robot welds through. I noticed right away when writing the job in MotoSim that there's a lot of axis movement in that corner but there was no other way to go through it as I couldn't stop the weld in the corner and I didn't have any better angle to approach from.

It workd in MotoSim with the given speed and most of the times it works on the robot as well, but sometimes I get an alarm going through the corner: Excessive Segment [R1:HIGH SLURBT] - R and T highlighted.

Alarm Reset and restart will make the robot successfuly finish the weld.

I'm using P-variable (value found with search) to shift this weld and it seems that certain P-variable values shift the corner to where the axis movement is still to great for the given speed . I've seen this before where a linear movement with shift could not be executed with a certain P-variable value, but worked great without it.

I decreased the speed for the corner - I still get the alarm but not so often.

Now my question - is there a parameter (or any other way) that could make the robot go through this corner with the maximum speed it can handle BUT not greater than defined by the MOVL instruction?

Is TCP calibrated?

Robot to external axis calibrated?

As far as I know you can't use LOADJ to load from a USB connected to the pendant. We use a product called YasXfer, it connects to the controller via ethernet, but you should be able to use a PC as well.

You have to load the job before you can call for it.

NOP

LOADJ:Print3D

CALL JOB:Print3D

DELETEJ:Print3D

LOADJ:Print3D2

CALL JOB:Print3D2

DELETEJ:Print3D2

.

.

END

If you have a lot of different JOBs you call for then I'd use Notepad+ or similar to just add the LOADJ:xxx before CALL JOB:xxx and the DELETEJ:xxx after it - I'm pretty sure it can be done.

Hi

May I ask why loading necessary jobs isn't sufficient?

I use LOADJ and DELETEJ instructions to automatically load and delete jobs, as there isn't enough space to store all of them in the controller (DX200). Not using FTP though.

I reached a point where there was no vacancy on the robot to write new programs by the end of 2017. Had my MotoSim training and hardware key in January 2018 and it was HUGE help. I now write almost everything in MotoSim. It has also let me experiment with different solutions to get the task at hand done in the most reliable way. By now we don't have a dedicated operator - the largest products take over 4h to complete, but the programs are writen so the robot wouldn't run into trouble - there is a "IF" for almost all possible scenarious. When the robot stops, it makes a call - it has a cellphone connected to it.

MotoSim, if put into good use, can be a gamechanger.

DX100/200...

I just tested it on a DX200 and it turns out, it doesn't do it on the fly - you get the exact position.

If the position doesn't have to include shifts or no shifts are active turing the move, it's also possible to use $PX004 in GETS instruction - that will get the position of the previous MOVx instruction without shift data.

In my opinion using Pxxx vs Cxxx is a matter of preference and what the programmer is after. And also which works better with the current task.

Look under IN/OUT -> SPECIFIED OUTPUT. I have SOUT#0036 - Teach mode set and SOUT#0037 - Play mode set.

You can use DIN command to read the state of input/output in a job.

DIN B001 SOUT#(36) for example would put the state of SOUT#0036 (Teach mode set) into B001 (0=off; 1=on)

Quote from DKirkman

I have been wondering why my speeds are off..

Not sure what the controller does or whether it rounds it off when using 4 decimal places, but how do you make a difference between 0.4567mm/s and 0.5mm/s? Should be impossible to visually make a difference.

If the liner movements have tool angle changes and you find the speeds to be off from one move to another it might be your TCP is out of place.

Quote from Fester1981

Code

GETPOS LPX000 STEP#(LB001) 
CNVRT LPX000 LPX000 TF TL#(5)

You're sure you can use local position variables there? Only asking because I can't (on a DX200).

Maybe this will get you there:

WHILEEXP LB000<=6

GETPOS LPX000 STEP#(LB001)

CNVRT LPX000 LPX000 BF TL#(5)

SET LP001 LP000

SUB LP001 LP001

SETE LP001 (1) 20000

SET LP002 LP001

SETE LP001 (3) 80000

SETE LP002 (3) 330000

SFTON LP001 TF

MOVL LP000 V=400.00 PL=3

SFTON LP002 TF

MOVL LP000 V=80.0 PL=3

SFTOF

IFTHENEXP LB000=1

MOVL C00003 V=320.0 DEC=30

ELSEIFEXP LB000=2

MOVL C00004 V=320.0 DEC=30

ELSEIFEXP LB000=3

MOVL C00005 V=320.0 DEC=30

ELSEIFEXP LB000=4

MOVL C00006 V=320.0 DEC=30

ELSEIFEXP LB000=5

MOVL C00007 V=320.0 DEC=30

ELSEIFEXP LB000=6

MOVL C00008 V=320.0 DEC=30

ENDIF

.

.

.

INC LB000

INC LB001

ENDWHILE

Example 1: No. SFTON P001 command will make it shift in base frame (default frame).

Example 2: Yes. SFTON P001 UF#(5) will shift the positions according to UF#(5). 100mm in the Y-direction in your example.

The frame that a P-variable has does not matter when using SFTON command. The frame in which the P-variable values are executed is defined in the SFTON command itself. SFTON P001 BF; SFTON P001 RF; SFTON P001 TF; SFTON P001 UF#(5) etc.

The frame of a P-variable is relevant when using MOV instruction with P-variable.

Example MOVL P001 V=100.0 This will make the robot move to the poisition using P001 values in whatever frame P001 is in. So if P001 is UF#(5) and all the values are 0, then it will move to the ORG of UF#(5) and the angles will also be 0 in UF#(5).

Hope you understand. It's not easy to explain as english is not my native language.

You could incorporate the P-shift into the pick-and-place job. You can for example change the position to where the robot is going to stack the blocks. If it's not on a level surface they can make a user frame of the surface so when they change the position of the stack the surface hight will still be correct. Bretty much comes down to how experienced they are. If they have zero experience then I don't think you can add anything to what you already have on the list.

Quote from metalco

We improved the program a lot for example by splitting a 2200 line program in 38 separate ones for each row and then call the next program

Quote from metalco

External Content www.youtube.com

Content embedded from external sources will not be displayed without your consent.

Display all external content

Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

I'd write all that stuff into a loop, use a counter and shift each loop accordingly. In fact if I'd write all my positions out like that I'd have hundreds of thousands of lines and I'd still be programming. Ofcourse I use searches and comarc (I'm a Yaskawa guy) for accuracy.