Posts by TomFoolious

    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".


    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:



    ARGUMENT = '4'


    N01 = "G2 Home OFS"

    N02 = "G3 Home OFS"

    N03 = "G2 Work OFS"

    N04 = "G3 Work OFS"


    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,


    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,


    Hey again with more complicated stuff :smiling_face:

    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!


    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...

    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.

    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 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...

    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 :winking_face: , but I would imagine they would be able to work with you on getting some good starting welding parameters with your setup.

    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. :wallbash:

    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 /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 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.

    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!

    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.


    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!

    Hey all,

    Another fun one I got here. I have reached out to FANUC and they didn't have too much to give me on this one, so I thought I'd reach out to the community here...

    I have an upcoming project where I have two linear sleds. One sled cannot go past the other or else crash and collision detect (I'm assuming). I'm mostly concerned for manual operations. I can limit what each sled can do in programming. Oh and to mention each sled is being driven by a FANUC axis motor. LIke an Ais or Aif, I'm not sure off the top of my head.

    So I haven't gotten IIC to work and I can't update the axis limits or a DCS joint check freely (read: without restarting). This machine will be running various models that require various lengths of the sleds, but one will always be shorter in length than the other.

    My other thought was BG_Logic the sleds' positions and in the macro jog sled program just end it right away if it is commanded to go to a crash position (read: past a varying soft limit), but I'm not sure if that's safe or viable enough? Feels more of a bandaid. I could try my hand at KAREL, but I feel that's the same as BG_Logic with another layer of protection.

    Is there a clean and safe way anyone can think of doing this? I think in the end KAREL would work best, but I just want to make sure there isn't a better way out there that I don't know about! And also surprisingly to me, FANUC doesn't make an option for this! :grinning_squinting_face:



    That's better testing than what I had tried. Hmm...yeah it is a bit concerning. I will probably come up with something else. They have no reason to ever change anything in this machine, in fact it's best they never do. There's a lot happening with KAREL programs and background jobs. It's stupid, but that's what you get when the sales guy says "Of course we can do that! *pulls necktie*". But like you said, if they ever do a file load it won't do me any good.

    Well I have enough other examples here to work something else up. Thanks for the info EnergyAddict. I'm sure that'll come in handy for others than just me in the future!

    In that situation I've always used a combination of location and a register.

    I believe there is a variable with the current program name. Maybe that would work better for you.

    Yeah I saw Current Program Name as well, but problem with that is I'd have to see if Current Program Name Variable = SR[x], where SR[x] = WELD_TACK. That works as well, but I'd like to have control over that String Register, so that it can ONLY have WELD_TACK written into it. You cannot do that in TP Programming unless you CALL a routine with an Argument Register set to 'WELD_TACK' (i.e. I cannot set SR[x]='string'). I couldn't find anywhere out of the User's hands to make that happen. Not in BG Logic either because you can't CALL in BG Logic and you can't send Argument Registers with RUN.

    I'll keep monitoring the Cur Prog ID variable and see if my program ID's change at any point. We still have a lot of running to do with this machine, so if the ID changes I should see it and hopefully find out how/when it changed.

    And of course I honestly can see that I'm probably just going waaaaaayy overboard here...haha. I have too much fun experimenting with new ideas to try and make a more solid machine for the end user.

    EDIT: I could maybe make Location & Register work...We are shifting the UF around a bit depending on what combination of stuff we are welding together...I could maybe make that work if nothing else.

    True, but then why not just set a flag to be ON?, etc.

    I'm trying to make my programming overly complicated for no good reason other than taking control from the user :face_with_tongue:

    But in all seriousness, since this is for a Robot Home program, I want to avoid someone skipping over setting a Flag to be On or a Register being set, etc. I already have the majority of my home program to be able to detect where the robot is and home from there without the user needing to be involved. Sure...I could just train the end user "nuh uh uh, don't skip over this line, it's very important", but I've had too many times those that don't listen or think they know the robot programming better. Trying to avoid that stuff/warranty call/going back out in the field to patch the code with something dummy proof!

    And to clarify why I can't user robot location with this, I need to distinguish between a tack welding program and the main welding routine, which use different paths to get in and out due to interferences from fixturing at certain stages.

    Hello all,

    I believe the answer is that the Current Program ID is generated when the program is loaded into a controller. Just looking to use the variable for some Home routine tracking. I initially made my Home program in Roboguide with an older backup of my real robot and was given ID: 2246 for my program I want to track. When I went to my real robot and dumped in the Home program I realized that the ID for the job is now 2259.

    So it seems it generates that number per controller...I also tried restarting the robot to see if that number would be regenerated on a restart and it kept the same.

    The end goal I'm trying to find here is: Will this number of the program stay the same for the life of the controller...Last thing I want is for the Cur Prog ID of that program to change, then the robot doesn't realize it ran the program and will not run the correct home path.

    Pretty far out there topic and I'm suspecting no one here will know the answer as per usual with some of my crazy questions on here :face_with_tongue:

    Thank you for any help that may be provided!


Advertising from our partners