Posts by WhyDoesMyRobotHateMe

I'm sure you've done this, but - run another job generated by the software (ideally one you know works), and run a job programmed on the bot exclusively. That should tell you where the problem seems to be.

If it's the software, check the frame your jbi code says you're working in on the robot and make sure it's where you want it to be; if it's a userframe, try re-teaching it. If it's a robot or base frame, recalibrate the manipulator and see if that helps.

If it's the software (believe me, I know what that can be like) and it's under a license, your only "legitimate" fix is to get ahold of support and be at their mercy. That said, if they're not helping enough and you're comfortable fiddling around in the language that the libraries its using are in, then the sky is the limit.

But it could just be a setting in the software's configuration somewhere, so first, go over all your settings and make sure everything is aligned with your cell - that's the main drawback to OLP; if the robot cell and your virtual cell are out of phase even slightly, then... yeah.

If you are using COMARC at all for your welds, let me know - COMARC drastically deviating was a major problem for us but we solved it; I won't waste anyone's time explaining that though unless it applies to this situation. Let me know.

Quote from Landqvisttim

*Sigh* had like 3 hours of troubleshooting yesterday, thinking it was something with IF.

That's coding in a nutshell for ya.

You're welcome. I'm just glad it worked for you.

Try putting an empty line below END and saving it. Seriously.

Also, regarding your L:0087 error; one thing I've found is that the line it gives you when you're working directly with INFORM code in notepad regarding an error is almost always incorrect. One reason is because it doesn't count job header data, as well as some other lines of code when it's parsing line count. The count doesn't begin until the NOP statement, and I believe that's line 0.

For instance, NOP is on line 19; if we account for that being 0, and subtract 20 from your total line count, which is 108 - we get 88. Which would be the line after your END.

Hopefully this solves your problem, and I don't know why that empty line has to be there.

Hey, sorry for the delay. So the hours on the robot are quite low, somewhere in between 1000-2000 hours of operation - but the robot itself is a bit older, 2015 it was purchased.

No, the harness had never been changed, or advised to be by Motoman. And for all intents and purposes, the rest of the components appear to be in relatively good shape - I think it must've just caught a burr or something inside the arm, or maybe a bad curve, and subsequently developed a rub that is borderline unheard of in its rarity and that's sort of how it went down.

Hey, so, not really looking for troubleshooting as we've fixed the problem but I thought maybe a brief summary of our symptoms/issue could help someone else should they come across this and we all know how helpful it can be to find the same problem you're having in a place like this, so here it is:

Basically, we were getting arithmetic errors on our external encoder, sporadically, for a while. Whatever, reset and continue on with the welding; until, a few weeks back we get a 4107 Major - that's basically an encoder's position not lining up with where the controller says it should be.

The first reboot of the controller cleared it, but after that we effectively are locked out of the machine. Upon inspection of the inside of the controller, the PWM power feed cable was... for lack of a better word, *scorched*. The weaved casing is melted and just, gnarly-looking in general. But everything else was... perfectly fine? Very strange.

I'll save you the myriad things that we did to diagnose the issue but as it turned out - the cable that ran inside of the manipulator arm, well, it's harness had a rub-point that over time, I guess, wore itself right raw to the live wire inside, which subsequently made contact with the arm itself, which I guess meant that an absurd surge of power connected with the arm, which ran down the ground, which was connected to the external rotary positioner, which decided that its best route of travel was through its encoder and into the aforementioned scorched cable.

Wow. Like, so what caught our attention was a nickel-sized perfect circle on the arm that was missing paint that was so perfectly formed that it was a spot that I guess on initial inspection we just, always thought was part of the paint job. That's where the short happened, and the wire welded itself to the manipulator on the inside at that position.

Right, so, a service call, a new encoder, a bunch of housing/harness and a PWM cable later, the problem is remedied and we wait for the next one. But if you find yourself with confusingly-nuked cable housing and encoder errors on an external axis, there is a reasonable yet tiny chance that your robot has welded itself... to itself.

