I believe that there are two separate parameters for that. Inching speed is used when manual feeding from the pendant and DOUT / Pulsing the output from the pendant. For arc ignition, typically you have something called “run in”. If I had a Fronius machine in front of me I would look for you.
Also, make sure your clip job is actually pulsing the feed output and not the retract.
Depending on what Arcset youre ending on, you could be changing weld schedules and have some setting buried in the Fronius messing with your inching speed. Do you go through all your arc files and change the inching speed as needed?
I hate it every every bit as much as OP does. I haven't found a way around it yet.
Are you changing weld schedules during your production?
While that is a setting, that is not the setting I am referring to.
Are you setting the welding parameters from the robot pendant or setting up “jobs” in the power source and calling those jobs from the pendant?
I am referring to the power source. Are you setting your weld files in the power source or the pendant arc start file?
Are you welding in job mode or no?
You’re smarter than I for sure. I’ve never used trig functions in any of my programs lol
Here is my example.
I am curious as to how the flange becomes misaligned in the first place. Is this a feature of the part that happens to not be flat to the ground? If it is always off of flat, could you just compensate in your robot program to align it to a set point every time? Or, does the operator load the part differently every time? These are the questions I generally ask first.
But, from a robot programming standpoint, I would use touch sensing as follows:
1. Level the part where you want it and note the direction you had to spin the part to align it flat.
2. Place the robot on the edge you want to detect when it is "flat" (in your picture, I would use the other side).
3. Write a job to spin the positioner slowly from its original point in the direction it needs to spin to make it flat. Use the search until rapid input on on the detail edit screen of the positioner spin move.
4. When the part "touches" the robot, note the location of the positioner and shift the program by the difference in locations.
It is hard to explain, but I have written jobs in the past to clock a part on a positioner by spinning it into the parked robot in order to "detect" its location.
Another option you could do would be to take measurements at both edges and compare the Z element of the detected position and write a routine to move the positioner different amounts in different directions until the detected Z values are within whatever tolerance you need to call it flat enough.
If I have missed the mark for what you're looking for, please elaborate more.
*GOOGLE TRANSLATE*
Не могли бы вы перечислить дополнительную информацию? Я хочу быть уверен, что понимаю вашу просьбу.
If you want to post the jobs here (master job and all child jobs including the one you need to adjust), I can take a look for you.
Or, save everything off the controller, compress it and attach it here and I can open it in motosim and see how the system functions.
I’ve seen this axis flip phenomenon happen a lot when you take a job that has been written as a standard and then converted to a relative job later on. Generally when you start from the beginning with a relative job, you don’t see this as much.
In addition to setting S2C430 to a 1, I would interlock test start through your job and modify enter on any trouble spots in the correct orientation as you encounter them. Try to avoid movements where the controller could make the decision to spin an axis one way vs the direction you anticipated. I would counter this with an intermediate point as needed to help the controller sort out the orientation throughout the job.
Good luck.
Are you sure youre teaching the macro correctly?
If you only have one robot, I would say that those lines are unnecessary. However, you may have another job somewhere that could force those outputs on. I would confirm that there is no way the controller can ever turn those outputs on before deleting those wait lines out. These things happen when you butcher jobs from other controllers and configurations to make them work elsewhere. Leftover code is generally a byproduct of the above process.
Good luck and you're welcome!
Ok.
As far as I know, this is not a standard touch job that I have ever seen in the USA. The various branches of Yaskawa do their own thing and have their own "standard" for what they do. Based on your job, it looks like those specific outputs are there just to make sure there isn't an active search taking place on R2 or R3 before R1 begins the search routine.
I went back through a old DX100 system backup with touch sensing and I do not see any lines where it would wait for the searching outputs to be off. What is the name of the search macro you are using?
Converts it from whatever frame it was in TO master tool frame. None of the other frame types are dynamic except for master tool. Master tool should have Z going through the faceplate of the external axis and X and Y will change direction if you spin the external axis. This is only necessary if you are doing coordinated touch sensing between a robot and an external axis. The non coordinated touch jobs would not have or care about master tool frame.
What controller do you have? Based on that would tell me what version touch sense jobs you have.
I can and will look up what specific outputs 394 and 395 are responsible for.
As far as the last line, I would venture to guess that this is a robot and station touch job based on MTF. It means convert local position variable 1 to master tool frame and save it in local position variable 1. AFAIK, master tool frame is the frame generated when you calibrate the robot to the external axis.
