If you have the jobs stored in the SD card then you should be able to use it in the new controller without issues as long as the new controller is the same.
Have you checked the contents of this card? I could be wrong, but I'm not sure if the controller SD card saves Robot jobs. It will likely have the up to date CMOS.BIN saved in it if auto-back up has been set up.
Savings robot jobs usually requires manually backing them up.
I'm using DX100 for plasma cutting, whilst it was in the process of cutting it stopped and showed 4110 alarm shock sensor. Did everything I could to remove the alarm through OVERRUN & S.SENSOR but still after releasing and going back to the JOB it pops up again, I really ran out of ideas what to do now. PLEASE ASSIST !!!
Check shock sense cable for damage/ try replacing it.
Install a new torch
Has there been any recent crashes? I had to replace the thru-arm collision mount (ICAT-M3X for YRC1000) after a crash as it was damaged internally and Shock sensor alarm wouldn't clear until this was replaced.
Check the wiring inside the torch, shorts happen there easily as it's a tight space.
Blown fuse can also cause shock sensor to remain active.
No unfortunately I could not figure out a counter-measure for this issue.
We run with YRC1000's and are exclusively arc welding. We have a mix of Relative jobs and Pulse jobs within most robots due to a previous issue causing set positioner values to flip polarity after pressing "Modify -> Enter" during program modifications.
Due to this, I send only Pulse count jobs to some robots, and relative jobs to others that didn't have the issue.
Yes, unfortunately I do run coordinated motion (R1+S1:S1) jobs on all robots. This would definitely make things more complicated.
TAST = Thru Arc Seam tracking.
Sounds like it may not be worth while to make any changes at the moment. If anything, I will start sending Pulse count jobs to every robot.
Hello,
Some of our Robots have never had TCP setup nor any tool weight/gravity information.
I'm not concerned about the Weight and Xg, Yg, Zg data since the robot will just assume worst case scenario for this to avoid internal damage. I will avoid setting this up since this change could change how the robot moves, affecting existing programs, and would traditionally require verification of all programs before continuing in Auto mode. This wouldn't be as big of a concern in automotive, but my cycle times here range from 45 minutes to 5 hours. The programs are very large and there are close to 100 programs in each Robot (High mix- Low Volume environment). Please correct me if I'm wrong here.
I am seeking opinions on whether I should set up TCP on these Robots that have been running programs for a few years now without TCP set up at inception of the cell. So far things run decent as I use TAST and searches. There is usually daily reteaching since parts are fit up a bit differently by each man, parts are cut and formed inconsistently too. No fixturing is used for fitment but this is changing next year.
If I set up TCP, all existing programs will need to be verified fully (this takes easily 4-8hours per program). It's maybe possible to use the PMT function to speed things up here to bring the Robot closer to the mark, but will likely still require re-teaching?
What action would you take in this situation?
Do you have touch sense macros setup already?
Assuming you already utilize touch sense searches - You don't need to do anything different or use a special command when searching curved geometry.
Just set up your touches the same way you do every where else. A two-touch should be sufficient but you can use three touches depending on the part geometry.
So I got declared the guy to wire in a new reamer, now when I fire up the robot for testing I'm immediatly given a low air pressure alarm. Our robot doesn't have one anymore it was apparently bypassed. does anyone know where this would connect inside the robot? The only thing I can think of is I accidentally loosened a wire somewhere. This happens even when the cords are unplugged. I didn't have to mess with any other wires except those on the old reamer. Any ideas where to start?
There should be a flow switch on the back of the robot (usually) unless you've removed this. If you don't have a flow control sensor anymore then you'll need to disable the IO for this sensor within the robot. Or this may be hardwired on the reamer IO board, which means you'll need the reamer board software to make any changes. Binzel may give you or Yaskawa this for free. That's how I got mine.
What is the PSI set to for your reamer?
I use Delfoi for offline programming. I shopped around and had a sales meeting with Octopuz too since they're local here. Unfortunately Octopuz software is behind Delfoi and the pricing isn't attractive enough to make the switch. It could be because I am used to Delfoi but I did not like Octopuz software, but my recommendation is that it's worth switching to Delfoi.
They have good support too.
You can complete calibration offline by recording Robot points with a TCP tool (8-10 is enough), then uploading this program into the OLP software and perform calibration tasks.
I recently calibrated a new fixture myself without calling in support. There will always be some inaccuracies between the CAD model and the real world fixture, this is where searches will come into play to help guide the robot to the correct location.
Cycling the power shouldn't cause any issues.
Do you possibly have a speed override in effect for the positioner? Or a speed override overall, like "speed limit mode".
Are the robots running at the set speed and do they change speed when adjusted?
You will see "speed limit mode" displayed on the banner that displays alarms at the bottom of the screen. It is a Special condition set under Special Run.
If you're trying to load files over FTP, you don't need to look for anything in the pendant except for the network setup and required parameters.
Take the IP address or set one up, and set up a server in FIlezilla and you should be able to send jobs over ethernet.
The image attached shows required parameter settings for FTP.
Have you cycled power to the robot after completing battery replacement? Perhaps check battery connections again and ensure wires are not caught up anywhere.
Have you tried loading backups? The robot may have lost data if it was left off with low battery.
You may need to perform an encoder recovery if the above doesn't work.
Cycling the power shouldn't cause any issues.
Do you possibly have a speed override in effect for the positioner? Or a speed override overall, like "speed limit mode".
Are the robots running at the set speed and do they change speed when adjusted?
If you want to use laser search with the longer torch you'll need a new TCP and a new tool # setup in the pendant so you don't overwrite the current TCP with the original torch.
If it's just a single weld you need done, I would personally have that welded manually, since taking the time to set up the new torch and then switching the torches back and forth as needed will soak up more time than manually welding the single weld line (depending on the size and length of the weld in question).
If you decide to weld it with the longer torch, just use a wire touch instead to save yourself some time. Wire search is more accurate in my experience too since the laser box could get bumped and throw off weld locations when out of alignment.
Hello,
Can anyone provide information on Panasonic Miller G2 GII ARC Sensing Unit YA-1RPSA2?
We use seam tracking but I'm looking for the manual to get a more in-depth understanding of all the tracking functions available with this arc sensor unit.
Having zero luck finding any technical information on this,
Anyone have a Panasonic Miller G2 GII ARC Sensing YA-1RPSA2 manual? Looking for more details on seam track/arc sensor setup.
Typically, teach pendants are designed to work with specific robot controllers from the same manufacturer and series. They may not be directly compatible with controllers from different series or generations due to differences in hardware, software versions, and communication protocols.
You could try anyways, there is no harm hooking up the G3 pendant in the G2 controller as long as the connectors are the same. You'll likely get a message telling you the software version is incorrect.
Check the Cable continuity between ASF02 board and ASU03 unit, IM-YE250/5-80P terminal board.
Also check wiring for good connections for those outputs.
When converting a job the robot simply does the math. If you get the "/OV" at the end of a move instruction it means the robot is trying to move beyond it's limits or Over Value of an axis or movement.
That is correct.
These programs run fine daily when they are in RELATIVE. Technically they should run fine when converted into PULSE too. But for some reason the conversion is flipping the R and T axis way passed soft limits causing the OV errors on most lines.
These are very long jobs with thousands of lines (3-4hr run time) and it would be incredibly tedious to fix these points individually. We have hundreds of jobs too.
Check the connections on these cables/boards as well:
- CPS01KA unit-CN156
- Torque sensor cable between controller robots
- Torque sensor cable which is stored in the robot
Is there a method to avoid or resolve having OV status on move points after converting a RELATIVE job to PULSE? The jobs run fine as Relative jobs without exceeding robot limits.
I've tried this on the pendant and MotoSim, results are the exact same.
Pictures attached.