Quote from HawkME

A good programmer will not put into production copied code without fully understanding how it works.

Oh I agree, using code you don't understand is one thing for sure - but after working as a dev for a few years, hell - it's just a better use of a coder's time to not fiddle with an algorithm that is already on github and (obviously) open source. That's why its integrated into Visual Studio nowadays.

And realistically its the only way to learn more as well.

Programming a robot is different, jobs are different, robots are different from each other, so yeah - to just steal a program and run it is reckless and stupid. My original point was just responding to the comment that programmers don't copy and paste.

I like writing code, that's why I got into coding - but there are elements of it that I don't enjoy and am not adept at - so my ethos is code whenever I can otherwise find someone offering it who already did it better than I ever could.

Quote from kwakisaki

Copy and pasting, and editing existing code does not make you a programmer either.

Are you joking? That's like 70% of professional software development - why would you re-write something if it already exists and is offered open-source and working?

Good afternoon.

So, like many shops we use offline programming software to quickly create weld paths for the myriad parts that come through here - custom work, revisions, it's always changing. If you've had the pleasure (ahem) of posting code with an OLP solution, then you're more than likely familiar with the process of getting the code to work on a Motoman unit. It's a huge timesaver, of that there is no question - but, if you're not dealing with alignment issues or crashes, then you're dealing with code output that won't even load on the controller due to various errors - the most common in my experience being 3220, of which its most common subcode generally tends to be [58]. Syntax. Okay, fine, easy enough to fix - but the problem line it gives you is based on what the pendant displays, not what your code editor displays. And even when you think you've figured out what it skips and what it doesn't, sometimes it makes you want to pull out any remaining hair when you spend an hour searching and come up with squat.

MotoSim, as an OLP, is rather lacking - but what it does do better than anything else is emulate your robot. So - how does this help you debug faster?

JobPad! Alright, so - just like the controller (as it basically... is reading what it thinks is the controller) you can't outright open a job in it that isn't on there already. However, you can start a new job with a similar control group, paste your problem job code in as if its a program you just made and subsequently click the check button, and...

Voila! Now, you're gonna see a ton of 3190[4]s because you don't put your command positions in (your C000xxx and EC000xxx values), just your instruction data. So ignore those. But woven between all of those, hey! The same error that the controller and the virtual controller were giving you, with the same wrong line number except that now you can double click that error in the log and it highlights the problem within the code.

Wow. Do note, that in order for your pasted code to populate JobPad properly you must first click the 'full mode' box, and then click the 'Show Log' box so that you can see all the errors. Then, you can correct them and paste it all back into your jbi file.

This may be common knowledge, but if it is - I have not come across it. I do however wish I had known this last year, as it would've saved me so much tedious "is it this?" work and countless cycles of edit, save, load, note error, revert edit, find new possible problem, repeat that can just drain your day dry.

Have a good day!

Your post isn't factual, friend. First

Quote

In the United States we've had < 200,000 so-called covid deaths in a country of ~350 million people (which is right on par with an average or above average flu season)

This is a dangerous statement far too many people won't stop making. At risk of cliche, you're doing the apples and oranges thing. If the number is similar, that's irrelevant - flu season's comin' and going as per usual, as well as the people that die of covid. It's an AND, not an OR.

Quote from Rekd

And just last weekend the CDC quietly revised it's statistics for deaths here in the US. They finally told the truth about how many are actually dying from JUST covid, and the number is LESS than 10,000. (6% of their total original number). The other 94% of so-called covid deaths had an average of 2.5 major pre-existing conditions when they "died of covid".

So in reality the odds of a healthy person dying from covid are around 0.0003%. You have a better chance of dying from sunstroke, bee stings, or being hit by a bicycle than this faux virus.

I presume this is the data you're referring to.

