Posts by TomFoolious

Received this cell in that was able to jog all axes (including both headstocks that I can only assume were connected to the LSU's). They couldn't get the LSU's to work after tearing down, cleaning equipment/platforms/robots and putting back together. I'm not sure how this was wired up at all to work since the R-J3iB LSU unit doesn't seem to connect to the R-30iA 6-axis servo amplifier (missing connections like CFR7) according to the R-J3iB LSU and R-30iA LSU Schematics I've found on local network/CRC.

I'm not familiar with these older robot controllers, so I'm hoping someone's brain can get shaken to help me out here. Would these two items work together? I'm thinking I need to find similar connections that the R-J3iB LSU would need that the R-30iA 6-Axis Servo Amp could send? and/or the Process I/O Board that is present too?

Normally I assign Port 1 as adapter to have talk to the PLC. The second port would be go to a switch or go out to EOAT or to a welding power source.

You may need to configure your AO/AI signals under the Analog I/O menu. I'm not entirely sure what you may need to configure exactly...due to little information provided and the use scenario. I would advise looking at a HandlingTool manual for the software version you are running.

You will probably need EDS file, so you know what settings to provide under the Ethernet/IP I/O submenu. Things like Assembly Instance In/Out, major/min revision, sizes, etc. That goes for EOAT and PLC.

I believe I'm correct in everything I've stated above. If not someone here will happily correct me

I've had this before. My problem was when I was setting up a Fronius welder using Ethernet Extended. I didn't set the IP Address correctly for the welder and/or the FANUC IP Port. When one or both of those IP's were wrong, I got the same thing you have.

I fixed it by (struggling for 2 friggin' days thinking it was a robot problem and not a darn user problem _{not bitter or anything...}) correcting the IP Address in Controlled Start (I believe I remember being able to get to Con Start). If that doesn't work (or if that didn't work for me in the past when I was fighting this) I would load the latest image I had and start over again.

Hope this helps!

You can get your DI's to turn on by using "I/O Interconnections" which is under the Cell drop down at the top. If you've ever used Interconnect on the pendant then this is the same concept.

Essentially what you'll want to do is tie other signals on your main robot from the same main robot or another robot/device in your virtual workcell to the DI's you need to use.

For example...under I/O Interconnections you could tell Roboguide that you want DO:102 of Robot Controller 1 to control DI:2 of Robot Controller 1.

Quote from Searchligt_1

Hello all,

Sorry for the late response, I am new to all this so I have been learning as I go and will try to explain it as best I can. My I/O's are configured correctly. I am currently trying to find the Logic Simulation Assistant option but can't find it anywhere in my Roboguide/Help ( TomFoolious). Another forum thread said its in the test-run drop down, but I don't see it. I haven't tried Daxos332's or HawkME's solutions yet.

Yeah, you're not wrong. It should be under Test-Run. In the Help file for the LSA, it says robot versions 7.30 and earlier are not supported - perhaps that's why?

Just abandon the LSA and go for one of the other solutions. If LSA ain't there, then it ain't gonna be there haha.

I've had plenty of people with the habit of flipping the teach pendant enable switch to ON as well. Hasn't seemed to hurt anything.

Normally though, if I know I'm going to be touching up something and with having the experience - I usually background edit in a pause or a wait (as HawkME suggested).

I think it also comes down to whatever is most convenient as well. And to be perfectly clear...we're talking about stopping the robot in a NON-Safety related way!

Just to throw this out there too (TitusLepic's answer is best)...If you create a Feature Group, click on the next tab in the properties, then add all your features/segments from one list to the other (this can make sense if you were to see the Feature Group setup box), you can then create one Feature that has all of your features/segments included all in one. It's not ideal in some situations, but that would be how you could take all of your individual features/segments and put them in one feature.

It's hard to help when we're all unsure of what is all in your code (what DI's are being used, for what purpose and how are they breaking your code).

Best I can suggest with what information has been shared: Use the Logic Simulation Assistant thing in Roboguide. Go through your program to turn your inputs on and off automatically. Check out the Help document via the Help button to understand how to use the tool. I've used it a few times, it's good for what it is there for.

Hope this helps,

Tom

Quote from HawkME

In that situation I would just switch to tool, rotate 13.5 degrees and jog straight on.

In my example I did not want to rotate the tool at all. I wanted to keep the tool parallel and perpendicular with the surfaces around it. Idk if that clears that up or not, internet words are hard sometimes haha.

It's hard to explain...but I've used them when I have a User Frame setup for a fixture, but still need to move in an off-angle way within that User Frame's area.

Best example I can think of...I was doing some cutting on a wall of a box. This box had a trapezoid like shape cut into it. I wanted to keep my tool in the orientation it was in (parallel with Z plane), but I wanted to move the tool at the angle of the trapezoid edge. So I setup a Jog Frame with just a W value of 13.5° or whatever it was...From that moment on I could keep my tool in the same orientation and then move it at the weird angle up and down.

Hopefully I explained that well enough to make sense!

I believe you can...I did DispenseTool a few years ago and I believe I needed to switch Seal Schedules either around corners or for an "end" schedule (like welding).

Also if it helps (maybe you already do this), from my experience last time I dispensed I laid down a layer of masking tape on my part where the sealant went. That way I could keep the part gripped up and everything and just tear off the masking tape and replace with new. Helped greatly for debugging/path creation.

I would think you would want safety wired into the robot controller on the E-Stop Board/DCS Board or sent via Ethernet/IP (CIP Safety).

The broken light curtains should be triggering a safety input on the robot which should stop the robot. The signal I'm most used to seeing used is FENCE and SVOFF. Those come from DCS.

Usually the robots I work on are programmed to start again after the operator presses the cycle start button again or presses a cycle resume button on a HMI which sends a UI signal to the robot (UI[ 6: START]). If you want the robot to start automatically after the light curtain is not broken, I would think you would need auto-resetting light curtains. My company tends to stay away from those types of light curtains since we've seen and heard of them used in proper applications, but still cause some unsafe sitautions. Human observation and interaction is better for restarting a robot after a light curtain is broken in my opinion.

Quote from TomFoolious

I don't believe I've mentioned this yet (didn't see it in my comment above)...But this one is simple and WHY do we NOT have the ability to do this yet...

EDIT IIC ZONES LIKE SPACE CHECK/DCS! SERIOUSLY! Haha...Unless I'm missing something...I'm making a random Obstacle Box, positioning it in the CHUI world where I want the IIC Zone to be, Measure from Robot Zero to vertexes of the box, then inputting those numbers into the TP.

But once again FANUC, seriously...why we can't edit IIC zones just as we can DCS and Space Check Function??

Oh and one more thing: WHen setting up Parts on a tool, allow us to turn on/off multiple inputs. Like if a part would cover more than 1 prox, let us turn on RI:1 & 2-#...Rather than turn on R1, have BG_SIM job that says "Oh RI:1 is on and this is this part? Well then RI:2 and RI:3 are on as well"

Display More

IIC Zones are now editable in Roboguide CHUI world just like DCS and Space Check Zones! I just noticed this, so maybe Revision R brought in this functionality? I don't remember seeing it in the What's New notes though.

Not a lot of setup particular information in your OP, but I'll throw a few ideas that come to mind...After typing below and re-reading your OP, I believe Option #2 may be your issue?

1.) Ensure your Simulation Jobs have Pickup and Drop instructions in them with the appropriate Fixture, Part and End Effector selected.

2.) If that checks good, make sure in the RUN Panel you have "Collect Profile Data", under the Collection section checked. As the description next to it says "also enables pick/place animations".

3.) If all that is good, make sure you have the I/O setup correctly under the Simulation Tab under each Properties page for your Fixture and End Effector.

I read half of what was going on in this thread...But I don't have much time and wanted to offer my suggestions/experience real quick.

1.) Flags in the program which then activate a check in a BG_Logic job...if F1 = on and UF != 2 and UT != 1, alarm

2.) Use DCS or Interference. Space Check to me is terrible, but I've only been in robots for 4 years, so I may be missing out on a great thing about Space Check...My opinion of Space Check being terrible stems from the fact that I understand it tracks TCP ONLY! Whereas DCS/IIC can track a MODEL regardless of UF/UT.

3.) I was going to suggest you could set up boxes like DCS or IIC and background track with the CUR_TCP variable, but that number of course changes with whichever User Tool you are using (and only updates when the robot is moved). Now I'm curious if there is a CUR_TCP like variable that only tracks robot position if the UT = (0,0,0,0,0,0) and in world frame...Then again you could always write a background track job that is based off of a Null TCP that is always set Null at the top of the program...etc etc etc, but still the CUR_TCP variable only updates when the robot is moved...hmm...

