Posts by rpgemployee

We ordered x2 HEB2-M200PY switches, now we're just waiting for them to arrive. Thanks for the help and let's hope that it isn't bricked!

Prior to us attempting to find a work-around it seemed like both Deadman switches were broken due to wear and tear. We think one of them broke a while ago which happened to be the one we didn't use as much so we didn't notice until the other broke as well. Is the teach pendant bricked or is this something we can recover from? Thanks for the help!

Good afternoon everybody,

We have a strange problem with our teach pendant and require some assistance with diagnosing what went wrong. We got a single chain fault error that was caused by the Deadman switches on the back of our teach pendant not working anymore. This is the original teach pendant from when the robot was integrated in ~2005 so it's not outside the realm of possibilities. We attempted to hook up a work-around with a 2-position microswitch (see images) while we waited for replacement switches to arrive but it seems to have made the teach pendant unusable when we attempted to use it with the microswitch work-around. Prior to us trying this work-around the teach pendant would turn on when plugged back in using the wire from the controller even if both deadman switches were disconnected I believe. Now the teach pendant doesn't turn on at all and we're afraid that we might have cooked something on the main board and it's more broken than it was before. Any assistance with this matter would be greatly appreciated, thanks!

Edit: If this information is useful we have a Rj3iB controller and a m-16iB arm.

We are using tool frames for our programs so I think that we'll stick with updating tool frame data instead of remastering and possibly messing up old programs that we use for production. Unless remastering is recommended I think that is the best course of action. I will take note of what you said for remastering because that's a very smart way of doing it - I don't think that I would have ever thought of that!

We've looked very closely for any witness marks and the only think we can surmise is that the witness marks are on the rotating faceplate of j6 or something because we can't seem to find any trace of them. They're hard/impossible to see because an aluminum frame that holds the spindle is attached to the face plate. We considered taking it off to check but we didn't want to risk messing programs up if we didn't put it back exactly where it was before.

