Posts by Reintz
-
-
Depends alot on who is your contact. I have given a lot of feedback on the bugs found in MotoSim directly to the guy who gave me MotoSim training. He is in contact with the developers and has always been grateful for the feedback.
And yes, there still are bugs. Never seen that one though.
-
I have only programmed welding robots so I haven't had the need for such a thing and might not know all of the solutions but using different tool files and switching between them comes to mind first.
But if I remember correctly from some other topic, it is you who is already using this solution.
-
Ok. If you post the JOB that you use for the tee type fillet start point detection, then someone can guide you through it.
I think it's the best way to go unless somebody has already made V-groove search JOB and is willing to share it with you.
-
-
As I said I doubt there is a manual on how to do a V-groove search (starting point detection).
You said you have "starting point decention for tee type fillet" and understanding how that works is really all you need to make whatever you want/need out of it.
-
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.
-
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.
-
-
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.