Posts by StoopidEngineer

    I'm looking at a pretty clean 100i from 1998, and while I actually have some experience with robots of this vintage, I've never done a weld robot this old. For those of you with experience: what is/is there a preferred method for uploading new welding programs to the robot? I've had intermittent luck with KFLOPPY on the Mate (yes, Mate - I believe a 1995 'Mate' with about 100,000 hours on it) but never actually tried to upload anything to a robot with KFLOPPY. It's such a pain to use that I have honest-to-god printed out backups of all the programs and settings (because, hey, it's a 1995 robot so there's not 1,000,000 screens like on the new stuff.)

    I also work on a couple of CNC machines that are still a 3-1/2 'floppy' only system, so if I can actually just plug a 3-1/2 drive into a serial port, that's fine by me too. My problem is that I have zero experience actually doing it, and am entirely reliant on my programming software to generate weld programs, because doing weld programs by hand on the TP is nuts.

    Thanks All!

    Got a guy trying to convince me Codesys is worth learning, and I'm not convinced. However - I have an upcoming project with a Mitsubishi robot, and someone told me they can/are programmed using Codesys.

    Any truth to that? It does look like Mitsubishi PLCs can be programmed using Codesys?

    PDL - UOP is over EIP (rack 89) and Robot IO is all typical point IO.

    For the record, this is a service call - not my integration.

    The one thing I'm only thinking to check now would be Group outputs to see if it's sending anything regarding sensor status back to the PLC. If something is flashing there that shouldn't be because of an intermittent failure, and the PLC is immediately saying 'dropped product' ...but the HMI seems decent for Error messages and isn't calling anything out.

    I'm on board with it being an EIP problem, but I don't have any Ethernet on the arm at all, so it bugs me the problem seems positional.

    Got kind of a weird one and want to check in with the hive-mind:

    M-10 arm, R-30iA controller. Arm pauses constantly during cycle because of a lost Hold Signal in UI. Communication with the PLC is over Ethernet IP. Connections are all good, heartbeat timer is fine (I made it stupid long and it didn't error out) and got the same results no matter what Ethernet switch port I plugged into.

    No collisions, no alarms, no faults or blown fuses I can find.

    BUT, and this is the weird part: the Hold signal drops out (and only ever the Hold signal) at one of 4 very similar positions in the system. This, to me, screams bad connection/cable somewhere on the arm, but all the RIO is fine, doesn't flash or hang.

    Anyone seen anything like this? I've got a new cable on order (EE connection breakout to J box) but if that's not it...PLC Ethernet card? Bad PSU in the robot controller?

    I don't have visibility on the PLC side, so I guess there could be a condition flashing there causing it to drop the Hold signal to the robot?

    Scraping the barrel on this one and appreciate any feedback.


    Hey gang - before I spend a ton of time and effort on making my own: does anyone have a programming environment they like to use for offline programming to be uploaded to the robot via ASCII Upload?

    I was thinking of making a user defined language for Notepad++, but really don't have a preference on environment/program as long as it's simple and functional.

    Anyone have anything they'd be willing to share?

    Thanks all!

    Hey Gang - R30iA controller running V7.50 HandlingTool. Got a sporadic crash that occurs during an OffSet move, so on recovery (alarm ack and restart from PLC) the robot continues its move with the offset, resulting in repeated crashes.

    I don't think I can replace the offset with defined moves, so I would like to run a 'GoHomeSafe' program on restart if collision detect was the reason for the pause. And I'm hoping for some help for the easiest way to do it.

    I know I've got a DO set to alert the PLC of collision detect, so I could watch that and either set a flag or registry value in BG logic....but that feels really clunky to me.

    There's got to be a slick way to do this I'm not thinking about, right?

    Hey Gang - I know, I know, way too open ended of a question in the Subject line.

    BUT I routinely program Fanuc, Epson, Denso, Nachi, and UR robots, and have experience with a couple more brands - the only ones of which offers real weld options Fanuc and Nachi. And while I like Fanuc, they are definitely not the cheapest game in town, especially when you start tacking on options (I've heard rumors their adaptive seam tracking is the cost of another robot all on its own.) And I can't seem to tell if Nachi doesn't have a lot of options for these, or if the information is just tricky to find.

    Because I'm flexible and really have no fear of learning another robot at this point: what's everyone's go-to or system of choice for Arc Welding applications?

    This is going to be a robot on a 7th axis, servicing two positioners - so I need 9 axes of motion total. I'm starting to think that adaptive seam tracking (by whatever acronym it may be known by a certain manufacturer) is going to be a requirement. I prefer Ethernet/IP, but can live with point IO if necessary.

    Everyone has a model with the reach I need, and apart from that, it's just a "what am I most comfortable with" type of question - and I just don't care at this point.

    If there's one that does the job and is significantly cheaper than the other manufacturers, I like that. If there's one that's expensive but has boatloads of cool options that make it a marvel of manufacturing, I might go that way.

    Essentially, I've got too many options in front of me, and no real resources to pull information from, ignoring the manufacturer's sales people.

    Would love whatever input you have - Thanks All!

    I'm fairly conversant with all of the R-30 variant controllers, but have very limited experience with the R-J3iB and previous. So of course the used robot I was given (to replace an R-J2 controller robot that died) has an R-J3iB controller.

    The physical integration and I/O setup is complete, so now I'm trying to blow out all of the unnecessary old programs the robot showed up with - specifically there's a bunch of stuff that was added to communicate to an external PC that I have absolutely no use for, and want out of the TP so someone doesn't start messing with them. When I try to delete these, I get the TPIF-008 Memory Protect Violation and MEMO-006 Protection error occurred errors. When I try to turn off write protect, I get the 'Cannot change System Level Macros' message. Same message if I try to change the Sub Type.

    I've done my Googling and searching through here, but am not having any luck in figuring out how to get rid of these Macros. Any help would be appreciated. Thanks!

    LR Mate 100i w/ an R-J3iB Controller

    Serving as an IO Link Slave in a System with a CNC and also a Fanuc Servo driven 2-axis Tray Handler.

    IO Link Cable from CNC is plugged into JD1A in the robot cabinet. IO Link Cable from the Tray Handler is plugged into JD1B in the robot cabinet.

    IO Configuration: My understanding is that IO Link is Rack 32, Slot 1 - but how do I know/set the IO from the CNC and Tray Handler if everything is coming into Rack 32, Slot 1?

    I have DI[1-72] set to Rack 32, Slot 1 - Are the first X number of inputs going to be from JD1A and the next Y number from JD1B? Same with outputs (which are DO[1-68])?

    If the external devices were PLC controlled, I could at least force outputs off and on to flash the IO in the robot and figure out what's what, but I'm pretty much flying blind right now.

    Thanks all

    Rekd - An extrusion base might be an OK solution for a small/low-speed collaborative robot, or something similar (although in my experience, they're not) - but I absolutely would not want to put an actual industrial robot on one, and expect it to do anything but cause problems and/or hurt someone.

    If you had a good experience with Vention, that's great - just keep in mind any extrusion manufacturer (of which there are a boatload) will provide exactly the same service. Reach out to your local automation supplier and see who they use - extrusion is a commodity, and everybody's got the same software tools (usually a CAD add-in) available to design it.

    therobotman - lots of robot manufacturers actually have 'standard' bases they'll sell along with their robots. Not the cheapest option, but pretty decent. One thing to keep in mind: almost every robot manufacturer is going to tell you that the robot needs to be anchored to the floor. Most of them have very, very specific requirements for how to do this. Fanuc will even tell you which anchors to use, how many, spacing, etc. This is why the base in the video you linked to is the size that it is - you need to make sure the center of gravity and moment loads of the fully loaded, moving-at-full-speed robot never get outside the footprint of the base, else you risk it tipping over. I would still be concerned about it sliding around. I've seen big six axis robots that weighed several thousand pounds sitting on bases that weigh even more than that rip anchors out of concrete floors when not properly anchored, or in one case, when the concrete was only a couple of inches thick (and no one cared enough to pay attention.)

    If you're doing anything really heavy and/or fast, then use a docking system of some sort. Either setting anchors/clamps/ball-locks in the floor, or bolting and unbolting your robot base from the machine it's working with. If done right, it really won't take any longer to move than if it wasn't anchored.

    I don't know of a standard solution for this, as it's not the typical application for industrial robots. If you have the footprint to be able to do it, and want to pursue a custom solution, feel free to reach out.

    Bought a used LR Mate 100i w/ a R-J3iB Mate Controller to replace an old Mate 100i w/ an R-J2 Controller.

    R-J2 was hooked into an IO Link Module in a CNC panel, and an attached Tray Handler system, also running a Fanuc Servo controller with I/O Link.

    One cable, from the CNC was plugged into the JD1A port in the robot cabinet, oen cable from the tray handler was plugged into the JD1B Port. I believe, based on the old programs, that these were responsible for 2 inputs and 2 outputs, each. Robot controller Digital Inputs used on the R-J2 were from DI 0 to DI 5, same with the Digital Outputs.

    I've got the existing IO Link cables plugged into the correct ports, and the system seems to be up and working correctly....but how the heck do I know where these wound up in the I/O on the new robot? Is the rack and slot assingment of the IO Link ports fixed? Configurable?

    On the I/O configuration screen, the only Racks and Slots that show 'Active' Status are Rack 48, Slot 1 and Rack 32, Slot 1. Everything else shows as Invalid, except Rack 0, Slot 0, which is 'Unassigned'

    I used to think I was fairly decent on Fanuc Robots, but apparently I fall flat on my face when it comes to the I/O portion of them.

    And I would gladly read the manual, if I had one, but I have every manual for this controller and arm EXCEPT the main one, that I feel would cover at least some of this.

    Thanks all!

    @kwakisaki - Ah, that makes absolutely perfect sense now that you say it. I'm in the US and rarely encounter NPN devices, so my mind doesn't usually jump to this - thanks for the input!

    It's going to be easy enough to test out and make sure, but it looks like (based on my amateur-ish reading of the schematic you posted) that the default is for PNP, and I don't need to put power to the RDICOM pin - that make sense to you?


    Ah, acronyms. Thanks for breaking those out for me.

    Functionally, if I put 24VDC to pin 6, I'll get an air pressure alarm, and if I put 24 VDC to pin 7, I'll get the SRVO-006 alarm? i.e. I don't have to use them, but I don't have to jumper them?

    Hey Gang - Looking at the pinout for the EE Connector on an old LR Mate, and was hoping someone could help clarify some things for me.

    Pinout given is:

    1 - RDI1

    2 - RDI2

    3 - RDI3

    4 - RDI4

    5 - RDI5

    6 - RDI6(*PPABN)

    7 - (*HBK)

    8 - +24V

    9 - +24V

    10 - +24V

    11 - 0V

    12 - RDICOM

    Pins 1 through 5 are obviously inputs. I'm guessing pin 6 is configurable from input 6 tom something else? What the heck is *PPABN?

    Pin 7 - What is *HBK?

    +24V is clear, but the 0V and RDICOM for pins 11 and 12 is confusing. I've run into trouble with different companies meaning different things by 'Common' before (You don't wire hand I/O to 0V or COM on Epson robots, you wire them to what they call 'Ground' but really isn't)

    Can I use the 0V and RDICOM interchangeably? Or do I need to use RDICOM for the common connection of all the inputs? Or do I use the 0V for the common connection of all the inputs?

    It's great they give me 3 pins of +24VDC for 6 inputs, because it works out perfectly if I want to use splitters, or at least only have to try to solder two conductors into a single pin, but why only have one (or maybe two?) commons? This type of stuff drives me nuts, because I hate putting giant j-boxes on the end of little robots.

    Appreciate the help with this - Thanks!

    If I had to guess, I'd say this is a switch timing issue. All of the logic is correct, but you finally hit the 'one in a million' timing of the cycle to play Rock 'em Sock 'em. If what I'm thinking is correct, you'll likely be able to run this for months at a time, without any issues - and then this will happen again, seemingly at random. (One in a million is a couple of times a day in some places, remember.)

    If I had to start looking for a way to prevent this, I would look at using a SKIP command on one of the robots tied to a Flag, driven by outputs from the other robot (set up zones, if you have the memory available.) If any of the conditions of the 'other' robot cause the Flag to turn on, the motion of the other robot would be halted. Might actually have to be both, depending on the positioning of the robots - even if you stop the one in the zone, it could still get smacked by the other, potentially. In which case you could volley a bunch of flags back and forth - if the one halts due to a flag from the other, have it throw a flag back that halts, etc.

    This is not an elegant solution, to be sure, but for the couple of times a year it will force a stop (and probably require operator intervention to recover from) it'll save you having to replace FieldBus I/O stuff every time it happens. And is fairly straightforward to implement and test (which is the type of solution I usually go for first.)

    Best of luck!

    Hey gang - working on an application and would like to double check myself before I commit to something that can't be done.

    What I'm looking to do (with an Epson 6 Axis) is essentially a 'geared' or 'synchronous' move: I want to do a 'Move' Command in World X (or Y, or a straight line in whatever frame/coordinate system) while simultaneously rotating J6 at a matched rate. Think rolling a wheel along something, but having to have J6 Spin the wheel.

    I'm relatively new to Epson - I can do all the standard/typical integration and application stuff, but haven't dug in on this one yet.

    Any help you can offer is appreciated - Thanks!

Advertising from our partners