Posts by TomFoolious

1: J P[1:ZERO] 100% FINE
2: J P[2:APPR] 100% FINE
3:
4:L P[3:WELD PT] 100mm/sec FINE
5:
6:LBL[1]
7:PR[1]=P[3:WELD PT]
8:PR[GP1:2,1]=P[3:WELD PT]
9:
10:PR[GP4:2,1]=PR[GP:1,1]+170
11:
12:L PR[1] 250mm/sec FINE
Weld Start E1[1,1]
13:L PR[2] WELD SPEED FINE
Weld End E1[1,1] CTV0
14:
15:PR[1]=LPOS
16:L PR[1] 250mm/sec FINE Tool_Offset,PR[10] //Retreat Position
17:
18:JMP LBL[1]

So, I'm starting at a point, then adding 170 onto the weld end every iteration. DOesn't matter what increment I put in here, the Positioner won't turn as long as I have a CTV0 motion instruction on the Weld End. If I change CTV0 to CTV1, then the positioner will rotate, but the robot will move on up to line 16 and start retreating from the weld while the positioner is spinning. Changing the CTV value from 1 - 100 will vary the point at which the Robot will move on to line 16. The manual reads that CTV should be set to 0 for Continuous Turn to be set active. I only tried values other than 0 to see if I could get the positioner to spin. Sure the positioner spins, but I can't have the robot retreat from the weld before it has welded 360 + overlap.

I gathered the information I have from the V9.40 ArcTool manual. V9.30 has the info too. Under Advanced Functions -> Continuous Turn Option. That has the info for CALIBNBT and CN_CTS KAREL programs.

When I have Continuous Turn Frames enabled, the Positioner's degrees do rotate up to 180 or -180 degrees. After 180° in either direction, the degrees flips the sign.

I've tried toying with that, setting up a move that only goes to 170° then trying to increment or go to another position that is another 170° away. Still, no positioner rotation happens when I run the program.

Anyone have experience with the option in the title? I've talked to our Sales Rep about it, asked tech support about this option, no solid help yet on figuring this out. We have this setup that customer wants changed to improve cycle times: Robot welds around a pipe 360° + Overlap without having to "rewind" the axis (because of axis limits). We want to find a solution where we can continuously turn. When I try to use the CN_CTS KAREL program with trying various pitch arguments and then having the CTV0 motion instruction on the Weld End, like the manual says to, the positioner does not spin or do anything when the Robot goes from Home, Approach, Weld Start, Weld End, Retreat and back Home. I see the positioner (FANUC 500iD Hollow Positioner) goes from 0 to 180 then from -180 back to 0, but I cannot figure out how to get the robot and positioner to work together.

I also tried this morning to use the CALIBNBT KAREL program to reset turn counts, but that ticks off DCS parameters because the FANUC 500iD Positioner has known kinematics and I can't seem to go into Controlled Start and set it to Unknown Kinematics (i'm assuming because this is a FANUC positioner and not a basic positioner). So I can't use the CALIBNBT KAREL program either like I thought I might be able to.

Anyone using this option successfully? It reads like it is supposed to do what we need it to do, but I can't figure out how to get the option to work in programming!

Here to answer my own question. The list of manuals that were provided by Yaskawa on the USB drive that came with the controller left out one important manual: YRC1000 INSTRUCTIONS MANUAL NO. RE-CTO-A221. This manual has the information I needed. I was also able to find information regarding setting the tool payload as a bonus. I did not realize Motomans were capable of performing their own auto-payload check.

Hey all,

I'm used to the FANUC world and having a manual for just about evey thing (interpreting their manuals is a whole 'nother skill). I'm setting up a Base Axis on a robot and I cannot find any document that goes through this process. I am trying to figure out what best settings would be to set my Max RPM, Acceleration Time and Inertia Ratio to for the motor. I have all the manuals that were on the USB stick, but I'm not seeing anything in the list of contents or by searching through them. Any help would be much appreciated. Thank yoU!

I was able to see argument definitions on another instance of robots that I pulled in from a backdate. Perhaps it is a bug then. I'll consider this solved for now.

