Hey, thanks for your answer.
Funny thing is, I think i'll go toward Motosim after a demo they showed us. So calibration will be part of the process anyways!
Heya, No worries! Glad to be of any and all help if possible 
Ooh, Colour me interested, I'll definitely have to have a look into Motosim!
Hi, I've been doing some research between a few OLP softwares and also came across RobotMaster.
I was wondering if Yaskawa is supposed to come and calibrate your cell before RobotMaster does his thing?
I've been told no from RobotMaster but i'm a bit skeptical about that point.
Hey mate,
I think that depends primarily on the condition of your robot. When we supplied the backups of our Motoman robots to Robotmaster to calibrate and generate the robot/robot cell they could see our mastering issues within the back up itself.
I'd suggest staying in close contact with whoever you are dealing with during the creation of your cell design within RobotMaster and if they suggest getting someone out to calibrate the robot to minimise the inaccuracies I highly suggest going through with their suggestion just from my personal experience as I am currently living the nightmare of having to OLP with inaccurate Robots and management refuse to try and fix the issue.
All-in-all I think RobotMaster is a fantastic program is utilised correctly.
Hope that helps, mate.
I think you are going to have to do touchups. Any software used will be garbage in, garbage out. Two issues going on the tcp calculations are based off the mechanical home position calibration data. If the calibration data is messed up trying to teach a tcp will be messed up.
If you have Yaskawa come in and "master" your robots, try to get them to use MotoCal not MotoCalV. MotoCal is the DynaCal software (least was 15 years ago) but with the ability to calculate link lengths. DynaCal will only get new abso data. MotoCal will get new abso data and link lengths. I don't know if Yaskawa does MotoCal any more since MotoCalV was released. Neither one will compensate for a 20 year old drive with wear and tear.
I always knew I'd have to do touch ups, but I just wish I could minimise the amount. At the current moment on one of the robots, if I do a curve movement, it pulls the cut bit out as it rotates. I've had to split tool paths off line and sometimes even move tool paths 15-20mm to get them within tolerance. Our RobotMaster technician has tried his best to even out the errors to make it as accurate as possible but it just feels due to these issues we can utilise the OLP to it's full potential which is frustrating to say the least.
I'll definitely keep MotoCal in mind during my next meeting when I push for updates to the robots. I had a suspicion that using modern software with 20+ year old drivers could be a big issue but our management team have the mindset of "We'll deal with that issue when it arises" and even then they refuse to update to newer or even second-hand newer Robots which i can only imagine would benefit the business in the long run.
I think that is a very good and important point there. Like, even if it was mastered well, what you might be seeing as your issue is wear. Or, at least, part of it.
I had a suspicion that would be the case. Every time I bring up wear, our maintenance manager shuts that idea down immediately stating their 6 monthly maintenance prevents that from occurring but the evidence speaks to the contrary.
Thank you everyone for all of your help and support, It is always greatly appreciated!
Just curious what your industry is? In my experience, every time I've received programs which were written off-line, usually designed with motosim, they always required at least one touch up pass ie: they aren't perfect.
Also after zeroing out any axis, I usually end up touching up every critical position. I'm not sure if there's a way to avoid this after you re-master a robot. I think there is some kind of sensor based system that records before and after TCP positions and offsets things accordingly, but how well these work in reality I don't know. Is it a big deal just to touch the programs up? Not sure about your facility/industry and how things operate there. I'm sure someone here will have some better answers for you.
I work in automotive and our robots are primarily milling robots working with plastics.
I mean, I expect some form of touch ups (nothing is perfect, I understand that) but due to the nature of the issues it's a lot more than what I'd think is reasonably acceptable. Especially when I've seen the finished results of programs designed off RobotMaster (our installer uses it in his own private business) and he doesn't have half the issues we face. Management see the downtime of touching up every program due to remastering (even on the robot cells that don't get touched for weeks at a time) as a waste of time and money which i can understand but biting that bullet would make things a lot easier for offline in the future.
I can get the programs done Offline but depending on what robot cell I'm using to get the job done, it'd honestly be quicker to online program most jobs.
Also probably doesn't help that the Robots we are using are 20ish years old.
Heya Everyone!
Hope everyone reading this is happy and healthy!
I have a question although I suspect the answer is a definite "No".
We have implemented an Offline programming software called RobotMaster to work with our Motoman XRC Robots without having to shut down the robotic cells to program new jobs. We've come across unique issues with our robots in their setup which have largely gone unnoticed due to online programming being unaware of the issues.
We've noticed across all our robots that a combination of the TCP and Axes values are out, sometimes rather dramatically. I've been trying to convince management to get Yaskawa technicians in to Remaster and align the axes professionally which will only benefit our offline programming capabilities (as far as I am current aware) but they are concerned that as soon as we do that all of the currently programmed jobs on that robot will be professionally out.
Every robot we have sent off to have the cell designed within RobotMaster we've been told its has mastering issues. We are refining the TCP values offline but that can only get us so far without having to face the elephant in the room: The Robot mastering.
Out of curiosity, Is there a program or something we can run that will prevent us from having to reprogram all the current jobs on our robots once its remastered? We currently use a program called DynaCal I believe to assist in the transition of programs jumping between robot cells.
I suspect that if we update the settings in DynaCal we can simply just "convert" the programs to the new values to minimise the amount of work that will be required if we do remaster the Robots professionally but every time I question this way of going about it I'm simply told no without any real explanation from our lead programmer.
any and all help would be appreciated.
Robot Type: Motoman XRC UP50
Controller Type: JZNC-XPPO2B
Controller Cable Type: RS232C
I don't know if the above information is helpful but I figured I'd throw it in to assist in anyway shape or form.
Thanks Everyone!
Heya all,
Hope this thread finds you all happy and healthy!
Just a quick question, but before that here are my robot details: using an Motoman XRC, this robot is primarily used to quality test Product Development goods (hinge tests etc).
I've been asked to write a program that loops on itself for a period of time. I have never done this in any of my programming experience.
I've been getting confused at work as the people I asked have given me multiple ways of accomplishing the task but without an in-depth explanation. "Just use labels" was one direction I was given, I've never used labels prior to this either.
This is what I have so far from some research online:
"NOP
SHKST <1>
<SPEED SETTINGS>
TOOLON
*LOOP
MOVJ
MOVL
MOVL
MOVJ
*JUMP LOOP IF PULSE OT#1 T=60
MOVJ
TOOLOFF
MOVJ"
So, from my VERY basic understanding of this is that the motoman will complete the program and loop the program for 60 seconds correct then go home and turn the tool off?
Thank you guys for any and all the support I might get for this. 
Good Morning/Afternoon all,
hope this message finds you all in good spirits and healthy during these trying times.
Just a quick question, I can't find anything that references the decimal data brought up in this alarm in any of our Yaskawa Motoman manuals onsite or online.
We are using a UP50 XRC Motoman if this helps as well as Robotmaster V7 for our offline programming.
Essentially what's happening is: I was trialing a new offline program for a Robot we just set up (I believe it is using C-Var code due to having problems with P-Var code). The first 3 MovJ's worked fine and looked super nice. However in both programs (we run a side 1 and side 2 program where the robot travels a rail) once it reached the fourth MovJ movement, an alarm popped up.
The Alarm is as follows:
"ALARM 4404
ARITHMETIC ERROR
[7]
Occur times: 1"
I know what Alarm 4404 is, it's described as "The controller error in the path operation process" but I can't find ANY information referring to the decimal data of [7]. Everything I find references Decimal Data 8 through to 10 but nothing prior.
Any help will be greatly appreciated.
Thank you all kindly and be safe out there
FDE for Windows that RoboDoc is talking about is a Yaskawa product. Sold only by them.
Ahh Thank you 95Devils! Looking on Yaskawa websites now for anything but coming up short - Have emailed their customer service department for assistance
Thank you kindly!
You can buy FDE for Windows that you install on a PC and plug into the RS232 connector in the pendant. You can do the same backups or load the same files from the PC and if you need to plug your CF card into the PC.
Heya Robodoc!
Thank you for your help, is there any chance you can link me to a site that sells FDE? I've looked around and can't seem to find any websites selling it.
I have found a bunch of free ones selling Floppy Disk Emulators but thats about it. I just don't wanna install bad software onto my work computer lol.
This is one I found:
https://www.itsupportguides.com/knowledge-base…drive-emulator/
Not exactly sure if that is correct or not 
Thank you once again!
Hi Gilldur,
I just realised I gave you strictly the Robot model of the Cabinet and not the robot themselves.
Both of our water jet robots read this:
Type: IRB4400 M2000
Robotversion: IRB4400L/10 Type A
I hope that was the info you were asking for mate
Apologies, bud.
What robot modell are you using? Who made the system?
There could be a number of things causing this. I am guessing you are using the industry standard with some hanging robots, probably 1600/2400/2600. If that is the case then you should be able to go way faster then what you are right now. I normally cut with 400-600mm/s in waterjet applications.
Its been like 20 years since i programmed motoman robots but i seem to remember them handling zones way different then ABB. I guess your cutting something other then carpets since your are using such small zones. There is a behavior in the robot when using such small zones that will cause the robot to slow down in each transition from L to C and vice versa. This will happen if you are using small zones and there is some kind of reorientation in the movement. You can get around this by making your own zonedata and increase the oriantation zone.
CodeCONST zonedata z0:=[FALSE,0.3,0.3,0.3,0.03,0.3,0.03]; CONST zonedata z1:=[FALSE,1,1,1,0.1,1,0.1]; CONST zonedata zone0:=[FALSE,0.3,20,0.3,0.03,0.3,0.03]; CONST zonedata zone1:=[FALSE,1,20,1,0.1,1,0.1];I assume you know this but i am going to say it anyway just in case. The first two entrys in your speed data are linear speed and orientation speed for the robot the second two are for external axis. The orientation only applies when you re orientate the tool and the value is degrees per second. Now if you are using the small robots 16/24/26 then you should not have to go below 120°/s. If you need to go lower then that the problem is usually something else in the system.
There are a lot of things you can change in the system to go faster with perfect quality. Some things are complicated and some are hard. I would recommend trying a lower acceleration and see if you can get the speed up.Code! On PathAccLim TRUE\AccMax:=2,TRUE\DecelMax:=2; !Off PathAccLim FALSE,FALSE;You can play around with accelerations, valied values are 0.1 to 20 and the value is meter/second².
You can take a look at a software from ABB called TuneMaster it is free and can be downloaded from ABB's web page. It can be used to tune foundations stiffness and resonance depending on robot modell and robotware version. This tool will usually help the 1600 and 2600 a lot.
Hi Gilldur!
The robots I am using are ABB S4CPLUS M2000 (on the metal tag on the cabinet)
No, the two robots aren't hanging. They both just sit parallel to the working table. we have one Robot a Motoman that is hanging inverted but that is for milling purposes. I was aiming for around those speed settings you are currently using but due to this problem I've been having I am hesitant to increase the speed to that level.
From my (very basic) understanding, Motoman uses position levels whereas ABB uses zones. So a motoman position level = 0 should act the same as an ABB fine zone? They both force the robot to go to those coordinates, brief stop then continue?
Is that section of Code what you would use to widen the orientation zones within the zonedata? I apologise for the stupid questions, a lot of robotics is still a mystery to me as 9 out of 10 times im forced to learn from my mistakes instead of my superiors (I don't have a whole lot of support).
Yeah, I was sort of aware of that but not to the degree you explain. I am fortunate enough to have a Maintenance supervisor who actually worked for ABB and has a fair amount of experience (although he admits alot of it is forgotten by now) and he told me to only edit the first two values in speeddata and ignore the last two (the one you explained controls the ext-axis, the two robots aren't on any rails so they can't move on it).
I'll have to have a look into Robotware and Tunemaster etc for the ABB's. The only software regarding Robotics im used to is an Offline Programming software called Robotmaster V7.
Thank you so much for your help, Gilldur!
Hi Guys,
Got a question for your more than capable minds 
So I am the lead programmer for Offline Programming and Our Water Jet systems (I dont have alot of experience in robotics so im as surprised as you are).
The issue I am having is the ABB's we are using (A master and slave system that relies on case files to call the correct jobs) seems to hate the transition from linear to curve.
Everytime there is the transition, the robot arm itself shakes alittle and due to the nature of water jet cutting, that shake can be clearly seem on our cut lines.
I've managed to smooth them out as best I could by pulling some points out - I figured distance was a factor that could be contributing to this issue but the issue has remained constant over the last handful of jobs we have trialed on this cell.
Originally I had the speed settings for to "100, 100, 50, 50" and slowed it down to "60, 60, 50, 50" and it improved it.
Originally, I was told to have the linear speed settings at "150, 150, 50, 50" and the curve speed was "100, 100, 50, 50" but after arguing the point I managed to convince them to allow me to slow the robots down. So, what I ended up doing was using the one universal speed setting across all movements which is: "60, 60, 50, 50"
Another thing I have noticed is that even though im specifying my zones are Z0 or Z1 the robots are briefly stopping at these points and moving on, which I assumed only happened with "fine" zones which I assumed acted the same as the "Motoman Pos level = 0" function.
I apologise if I have confused anyone with my explanation.
Thank you all for any and all help
Heya all!
Just a quick question, I work with primarily Motoman XRC robots in a milling fashion. Our electricians on our maintenance crew have been researching how to extend the card reader inbuilt into the Motoman cabinet so us programmers dont have to require an electrician to come down and open the cabinet so the robotic programmers can have them insert the card and upload a .jbi file (we recently got a hold of some fantastic Offline Programmer software which requires us to be constantly uploading .jbi files through the inbuilt card reader). We are sort of coming up dry, the closest an electrician found is an extender that extends the connection by about 150mm but we can't find anything longer.
Was just wondering if others have had similar issues and have found a way around it.
any and all help will be greatly appreciated, thank you.
Heya everyone!
I recently got promoted from a machine operator working with comau, ABB and motoman robots to a robotic programmer position. Im beyond excited to get my hands dirty in all the knowledge I need to soak up. My problem is, The guy who is meant to be training me doesnt really want to do that. Gives me a 5 minute crash course in what he wanrs then disappears and im thrown on production assistance for days at a time but expected to have all the knowledge as if i've been working with robots that whole time. Im pretty much just introducing myself and asking politely for any help If I post a thread.
I've got the bare bone basics of movements etc but when i asked about speeds cause we cut plastic primarily, I was simply told "you will figure it out as you go.". So my first of many questions this, I've scoured my manuals for the info and unless im blind or dont have the right manual i cant find it. What is the ratio of speed to distance when it comes to V, VR, VJ and VE etc? So is like VR=25.00 25mm p/s? I apologise for sounding stupid but like I said, I've had very minimum direction being given to me and I am beyond determined not to let this opportunity slip through my fingers cause my teacher doesnt want to train me.
Also, because how stupid i sound in that post i dont blame anyone for not replying
