Fanuc R-J3ib Controller Spindle I/O Output

    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.

  • kwakisaki July 20, 2023 at 11:37 PM

    Approved the thread.

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

    Quote from rpgemployee

    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.

    This is important: on the robot pendant, does the Output stay on, or does it also only turn on for a split second?

    If the DO turns itself back off when you turn it on, then something in the robot is turning the DO off. The robot outputs can't be turned back off by a bad wire.

    This sounds more like a BG Logic program (how did you determine no BGL is running?), or possible a KAREL program running invisibly in the background.

    For example, I've often seen developers write background software that cyclically turn off the outputs to spindle tools whenever the robot's motors are off, or the program is not actively running. This is usually regarded as a way to avoid leaving the tool spinning against material when the robot stops moving for any reason.

    If you've just been turning on the DOs from the pendant manually so far, I suggest writing a small program that just turns on the DOs you need, and try running that program in both Teach and Auto modes. If it's a background program turning off the outputs, there should be a set of conditions that will get that background program to stop turning off the outputs.

    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.

    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.

    Quote from rpgemployee

    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 guess is that this is your problem. I'm guessing (and this is just a guess) that you have a karel program running in the background that's turning off the DOs because the spindle shouldn't be running without a tool clamped.

    The clamp/unclamp sensors should be a pair of prox sensors reading the back of the drawbar. Probably under a cover. Check them and see why they aren't reading.

    Quote from rpgemployee

    Is there a way to more thoroughly check if we have background logic running?

    I'm not sure if there's a 100% surefire way. For regular BGL, you can go to Menu>Setup>BG LOGIC. If that menu option doesn't exist, your robot may not have it.

    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 used that in the past to have a KAREL program running in the background, loaded during boot.

    The other thing would be to make a backup of the robot, and look for any .PC files. You can't examine their program code, but hopefully someone picked names for them that suggest what they do.

    You can also do an ASCII backup, and use a search program like BareGrep to search for any occurrences of DO[1] (or whatever your outputs are). That would at least get you a list of any TP programs that are trying to control those outputs. BG Logic programs are just TP programs with some extra constraints.

    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.

    Quote from TitusLepic

    And when you start it up, does it show that you're running routerware instead of handlingtool?

    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.

    Quote from rpgemployee

    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.

    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.

    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.

    If my suspicion is correct (that RPT was the integrator), summary.dg will show HandlingTool as the software application/version but they replaced the shell so the TP will show that Routerware is the software application

    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.

    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!

    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?

Advertising from our partners