I'm a big dummy and my mistake was in my original post...

I was using PROGRAM = "PROGRAM_NAME" rather than NAME = "PROGRAM_NAME".

Whoops.

Quote from Nation

Attached is an example .DT file I've used in the past with success. I just changed the extension so it would upload.

Still can't get anything to show up, even using your file and creating a job called SAFE_PERCH. Perhaps this is a Roboguide bug. I doubt it is thoguh since RG runs a virtual controller.

Quote from AnandTUD

Please check if the file has been loaded from MC: with the naming convention "ARGDISP(fixed) +

EG(language) + 01(serial number) + .DT(extension)". Also check if the $ARGDISPMODE system variable is either 1 or 2.

0 : Wizard to input arguments is disabled.

1 : Wizard to input arguments is enabled. (Default)

2 : Wizard to input arguments is enabled and the value of macro definition is displayed

I completely missed the naming part of that section in the manual, though I didn't see the variable in the manual. I did the correct naming convention and checked the variable (currently set to 1). Still no-go. I'll be digging in more tonight.

Attempting to create a .DT file to show definitions of arguments for a CALL job...

I have the ArcTool manual pulled up and I've written up a very similar example from what FANUC has, but after loading and cycle starting I'm not seeing my definitions show up with the CALL job.

Here is the .DT file contents:

[PROGRAM]

PROGRAM = "MODEL_CHANGE"

ARGUMENT = '4'

[ARGUMENT]

N01 = "G2 Home OFS"

N02 = "G3 Home OFS"

N03 = "G2 Work OFS"

N04 = "G3 Work OFS"

[ENDPROGRAM]

I've loaded this into my virtual robot in Roboguide and cycled power, but not seeing my definitions come up when adding the Program Instruction "CALL MODEL_CHANGE" into my .TP job. Any idea what I'm doing wrong?

Thank you to anyone who may provide help/insight,

Tom

P.S. I'm using v9.40 on my virtual robot.

Zero Position Master is what I did. I still have the original factory mastering data that was in the robot originally and on the Master Data Sheet we got with it. When we had that mastering data in the robot though and drove the robot to all Joint's Zero - the Robot's J3 was pointed downwards about 45°, J4 was turned about 15°, J5 downwards about 45° and J6 spun CW maybe 10°. FANUC said they probably did a Fixture Master on the robot at some point before geting to us and that's why the Factory MDS is off? We have values in our Single Axis Master page as well.

I've never had a brand new robot from FANUC come in with bad mastering data before, so this is all new to me.