4.) You could have a BG_Logic job that sends the UF and UT to the PLC at all times with a Group Output...or the PLC could explicit message a Register you are background logic setting to the current UF and UT. Then of course the PLC can restrict what can happen if the Robot isn't in the right setup.

I read a bit more of the thread and it seems like you did solve your problem...but anyhow, I'm just going to leave this here anyway

Bug Report: Sometimes when pressing F8 with the Virtual TP focused, disables keyboard shortcuts. I then have to press the keyboard button at the top of the VTP to re-enable keyboard shortcuts. F8 does not always cause this and I have not been able to pint point the sequence of events/keystrokes/whatever it may be that causes keyboard shortcuts to be disabled when pressing F8 to bring up the VTP Menu.

Just gathering and laying down some thoughts here...So FANUC is coming out with their own Laser generators (already has it seems). I'm hoping to be getting into these at some point at my workplace. I decided to hop into Roboguide and try and toy around with this, but am stumbling a bit. I can't find any documentation on CRC about their own seamlessly-integrated laser units!

I have a LS() line placed in as a Laser Start in Roboguide with a short slow move followed by a LE(), but I'm not seeing any I/O being simulated. Going to keep messing around...maybe I need to turn some bits on to start the process. New to lasers and new to FANUC's laser here, but still going back...no documentation on CRC! Nothin in ArcTool or HandlingTool.