Look, from the outset what have all the major health organizations been saying to us - it is the vulnerable that will be the most at risk - healthy people never were, the whole point of all of the precautions was so that they wouldn't have to die. Yes, it is important to note that the vast majority of fatal COVID diagnoses had underlying conditions ahead of time but this was one of the first things that we knew. To suggest that they were going to die anyway is validation for removing their punishment for our negligence is disrespecting their memory

You keep using portmanteau terms like plandemic as if this is some New World Order stuff, that we're being decimated on purpose, that they want our businesses and livelihoods to fail - to what end? You're not alone in this, much like the anti-vaccination crowd, or the flat earth society, or countless other tragically popular scientifically damaging trends but the bottom line is that it can kill people, it does kill people and it will continue to do so unless we do something to stop it.

If you've been lucky enough to not have lost someone you thought you had substantial time to cherish with remaining then I'm happy for you, and you should be too. But this attitude is a direct affront to the exponentially bigger number of people than the "died with, but not of" COVID statistic. Keep believing what you want but don't spread this poison around, if nothing else for the people that are still hiding away from their loved ones because they don't want to die.

We had the same issue on a DX100/MA3100 setup - I couldn't find an exact fix for it but the cause was a particular robot 'posture change' during a weave; for whatever reason that sine wave as well as the robot's B movement was causing it to fire a collision detection error; I changed the way the robot was postured for the weld and it stopped happening.

Is there a weave where you're getting the error?

Could you show us a snippet of your code? Inform is super finicky about everything.

Quote from TheFabricator

I think its a long stretch to say its dangerous to have him welding without a ticket. I am a trade qualified boilermaker but I have employed plenty of guys who can "just" weld. Once I teach them the basics they can produce "safe" welds in a couple of hours. Is it ideal - No but thats the real world. Will they kill anyone - again No because the weld I have them do are not critical.

Depends on where they're located I guess - here, if you're welding production parts and you don't have your ticket or are not a registered apprentice? You'll get fired, for one; your employer will get fined severely, and the college of trades could suspend your ability to write your ticket for however long.

You say once you teach them the basics they're good to go - have you seen a program go *really* wrong? Or how a new robotic operator can panic when they do? There are safeguards in place, sure - and I do think the likelihood of someone dying is low but the point of the ticket is to eliminate the possibility of anyone getting harmed, period - not to mention depending on what the parts are, their integrity could be an issue as well.

My point wasn't really safety-related, moreso that if they aren't being trained whatsoever and yet expected to just 'learn on-the-job' then their employer is failing them.

Hey.

MA3100 with an external rotary and a DX100. So let's say I have three parts set up in line on a beam, and these parts are basically snow-shovels with walls, and I'm welding the inside of these walls to the snow shovel lookin' part using coordinated motion, and the profile is ridiiiiiiiiiiculously convoluted so perfecting even just one side took several hours.

Okay, so - parallel shifting the other two iterations of that side? No problem. But when I try to teach a UFrame so as to reflect the weld in the middle on the XZ plane, the result I get basically projects the new weld 90° toward the robot, instead of 180° with a horizontal flip like I want.

If the rotary is positioned -X, +Y from the robot (the program is in RF) does it matter HOW the reflecting Uframe is taught aside from the XZ plane being in the proper place? I haven't had a chance to test much today but I taught my origin->X (XX vector) basically in a straight -Y line relative to the RF, and my XY as basically a straight -X line relative to the RF but the reflecting plane (XZ) should still be smack dab in the middle of the part as a perpendicular wall....

So I'm confused. I'm sure my description has confused anyone who has read it but if you have any insight I'd appreciate it.

Quote from rohbhot

Hello Emre,

Can you please explain in terms of commands as to how you solved your problem.

Hey. Not OP but it's been a week and I thought I'd try to answer your question in case you still needed to know - for starters, if you want to read up in depth on MFRAME, it's in the Relative Job Function manual on motoman's documentation page.