Hello everyone, I have a question regarding single-axis mastering. We remastered the robot (when we didn't need to, pulse coder died on a joint so we only really needed to do single-axis but did all-axis zero mastering) about 6 months ago. Every joint except j6 had witness marks that we were able to jog to. We did our best by using a flat object against the spindle to master J6 but I've noticed that our sawblade is about 1/16" out and is not level to the flat fixture we are using to cut parts on. What I mean by the sawblade being 1/16" out is when you measure one side of the sawblade it measures 1 1/4" from the top of the flat fixture to the front face of the carbide teeth and the other direct opposite side measures 1 5/16", 180 degrees apart from each other. I think this might be due to the way we mastered J6. Is there a way to single master J6 when the witness marks are either gone or hidden by the attached spindle? Any help with this would be really appreciated, thanks!!

That seems to have done the trick - our robot has collision guard as the only Fanuc-provided safety software. Everything else was integrator specific and after market. Removing that option made RoboGuide much less frustrating to use, thank you!!

Hello everyone,

I'm trying to create toolpaths and generate programs using RoboGuide. Everything seems to be working fine except when I try to move the Tool Center Point with my mouse. Whether I offset it in a direction +/- or just grab the little TCP dot and move it, RoboGuide pauses for about 3-4 seconds with a little pop-up menu stating "Waiting for SysRdy UOP signal". The robot arm "ghost" will then move to the TCP briefly and then the TCP will move back to where it was originally. When I created my station I used a very recent backup of the files (not an image). Our real robot has a bunch of safety interlocks in place that prevent certain things from running unless certain conditions are met (doors are closed such that prox sensors activate, spindle needs to be warmed up, robot @ home position, etc). I'm not sure if that could be contributing to the issue but it might help. I've noticed that cycle restarting the controller makes it behave briefly, a few moves maybe, before the issue resurfaces. Any suggestions to help resolve this issue would be greatly appreciated, thanks!

Adapter/Card image:

Hi everyone,

I am trying to make an image backup of my company's controller but for some reason it continually gets hung up/frozen during the process. I've attached an image of the adapter/card and an image of the screen that the backup freezes on. I created a 64mb FAT16 partition on the CF card I am using to avoid running into issues others have had when trying to use larger capacity cards. Before the backup process I am also formatting it using the option in the backup/files menu before attempting to do the image backup. Each file that is successfully pulled from the controller is exactly 1024kb, with the combined size of every file equaling ~18Mb or so. The issue obviously isn't the available size on the card. Any tips or advice on how to get a complete backup without it it freezing?

Quote from Skooter

This is picture from eBay of what you need. The CF card can be 64MB up to 512MB - buy at least 2 CF cards. There are plenty of options on eBay & Amazon.

This worked perfectly, thank you! One final question, I swear: I want to make a backup for the image of the controller. Do I need to jog the robot into it's mastering position (tediously line the witness marks up I think?) or am I okay to take an image of the robot without moving it?

Quote from Skooter

To answer TitusLepic, need to post the software application and version. Posting the summary.dg file from your 'All Above' backup will answer a lot questions regarding this and setup at the robot end.

A quick way to get a readable info from R-J3iB programs and many variables is to Copy MD to MC. Here's how:

Insert empty MC card

File menu > F5 [Util] > Set Device > Select MD & press Enter

Press Next > select Copy > F4 [Choice] with cursor at 'To Device' > select MC & press Enter

Press DoCopy and since you started with an blank MC, answer Yes to the Overwrite question.

This copy will take up to 10 minutes depending on how many programs - be patient.

Once complete, I always press Next > F5 [Util] > Set Device > select MC & press Enter. Leaving device set to MD is NOT safe or good housekeeping.

On your computer, look at the files copied and you can now read the text versions (*.LS, *.DG, *.VA). I personally use Open with and select 'Always use' WordPad.

Display More

I know that this was resolved but I am trying to get a backup of the controller and we're running into issues. We are using PCMCIA -> SDHC. I created a 64mb FAT-16 partition on the SD card but the card cannot formatted by the controller. When I try to copy from MD->MC as per your instructions the card cannot be detected despite the alert bar saying that a card is detected. Should we just switch to PCMCIA->CF instead?

We were able to get it to work. The issue was whoever owned the robot before swapped the spindles out and their specifications didn't match. The one installed prior had a thermistor but the current one does not. They also swapped the unclamp and clamped inputs during installation so we swapped them back in the cabinet. We ended up just pulling out and capping the wire that controls the the thermistor input to the controller and everything seemed to work correctly. Appreciate the input by everyone here!

Quote from Skooter

The old RPT is now Shape Process Automation. If it was made by RPT, they should still have info - they've been great in the past whenever I've needed their help.

They were indeed the previous integrator. I've gotten into contact with them. It's taking them some time to find everything since it was configured almost 2 decades ago but they've been super helpful.

Quote from TitusLepic

Do you know who the original integrator for your robot was? And when you start it up, does it show that you're running routerware instead of handlingtool?

On the main browser window it says that we're running HandlingTool v6.3140. I'm still working on getting an ASCII backup - the machine is almost as old as I am so it's a bit of a learning curve to say the least.

Quote from SkyeFire

For background KAREL programs, the first thing I can think of is to go to Menu>System>Config, and check the entries that have Autoexec Program in them.

I've also checked these - both have no values. I think the ASCII backup is a great idea. I'll first look into whether the proximity sensors on the spindle are working properly and then figure out how to do an ASCII backup. Great advice everyone, I really appreciate the help.

So it looks like that the spindle controller does receive output from the teach pendant. The LED for spindle forward stays lit up on the output module when the warmup program runs in Auto and the controller does register a (albeit very small) load. The controller display says that it's only outputting ~1.2% of the motor rated active current and the spindle does not move.

The DOs in the teach pendant display do not stay on - they will also only stay ON for a split second before switching back to OFF. We have a small program that we are supposed to run before using the robot for production that warms the spindle up for ~15 minutes or so. This program turns on the needed outputs and sets the spindle speed via analog output. The outputs don't stay enabled even if they are enabled in a program like you described.

Is there a way to more thoroughly check if we have background logic running? Our teach pendant doesn't have any options to set/enable background logic programs in either Menu -> Setup or in the Menu -> System menus. I was doing some perusing through other posts in this forum - common consensus is that a lot of the older models don't have this specific option for background logic. I think that the system variable $PWR_NORMAL can be used to do something similar to background logic but it was uninitialized when I checked it.

I think I've confirmed that there's no background logic going on. The teach pendant doesn't have any options for checking or setting background logic (our controller is from ~2003 or so; I've heard the older models tend to not have this option). I've also checked the $PWR-NORMAL system variable - this was uninitialized. I also checked for any interconnections between inputs and outputs - these were also all disabled and were default values. When the outputs are toggled you can see their respective LEDs light up briefly on the output module that's plugged into the IO rack but only for a split second. I think there might be a loose or broken connection between the spindle controller and the teach pendant. We're going to try to check continuity between the connections and see if that might be an issue.

The spindle is a Colombo RC 73/22 spindle and it is controlled by a Commander SE variable speed drive that is located inside of the top cabinet of the R-j3ib controller. I'll do some poking around and see if I can find any background logic that's affecting the I/O status in the meantime. Is it possible that these outputs are interconnected with other I/O?

I should also note that the spindle does NOT move when the digital outputs are toggled (and then switch back to OFF almost immediately).

Hello everyone,

I started a new job recently and my first task was to get a pre-owned M-16ib arm with R-j3ib controller working. I have no previous experience with robotics in the slightest. Attached to the arm is a spindle that takes tools placed in collets (saws, drill bits, router bits, etc). So far, I've managed to figure out how to jog the robot, make basic programs, toggle various outputs such as spindle air cooling/clamp/unclamp the spindle, things like this. However, we can't seem to get the spindle to forward or reverse using the digital output, either through simulating or through programmatically changing the status of the DO register. When I try to force an output in the menu, it only stays on for half a second or so and then immediately switches back to OFF.

We've verified that the spindle itself functions by using a manual override on the speed controller for the spindle. I've also noticed that digital inputs related to the spindle, namely two that define if the spindle is clamped or if the spindle is unclamped, do not update accordingly when it clamps or unclamps. My suspicion is that there's some communication error between the controller and the spindle with regards to the I/O connections. Any tips on how I can troubleshoot this? Thanks.