Posts by ClaudiuA

    In case anyone else ever finds themselves in this particularly stupid situation: Reinstall Pick Master 3 on the PC. That's it. A simple reinstall fixed the issues because a particular runtime app did not install properly the first time around and I ended up wasting weeks and everyone's time on a dumbass problem.

    It's only mentioned in ONE place in the manual and we had to use an external app to monitor PC - Robot communication and discover what we were missing.

    Hello folks,

    An interesting issue for all of you that have more experience with Yaskawa than I do.

    I've recently left a job and one of the final projects I was involved with featured an Yaskawa robot with a DX200 controller. I programmed the bastard and left some updated jobs to be uploaded by my colleague - was in the final day.

    Most of the jobs uploaded fine. They work fine.

    Except this one.

    And, for the life of me, I can't figure out why.

    Every time my colleague tries to upload this, the robot reboots and he's faced with ALARM 0020, 1865, and 1876. Every time.

    If you guys could have a look through the file and see what's determining the robot to reboot, I would be extremely grateful.

    The client is far-the-fuck away and my colleague has no experience with Yaskawa, so unfortunately I can't pop over there and redo everything from scratch. I'm thinking I've written something particularly stupid at some point in this since it was all done at the office, with no robot on hand.

    Hello all,

    Maybe someone can help me on this issue.

    Our setup is as follows:

    We have 2 ABB IRB360 Robots that will need to pick items from one conveyor and place them in boxes on the other conveyor. Both boxes and items are detected with a sensor. No cameras involved.

    We are using the DSQC2000 conveyor tracking board and Pick Master 3 software.

    I have calibrated the conveyors for working with both robots.

    I have calibrated the counts per minute for the conveyor tracking. All is ok.

    I hit a wall when it came to actually running tests in production. In whatever way I connect the bloody signals, I keep getting a strobe missing error.

    I've followed both the manual, and the training we received on Pick Master 3.

    Our sensors are connected on the X21 and X22 inputs on the DSQC2000.

    Position generator: c1SoftSync

    Trigger: -

    Strobe: c1NewObjStrobe

    Start/Stop Conveyor: doStartConv1

    c1NewObjStrobe is cross-connected to the c1SoftSync. And result:

    I've tried with the doManSync output as a trigger, cross connected to another DO for strobe.


    At this point I simply don't understand what the software wants from me. The robots need to run on Monday... any help would really be appreciated.

    Nope. All arms reach too high and bang against the metal support.

    We're lowering the robots and changing the mechanical support because we don't want to risk the client running into the same situation later on.

    Hello All,

    I have 2 IRB 360 robots that I need to commission soon. Unfortunately, my support for the robot doesn't allow me to raise the robot's arms to the 0 position.

    Is there any way around getting the robot to the 0 position to calibrate the axis?

    Your other robot looks alright due to it having been stationary.
    The one you've been using has had the grease go liquid from heat and mechanical work. It's very clean grease too, so no real issues inside. Normally when we did maintenance for bad reducers / motors we'd get blasted by pitch black grease.

    As someone else pointed out, jog the robot after greasing, without putting in the plug. That way you won't get pressure build up inside.

    The only way your program points could be affected by improper PM is if:

    1. The maintenance guys manage to demaster the robot, in which case you'll need mastering and, likely, touch up some positions.
    2. Your reducer goes bye bye, in which case you'll need to swap it out and, again, remaster the robot.

    Just simply over greasing won't "push" the points away, just annoy whoever opens the plug the next time. Or, as in your case, a collision detection alarm.

    In the US, Fanuc Motoman Kuka and ABB are the ones I see the most. Kuka is hitting the market hard right now. You can buy a new Kuka cheaper or equal to a used fanuc in most cases. IMO fanuc are thieves and cons. Terrible customer service and I hope they collapse. The only reason people use them is because that’s the biggest competitor in the market and they abuse the hell out of it. They’ve got a big head on themselves and the milk people for every dime they can. I would avoid them if my work didn’t use them.. ABB i don’t know much about. Motoman is my favorite but they’re starting to act like fanuc.. I will say their customer service department is fantastic and everyone in our shop knows it, we hate dealing with Fanuc. I hear about Kawasaki nachi Hyundai otc Dyhan and omron but I don’t know much about them. Also URs are newer to the market and people seem to like them

    I've mainly dealt with FANUC customer support from Hungary or Romania. I can say they've been pretty great, even if sometimes you need to growl a bit to get the info you need.

    They say you never forget your first one.

    2014, my first robot. FANUC AM 0iA, for welding some pipes together.

    I was barely trained. I didn't even know fully what a USER FRAME was, and the TCP was still a bit magical.

    I did the trajectory. Everything worked fine while I ran the program step by step. Fine and dandy. I was completely alone with the installation at the client, so I called in the project lead to do a demonstration. Because running the program step by step ONCE was enough, by my reckoning then.

    I start the robot. It welds ok for the start, and then smashed torch first into the fixture.
    Apparently I had a CNT100 J movement somewhere on the way. Was the first time I learned why you should pay attention to your CNTs and your FINEs. I bent the torch a little, so that was a lot of fun to redo. Cemented my knowledge of TCPs tho.

    No such thing.

    I remember installing a Yaskawa robot. We were exhausted. Pulled a few 20 hour days to get the application up and running. And when we started the SAT the robot thought he'd finished a stack, went straight for the next one without resetting the counters, and made short work of the rather sensitive gripper.

    We called it a day. Packed up. Went home. 23rd of December. Came back on the 4th of January, had the application running on the 6th.

    Kfloppy works with RJ robots as well, I do it almost every day…

    Search the site, there is a link on the site where you can download kfloppy.

    Funny enough, I have KFloppy as a piece of software that I inherited from the robot programmed before me. I simply never had need for it. Thank you both for the info.

    Ok, so this is a new one.

    I have a client that wants to be able to load TP files into an RJ controller via a serial communication through the Floppy Disk connection...

    Has anyone been able to do this? Is this even possible?

    Right, that's a better way!

    But it should look as follows:

    L P[1] 300 mm/s FINE SKIP, LBL[1]

    Was writing from memory and almost 100% sure I messed up the syntax somewhere. Thanks for the correction.

    I normally use this type of programming for "crash sensors" on a palletising gripper, to abort a motion if something unexpected comes up, without mulching the payload.


    Maybe I'm blind, but I can't seem to find this feature for the e-series.

    I remember on the CB 3.1 series of robots you could define as plane feature as varible and then recalculate it. I want to create a variable in which to pour one feature or another so I can use the same MOVE instruction relative to two different pallets.

    How can this be done? I'm thinking for something really backward like selecting BASE for the move instruction and actually calculate with PoseTrans my waypoint, but that seems like reverse engineering a solution rather than using a correct one.