Lastly, I'm really really hoping that FANUC releases Laser as its own Tool branch...LaserTool. It's a bit messy being thrown in with ArcTool currently.

There are a few options...

1.) Use Logic Simulation Assistant under the Test-Run drop down menu. There is a help document along with this to explain how to use it. But in a nutshell, you point at a valid line of code and tell it what you want to simulate when it gets to that point...i.e. If you get to a Wait for Pounce signal in the robot code, you can simulate that the robot gets that DI: Wait for Pounce signal.

2.) You could throw an additional blank/throwaway controller in the cell and setup I/O Interconnections between your main robot controller and this throwaway one. Then run a Background job on the throwaway controller that will look for DO's from the main robot in the form of DI's and then the throwaway can send DI's to the Main robot in the form of DO's...

3.) Last option is to just put your simulate stuff in the robot code itself where you need it. When I do this I usually just mark around it **FOR DEBUG ONLY** and such.

4.) Load the PMC option into the robot, bring up FANUC Robot ladder editor and write the PLC logic yourself in the ladder editor.

I've used all methods depending on the situation. Logic Simulation Assistant I've only just started using...it's OK, a little confusing and sometimes maddening with the restrictions of where you can place simulated logic...The throwaway controller method I've used only once before and that got a little iffy because of the I/O Interconnections getting passed around - Roboguide is finicky at times and that can cause a corrupted workcell. Definitely take backups of the workcell to load back to when you are messing around with these things!

Quote from alive15

TomFoolious Do you have to move the duplicate robot into the same position as the original robot to get all the teach points to match up? Couldn't you just take an image file from old robot and upload into the newer robot, that way all the master data points would be the same?

If I'm not wrong, an Image would do the same as an AOA...but loading the AOA is just faster? And as HawkME said, you'd still need to load the SYSMAST file.

No you do not need to have the robots in the same orientation when loading. The teach points would be the same because the robot knows where they are based off the robots unique mastering data and the programmed TCP position. So from one robot model to the SAME robot model, the position data should match up. Someone correct me if I'm wrong, don't want to lead anyone the wrong way!

Just to throw this out there for anyone reading...If you have identical robots like I have on my current project...I've taken an All of Above backup of the robot I have finished, taken a backup or already have an As Received backup of my Duplicate robot...Then I will go into Controlled Start and Restore the All of Above backup of my Original robot into the Duplicate robot. After the Restore is complete, I then needed to set the F# as well as Load in the Duplicate robot's SYSTMAST.SV file, which will Restore the Duplicate robot's Master Counts. After this the Duplicate robot is exactly the same as the Original robot, minus their differing F#'s and Master Counts.

Saved me a LOT of time not having to load individual files, punching in PR's, comments, etc. etc. etc.