Ah! You're too fast. I found it as well, buried in the maintenance manual. Odd that no search engines could find it.
I appreciate the answer, and the expediency. Feel free to close this thread if you like.
Posts by WhyDoesMyRobotHateMe
-
-
I am a Masters student...
I'm 99.99999999999999% sure you've thought of this but have you tried appealing to the various developers, telling them that you are a student and that the current situation has really put a stick in your spokes? Somebody will be empathetic, I'm sure.
You could try Octopuz, Cenit (Fastsuite 2), Delfoi, ABB (RobotStudio [Hey, shoot for the moon!]), etc etc etc...
We use Octopuz and I know they've been quite generous with temporary licenses when we've needed an additional seat so if you send them a message it's possible they'd hook you up with a temporary key? Could secure them a lifelong fan, so it's worth asking.
FWIW MotoSim is... probably one of the rougher characters in the business, everything I listed above is like driving a porsche over driving a 1989 Chevy Sundance without a safety compared to the proprietary software, aha. With the exception of having the exact controller there, I can't stress enough how mindblowingly convenient that is for accurate simulation. The UI design though... oof. -
Hi.
We recently replaced the pendant on our DX100, the screen died on the last one, and on the 2nd day of operation, we got a string of the error I mentioned in the title. We managed to clear it by sort of... doing all the basic troubleshooting steps but as its the 2nd day it is concerning so I tried to research the alarm code.
Can't find it, or a record of anyone dealing with it, anywhere online.
Anyone familiar with this? It's a minor, I assume CPU1 is getting sporadic false safety data from the robot or the pendant, but - what good does a general guess do me? Aha. -
I use Octopuz with Motoman. What's up?
-
If you don't have a ticket, they shouldn't have you welding at all tbh - now I know regulations differ but that's pretty dangerous. I've been dealing with a welding robot for almost a year now and just got my ticket, but I've been lucky enough to have a fully experienced welder operating the thing while I just program and troubleshoot.
I'd ask your company for a welder. -
Up in Canada, haven't lost a single working hour. I don't really agree with it as I don't think we're essential.
Pretty much business as usual for me. -
Just to give my opinion: I think that the problem is the welder instead of the robot's moves. Maybe there is something that delays the start of your welding, maybe the cables of the welder are in a strange position around the 9th welding line or the cables have a little damage that is forced during those moves?
Absolutely within the realm of possibility. If the new program doesn't fix it we will start troubleshooting on the welder.
Still though - so strange how it's random and infrequent; you would think with such precise movement it would replicate the fault more consistently. It uses COMARC as well which is completely unecessary for these tiny welds so the fitter making a mistake such that it caused an initial path deviation could be the cause as well. -
The torch isn't moving much, just the external. The torch effectively weaves in place for welds like these while the external does most of the relative point of contact work.
But you may be right. -
Can we see your job header data? From the jbi?
-
I'll be honest with you; probably 50% at the very least - of anomalies I run into are COMARC-related. It doesn't matter if your arc files are perfect, it doesn't matter if it's run it properly 50 times, sometimes when it's doing it's game of catch the current it just seems to go "NOPE" and go freestyle on me.
That's not to say it fails half the time, it definitely works when it works which is more often than not, but sometimes it doesn't. Though it does sound like you've got a fault in the setup for sure, it should lay relatively flawless weaves at least occasionally for you.
I used it a lot when I wasn't as familiar with the robot and its touch sensing capabilities - now that I am though, I prefer to use those in abundance because otherwise using COMARC we have to babysit the thing so it doesn't bork the whole part.
Weirdest bug I've found is that if we're doing a coordinated weld path, when it rotates more than a relative 180° the wave will just, roll like 90° and weave up instead of out. Baffling stuff. -
Are you able to send a backup and cmos?
I could, if you think the problem is in there; but would it be if it's just that literal one job?
Is it possible that the workpiece after the flip is in a wrong position?
It is possible I suppose, but I should note that the welder/operator is rather meticulous and very good at what he does, and we also have a jig/fixture that pretty much ensures that it'll always be in the same spot every time, give or take. I wish I had video of the error, it's surreal how far off it goes.
I apologize for the late response, it's been a bit of a week.
I did some deep diving into the steps themselves and discovered that there was redundant movement between the start of that part of the program and it's respective first weld - it has a lightning-fast MOVL to the part and then a slower approach MOVJ that, for an almost non-discernible amount, the external pulse values change before going back to the proper one. I'm wondering it hits that part of its ladder so fast that maybe sometimes it does this tiny turn, and sometimes does not based on... who even knows, something in the air? Something executed prior in the program?I replaced them with a singular, slower move statement and added a wait statement so it can catch up with itself but we haven't had a batch to test it on yet. So I'll keep you posted.
-
Okay, so...
There's a program on our MA3100/DX100 cell that precedes my employment here, and to my knowledge hasn't been modified whatsoever. It's a basic hinge program, and for reference it's like a 90° angle where the program (which I will attach) welds four brackets along the base plane, then the part is removed and flipped and put back on the positioner to do the welds on the other plane, with a jig that allows absolutely zero chance for the operator (who also hasn't changed, by the by) to place the part on it improperly. Plus, he batches these at like 50 per go so it's not like he would suddenly forget how to do it in that run.
Here's the problem:
So there's 16 main welds in the program, 8 for each plane. We've never had a problem with it until about the new year, at which point our operator noticed that seemingly at random, the 9th weld (which is the first one in the second orientation of the part, the 2nd half of the program) will just, malfunction and attempt to start at an almost 2 inch offset. Nothing changes in the job, it pauses for the flip, he flips it, and resumes welding. It does a quick tac weld for each, which it does fine for this weld, but after the tac when it goes to COMARC the joint it just, starts way off. They're all comarc joints, so that part isn't out of the ordinary, just the haunted weld.
Some other things to note:
- The dude who programmed it no longer works here,
- It has never, ever malfunctioned before
- It is 100% always the same weld
- There is no consistency to when it will happen though the welder says it generally will be either at the beginning of a run or toward the end
- If the first one malfunctions, the rest of the 7 for that half will too by the same amount (there's no SFT instance though)
- No positional or major parameter data has changed on the robot\
- Nobody has proven that robot ghosts aren't real
Some oddities in the program, though. Like there are two questionable external axis command points right before the weld that screws up but the weld start point has the correct one. I'm giving you the original unedited program without the fixes I've tried so that it's not further corrupted by my 'helping.' You'll notice negative values for the comarc amplitude for some of the calls. This, too, baffles me as I'm not a physicist or mathematician and as far as I know for a symmetric waveform you pretty much always deal in absolute values, unless you're working with current which, I don't think applies here? I could be wrong. There's also a P variable defined in the header data which I'd never seen before and could very well be confusing the controller. It gets called in some weird ways, too.
Related followup question: Anybody know if there is a way to look at the code that COMARC uses? I couldn't find it, and my hex reader doesn't like yaskawa's code and doesn't tell me much.
If anyone likes mysteries or ghobots by all means, please check out the code. If you're using a text editor that has a line counter, the error is around the literal line 537, which is commented rather clearly as Weld 9.
Thanks!
-
This is a bit late but if you're working with robot frame the robot shouldn't be moving relative to the table whatsoever, and if you're working with respect to a surface that isn't a static feature of your robot cell, you should be using userframes and teaching a plane on top of the table.
If you are certain that the table is perfectly level with the cell floor, then your robot frame should absolutely be running its edges, and you should re-calibrate your bot.But yeah, do yourself a favor and don't use things that aren't the origin or the robot as a frame of reference for your robot frame. Even if I'm 99.99999999% certain of the consistency of a surface I still re-teach a UFrame before every cycle to be sure the accuracy is on point. You can even automate the teaching process, though you have to stay on top of your organization of where you store your touch data and what you do with it.
-
This is over my head but I just wanted to say how rad this project is.
-
There is not an alarm list that I know of but it can be added by adding an internal alarm read to a register to be passed by Modbus using this guide:
Do you have a particular controller of Yaskawa you are interfacing too?
I think I sort of misread the initial question and got distracted researching the HMI. This is probably your best bet, there is no list available or means to compile it on the controller and the alarms themselves are stored in various memory addresses, or as Yaskawa generally calls them, parameters. I remember seeing an appendix that listed those which if you (OP) would like I can try to track down when I have some time. -
Which model/version of Pro-face are you using?
-
So in case you weren't able to find it on VIPA's website, here is a link to the manual for the HA1-71A41. There are also Movicon manuals available but they are behind a registration wall so I can't link you directly to them.
A communication error, assuming you've got it connected on the hardware side properly suggests there is either a driver or a firmware incompatibility. I've not set up the specific configuration you're doing, but based on a few minutes researching the various manu websites, I've got a couple of questions.
1. Have you run the proprietary startup manager on the VIPA's prepackaged OS?2. In Movicon, you're setting the Yaskawa drivers up for the project, as well as in the DB Realtime settings?
'
3. Is the DX200 even compatible with this setup? Movicon appears to be designed toward PLC synchronization moreso than monitoring what a DX200 is up to. Have you considered using Motoman's HMI software instead?
I apologize, as I'm by no means an expert but as you haven't had any replies yet I thought I'd do a little research and educate myself as well. It does appear as though you can write your own drivers for Movicon relatively intuitively so maybe look into that - if you're getting errors flagged on input then I would confidently infer that it's most likely some sort of driver issue with Movicon. -
Have you tried adding additional movement commands through the corner? That could help; I've had similar joint errors before for doing large rotational axis changes in one move that were corrected by doing 3 smaller fluid ones. Normally this is fixed with a switch from MOVL to MOVJ but I assume your weld is active so that's no good.
I also use OLP to make a lot of my programs and they always end up needing changes like this once I load them onto the bot... It's frustrating. But that's just where simulation is right now, I guess. -
Why SCOMARC? Are you using coordinated motion?
Also COMARC isn't really for finding the seam, it's for staying in it. There are touch macros and such to do those things... Comarc uses the weave motion and for the most part, contact with the part to verify that it's still in the seam... generally by running a sine wave of a frequency and amplitude that you define in a comarc page file, and constant current feedback at the peaks and valleys of the aforementioned wave.
So you've got it working, just not properly? Can we see some of your code? -
Can you be a little more specific? I regularly use comarc on a DX100 so I may be able to answer your questions.
What do you mean "set up"? Like, install the detector hardware to the welder and controller? How to configure it on the pendant? How to use it in a job?
Like, what kind of practical example do you want to see? Applications? Inform? A tutorial?I'm not really sure where to start, lol. Have you read through the docus for comarc on the website? They're pretty thorough.