Had a new FANUC robot come in with bad mastering data. Going to witness mark remaster. The robot model manual says to turn off Gravity Comp and Brake Control via the variables listed before mastering. What is Brake Control? This I'm assuming isn't the same as Brake Release (as in, the Robot won't drop once I turn that variable off, right?)

THe robot model manual doesn't have any big warnings or anything near Brake Control, so I'm ASSUMING it's not the same as Brake Release, but I just want to verify before doing so...I already mastered this robot once with grab comp and brake control on and I cannot get a good TCP to track, so I'm assuming this is the reason why.

WHile I have you here, we already have a wirefeeder and torch mounted on the robot...will mastering the robot with this equipment on the robot give us a bad master and prevent a good TCP? FANUC said it shouldn't, but I wouldn't mind having your opinion too.

Thank you to any that may provide help,

Tom

Hey all...me again with more complicated stuff

Have a project coming up I'm getting ready for. The robot is on a transporter with 3 axis: X, Z and Z Rotation. I already have the axis setup correctly where the TCP can track (along X and Z), except that the Integrated Arm Length I cannot get right to save my life (in Roboguide). This is causing the TCP to "drift" when I rotate around Z axis. I thought I would measure from the center of my Z Axis out to Robot Origin, but that doesn't seem to be the solution? I tried Robot Zero as well, but that's the same measurement, just a different Z, which I don't care about height.

Been looking through ArcTool Manuals, Extended Axis manuals we have here, etc. I don't see anything showing any kind of calibration or touch 3 points to get the calculation...How am I supposed to figure this out in the real world? It seems to be very important in order to keep your TCP true to where it should be, so I'm laser focused on figuring out a very precise calibration technique.

Thank you to any help someone may provide!

-Tom

Update: Figured out 1 issue - my platform that extends the robot out that is rotating around the Z axis, was off center due to using the wrong origin in our CAD software, whoops. But in real world, the robot won't be perfectly on center of the Z Axis, so now to figure out how to adjust for that...

Quote from neighbour1

It's possible,

$SCR_GRP[4].$AXISORDER = 0

$SCR_GRP[5].$AXISORDER = 0

Then $SCR.$STARTUP_CND = 12 anc cycle power.

Changing the AXISORDER variable will "mute" the axis (that's my description and my experience). The group will still be able to be switched to through use of the GROUP hardkey.

Quote from josephtoftjr

Group 4 & 5 are positioners. I would like to unplug the positioners and move them to a different cell with a compatible robot. If I remove the groups like you recommended, should I be concerned about any DTER errors from the robot that I am removing them from?

Using the above variable (the AXISORDER ones), you should not get any DTERR alarm since you are esentially "muting" the axis. I'm not sure what other effects this may have though, so use extreme amounts of caution if you plan on going down this route.

My .02c, just do the job right...Take an Image, take an AOA, take a MNT_DATA backup...re-install the software without Groups 4 & 5. I have "muted" axis before, but that's when we're waiting on motor cables from FANUC or something else is messed up with a positioner or w/e. As soon as I can get the axis back up and running I "unmute" the axis. I've ever only used it as a temporary solution to keep moving forward with an integration project.

I'm not sure if this would work at all, but I will suggest it anyways. First off, make sure you have some kind of backup of your robot (the backup.dt file). Go into the Robot Neighborhood and then delete that robot in question. Then perhaps you would be able to load into the workcell and you can then create a new controller with a backup file? Just throwing something at the wall to see if it sticks...

Quote from yzdtc2008

Haha, you seem to like Lincoln a lot. We also cooperate a lot with Lincoln Shanghai, we have dozens of Lincoln manual welding power sources! But I am more concerned about the connection between Lincoln or Fronius and Fanuc or ABB robots, and the coordination of work. As I said earlier, I'm going to buy the arc sensor package, the robot uses the feedback of the arc voltage to relocate the path, so maybe the speed of the sensor as well as the fit is important, and the different waveforms seem to have a big effect? I wonder if you have any experience in this area to share with me?

Ha, no need to worry about the connection between Lincoln and FANUC. FANUC has come up with their own communication standard for Lincoln welders called ArcLink. To setup a Lincoln welder with FANUC, all you need to do is setup Host Comm TCP/IP address for Port 2 as well as the subnet mask. Connect to the Lincoln Welder with the PowerWave software, verify the welder is set to Dynamic IP (most of the time it already is, but I like to check anyways). Then go into Controlled Start on the FANUC controller with the Lincoln welder powered on, then FANUC will find the welder and ask some setup questions. Then Cold Start and you're off to the races (at this point I usually check the wirefeeder rollers spin with Wire+/- buttons on teach pendant). You also already seen that there is a Lincoln Arc Package with FANUC, so that should tell you all you need to know about the coordination between the equipment.

As far as using Touch Sense, you'll be best to look through the ArcTool manual from FANUC's website (CRC) or get your hands on it somehow. I'm actually looking at it right now as I write this. There is a bit to the whole process, but the I/O side of things is pretty straightforward: Tell the robot how you are touch sensing (wire or laser) and what I/O it is looking for to activate the touch sense circuit and what to look for when a side is found. Then you'll need to setup schedules and a master, so the robot knows how to find the part, what to expect, etc. As far as the speed of the sensing goes, that depends from my experience. I was using a keyence laser sensor to detect a 10mm wide V Groove once and I had to slow it down a bit to get it to sense correctly, BUT I was also taking the GO signal of the Keyence sensor over ethernet to the robot, so there was probably latency that was causing me a fuss. I would be willing to go out on a limb and say that most of your debug time with the touch sensing will be in finding the right speed and practice of finding your edges rather than setting up the touch sense circuit to work. That's where most of my debug time goes with touch sensing. As they say, put good in, get good out.

Lastly, as for the welding source waveforms, well there are a lot of waveforms available on a Lincoln Power Supply. Your best bet is to get in contact with Lincoln. I'm not sure how things work on that side since I'm usually at the end of the process with parameters already figured out from the Parents , but I would imagine they would be able to work with you on getting some good starting welding parameters with your setup.

Quote from byrol

I think you need to choose this entirely based on which brand in your area can support you better. Fronius machines are more affordable than Lincoln, and Fronius equipment becomes lighter. I think both are the same in terms of robustness. Cloos is not a brand I know of. According to Lincoln Fronius, there is more electricity consumption. However, because Lincoln is an older and more experienced company, their resource options are much greater.

Strange, last time I saw a customer buy a Fronius package it was $50k. In my experience Fronius has always been the far more expensive option than any other brand. Not sure where you have your information from, but I know some people out there who would love if Fronius actually were to cost less than Lincoln!

I have equal experience with Fronius and Lincoln. Fronius can be quite finicky. I've just gone through 8 ferris wheel systems and had to return 2 servo torches, 1 hosepack and 1 bad ethernet card/anybus module. Getting the Fronius system connected and functioning was also a pain because of their "over-engineering". Anytime the Fronius welder had an error, the screen displayed "Something went wrong. Contact support". I can't imagine why anyone would want their line down because their welder can't help their maintenance guy troubleshoot, instead "contact support". The integrator we sold those 8 ferris wheel systems to also mentioned their headaches with Fronius equipment, but chose Fronius anyways because of the CMT process. Just my .02c.

As far as Lincoln goes, there is a Lincoln place over there in Shanghai, China. I believe Lincoln will be able to offer you more than just welding support too if you want/need it. They should be able to help with integration and programming. Lincoln has an entire automation division that specializes in turn-key systems.

And lastly, not to get into too many specifics about my upcoming project, but it is a little similar to what you are doing (yzdtc2008) in terms of size and layout. Our customer has chosen to go with a Lincoln Power Supply because of the support that they can get from Lincoln, and also previous experience with them. Lastly, FANUC and Lincoln have quite the partnership going on, so they work very well together. Though I will say FANUC and Fronius work well together too when it comes to connectivity. It's up to you which you choose and as Byrol mentioned, just see which one has the best support for you in your area. I know I will definitely recommend Lincoln, but I may be a little bias, but! I am also talking from experience with both Fronius and Lincoln!

EDit: Also wanted to mention we have a returning customer who originally went with Fronius, but for all future cells (starting with the next batch here) with them are going all Lincoln.

Alright, figured it out...Something I don't believe they didn't cover in the Multi-Arm Manual or the ArcTool manual under the Process Sync section (go figure)...

You will need to setup MASH first! Menu -> Setup -> MASH. I set Group 1 as #1 and Group 2 as #2. Then you RESTART THE ROBOT!!! (I thought this P_Sync still wasn't working then I restarted)...voila now you can use the Process Synchronization instructions.

Also to note: You will not need to enter a hostname or change any of the suffix letters (which I have NO idea what those are for) if both robots are on the same controller. Lastly, I figured this out when I tried inserting a MultiArm Sync instruction. Yelled at me saying "Gotta setup MASH!" and I'm like...what's MASH? Then it clicked...Figured out how to setup Process Sync when failing trying to see what MultiArm sync is... Come on FANUC...lol /rant

Hello all,

Wanted to try these Process_Sync instructions and cut the flag handshakes out...I got 2 robots and a positioner. Robots weld a pipe in the positioner. Robot 1 and Headstock (group 3) are a coordinated pair.

I call Main_Routine, in that job I RUN R1_Weld and R2_Weld. Robot 1 and Robot 2 run jobs have Sync_Sched[1] in them (saying what I believe is "Sync Robot 1 & 2"). Then Robot 1 and Robot 2 move down to weld position. Robot 1 PR_STRT[1] at weld position. Robot 2 INPOS[1] at weld position. This is where the robots wait in position (RUNNING) for something to let them move on. Robot 1 should move on to a CALL job that rotates the pipe, but Robot 1 never moves on. I have tried swapping Robot 1 and 2 with PR_STRT and INPOS commands, I get the same effect (they stay running on their motion line). I also tried putting a WAIT of 5 seconds before the INPOS robot gets to the INPOS motion line, also didn't help move the master robot move along.

I've been trying to debug using the Process Sync Status page, but this page doesn't ever seem to change or update. Attached a screenshot of what I got on this page.

Has anyone tried using these Process Sync commands and have any idea what I could be doing wrong? I asked FANUC support, but unfortunately the support agent I got to didn't have any experience with Process Sync. Perhaps I should just abandon and go back to the old handshakes with flags (boring & tedious).

Thanks for any help that may be provided!

-Tom

No...no way to change the light unfortunately. I was trying to get cheeky and use the lights as stack lights/Operator push button lights once. Didn't work out. Though I wonder if we could slap a fairly transparent colored cylinder around a light and have the light shine from under the cylinder, lighting it up in color? Probably won't work since the simulator only simulates robots.

In case anyone's curious, I did simulated blinking lights in Roboguide by creating a machine "OP BOX". Then I had 2 cylinders for each button, one darker colored (OFF) and the other a lighter color (ON). I made the ON cylinder a slightly larger diameter than the OFF Cylinder. When output turned on to "turn on the light" I had roboguide move the ON cylinder out from underneath the gray OP box and slightly past the OFF cylinder (this way the ON cylinder completely covers up the OFF cylinder). Voila, you can now have blinky lights for whatever reason haha.

Sorry for the late reply all, out at a customer facility with an install of my current project.

Quote from Nation

Are both sleds being controller by the same controller, or individual controllers? It that the only axis on the controller, or is there an arm present?

At first glance, it looks like you are on the right track with BG logic.

Another method you could pursue is muting of Joint zones in DCS. If the one sled is out of the zone, mute it. But if that sled is in it, it will be active for the other sled. Just size the zones so there is enough of a buffer to stop in time. Combine this with your BG idea, and I think it would be pretty reliable.

The configuration is one controller with 2 robots, 2 headstocks and 2 individual motors for the sleds. I don't know enough about the DCS Joint Checks, but maybe I completely missed if that is constantly checking the current joint degree. If that's always keeping track of where that axis is and the other axis then yeah that actually could work. I'd like for the stop to work like an Axis Limit more than a DCS Alarm though is the only thing. But by this point if that's what I got, beggars can't be choosers! I'll investigate DCS some more becuase I think my understanding isn't all that quite there. Used a lot of CPC and JSC, but I guess not enough JPC!

Quote from SkyeFire

The last time I had to handle an issue like this, I ended up adding collision switches on the sleds, wired into the robot E-Stop circuits. Of course, it required a bypass switch to jog the sleds apart if/when someone managed to collide them. Not terribly elegant, but it worked.

FANUC did mention using a laser analog sensor or a limit switch of some type, but I'm not sure if that'll be a viable option at this time. Honestly I highly doubt the electrical and mechanical engineer will want to go back and make that possible. Everyone is slammed with work unfortunately and software solutions are going to need to be proven ineffective first before adding hardware solutions.

Quote from Sevastopol1

Tom,

You mentioned you couldn't get Intelligent Interference Check (IIC) to work. What issue did you encounter trying to implement this as a solution?

I believe I attempted to calibrate the motors according to Robot 1, so they know where they are in the world. But I don't believe they know that they are moving in a certain direction to IIC. The robots themselves have their personal space bubble and can stop themselves if they get too close, but I don't think I was able to get the motors to drive a combination model to stop my roboguide sleds from bumping into one another. Hopefully that all makes sense, apologies if it doesn't. Been working 12 hour days in the cold for the past 3 weeks just about!