Anyway it works like MSHIFT, if you're familiar with that - where MSHIFT teaches an amount for shifting to a (usually P) variable while a program runs, MFRAME creates/modifies a UF#() frame while a program runs. In INFORM, it looks like this:

MFRAME UF#(n) P001 P002 P003

Where n is the frame you're modifying, and P001, P002, P003 are the Origin, XX, and XY positions you want to use for the frame respectively.

As far as I know, there is no way to pull specific coordinates used to teach UF vectors - if there were, you could write a simple job to GETE from it, add your shift amount and then SETE right back in. Shifting one or two frames, the simplest way would be to just FWD jog to the taught points and move your shift amount and re-teach them. But if you need to shift a ton, you could write a FOR/NEXT loop that calls a job in each user frame and uses its origin and ADD/SUB, maybe?

So like (on the pendant) it might look like:

_{NOP
FOR I000 = 1 to 15}

_{CALL JOB: SHIFTFRAME UF#(I000)}

_{NEXT I000}

_END

And so since SHIFTFRAME will be in the UF being changed, we should be able to zero it out and then add the shift value, so like, lets say you wanted to shift all the frames by x=50 and z = 190, well:
_NOP

_{GETS PX001 $PX001}

_{SUB P001 P001}

_{SET P002 P001}

_{ADD P002 (1) 100 //Because this is our XX point}

_{SET P003 P001}

_{ADD P003 (2) 100}

_{ADD P003 (3) 100 //We move it on Y and Z because this point sets our plane slope}

_{//This next bit changes based on your shift. In the (), 1, 2, and 3 respectively represent X, Y, and Z. Since we are setting vectors, 4, 5, and 6 (Rx, Ry, Rz) don't matter.}

_{ADD P001 (1) 50}

_{//The above statement would set P001 to be x +50, you could do multiple elements for your shift, like:}

_{ADD P001 (3) 190}

_{//Then repeat it for the others}

_{ADD P002 (1) 50
ADD P002 (3) 190}

_{ADD P003 (1) 50
ADD P003 (3) 190}

_{//Then you would do your MFRAME}

_{MFRAME UF#(I000) P001 P002 P003}

_END

Whew. So - full disclosure, I just came up with that on the fly so it hasn't been tested whatsoever and there are no doubt errors (for instance I think some CNVRTs might have to turn the system vars from pulse to cartesian and also I'm not certain if ADD can call elements like that or if its adding in absolute or relative numbers. That being said, this is one concept, debugged and tested of course, of no doubt many, where you could shift 15 frames by running that parent job once.

Hope that helps.

Absolutely, there are digital I/O functions built-in that would make that incredibly straightforward to achieve - on ours, we integrated a subroutine into the touch sense process that checks for that and automatically feeds wire before checking again and moving ahead.

I have zero electrical experience so I've never hardwired anything but I did the accelerated training in Mississauga and they had a lightbox wired to the controller that used basic I/O so if you know how to not get zapped or fry things with wires you should be good.

I was about to ask something similar; where would I find the information for that? Apparently our robot had it installed, but I can't find the setting anywhere - I can't find anything by that name on our DX100 indicating which user coordinates would be used for it, so odds are I've overwritten the darn things.

Hey.

Running into issues when trying to weld around a cylinder-type part. Using coordinated motion, normally I can weld any which way on any surface with all 6 + 1 axes moving around. However, what should be (to the robot) a simple straight line around a cylinder becomes all sorts of trouble when adding a weave into the mix; thinking back to when trigonometry was a regular part of my day-to-day life I'm thinking asking the torch to perform a sine function without any motion on the torch itself could be the issue (having no forward motion is not unlike having a tangent of 0, which i suppose could result in an undefined solution to a sine wave) - though I sort of thought the controller would handle the external axis in such a way that it would consider turning that as the value for the wavelength. Without a weave, no problem; adding in SWVON and it's almost random what it does with it. SCOMARC is almost out of the question as it takes the random and applies it to the weld path.

Our OLP attempts to correct this by making the torch move slightly during the weld but it really negatively impacts the weld path, and on the pendant I can move the torch but even minor changes can mess with a 1mm amplitude on a precision weld.

Anyone come across this issue? Is there a solution I'm not seeing? In a nutshell I just want the torch to stay put and oscillate like an ECG needle while the rotary does all the work.

Oh, DX100/MA3100 setup with Miller, fwiw

Quote from Stanley1012

Guys thanks for the advice. The problem here is not the final customer but the contractor however, here is my plan to ensure i get paid.

-- Change the Management mode password.

-- Disable job edit function while enabling the modification of position data.

--Hand over factory delivered CMOS and setting files as back on job completion.

As i know for a fact the final customer could like to add another variant to their production line, this mild changes brings no one in harms way but ensures the project stops and questions asked when big changes are needed.

I don't know what country you live in so obviously business/corporate/industry/criminal codes vary wildly, but there are few common (albeit sometimes named or worded differently) laws and statutes you should probably be aware of:

- You do not own the robot, you own your intellectual property: that is, your program. And that too, is dependent on what your contract looked like when you signed it. What this means is anything you do to their equipment or existing IP assets (their programs, their CMOS, etc etc) is considered very much the same as you tampering with their pipes, wiring or roof. Property damage, sabotage, extortion, anti-trust; these are all terms you could see on a subpoena with your name on it.

-Your property, as a digital asset, is only yours as much as you can prove it is. If you aren't already, you should be having the people who hire you sign a document drafted by a legal professional outlining the scope of what services and products are yours, the limited liability of said products, and conditions for default or renege. if the contract you signed hasn't been met by the contractor, but you have no way of proving you wrote what you did, they could very easily just claim it as their own. And they will have no trouble proving that you did anything to their existing infrastructure, trust me.

- The best vengeance you can take is being honest with your industry peers and clients. If these people don't pay, make sure everyone knows they don't pay. It doesn't take long for a crap company to sink with a bad reputation.

Even if your plan goes full best case scenario; it's rife with opportunity for a company like that to trap you and even pin worse charges on you. Don't do it.

Quote from Noob1982

I've been ok with Motosim. I have completed two projects now through the simulator and dumped them into the robot when it arrived and only had to touch up a couple points. Not sure about the other software out there but I've been able to completely manipulate the ladder and dump it in and it works great.

Honestly, that's its strong suit amongst what I've tried. You're using a 1:1 virtual representation of the controller itself, so generally anything that works on your simulation will work on your IRL cell - hell, I haven't been able to try it yet but I guess you can even connect your controller to MotoSim via your network and not just monitor but send a shortlist of commands to it and run jobs. No other OLP is going to be able to do that with a Motoman robot without breaking a few license agreements, at least not for a while.

My biggest and only gripe with it is the UI. Some of the decisions made, simple things like moving your PoV around just seem to purposely be against every industry standard, go backwards, have baffling settings (why would I ever need a manual control wobble view for programming?) and make it feel like a fight to use, when other OLPs are borderline fun to utilize.

Building a cell is a pain, too - again mostly because of the interface. Documentation and tooltips are borderline nonexistent. But, what I CAN do is load the .jbl i'm working on and modify it in real time and see with virtually perfect precision what will happen out on the floor. The value of that almost outweighs any of the perks that the aftermarket OLPs offer.

Okay so, an update - now we're not getting an error code but as of this morning the robot doesn't really want to keep its servos on in play mode. With fiddling it'll eventually run a job but if you stop it it won't fire.

I've looked for any externals blocking the light curtain beams, all the doors, etc etc.


They'll turn on in teach (understandibly with the safety settings being moot) but just sporadically wont work in play.

Not sure what to try.