Posts by jstolaruk

    Often, I have 2-5 robots competing for access to a common space. I use a safety PLC along with DCS to only allow one robot at a time access to the common space. A TP program must first request access from the cell PLC and if given, the CPC zone is "enabled" for access. Once done and clear, the TP program releases it. The PLC logic gives access on first-asked-first-allowed.

    This works well to protect the robots from crashing and if a programmer without system knowledge tries to program a robot to access that space without going through the request-release protocol, a DCS CPC zone violation occurs before the robot gets in harms way. And for the programming, a simple wait-on-a-OK-to-access-input is inserted in the routine.

    I've got (2) extended axis (J7 & J8) that I make a dual axis after I calibrate them (J8 follows J7) so after pairing, a PR will only show J1-J7, I've noticed that if J8 (or J7) suffers a over current fault (requiring the controller to be power cycled) and J8 is no longer zero when J7 is zero, there are no faults indicating that they are no longer synchronized. So, on power up I'd like to put a comparison check on the J7 & J8, and report the un-synchronoused condition. Any place in the system variables I can get J8 value? (Sorry if this is detailed in another thread, a quick search didn't yield anything).

    Thanks, Jeff

    Very nice, thank you for the utility. Often, I have multiple robot's that I would like to backup at once. Can fruit be run from the command line?

    I was using the backup tool from onerobotics which is perfect except it doesn't backup more than 128 files.

    Again, thank you!

    PS: OneRobotics backup tool does appear to work for more than 128 files but sometimes not.

    I've got a very large tool on my M900iB robot and I've defined it as DCS's User Model 1. My cartesian zones, like the overall fence and some equipment within reach of the robot include the robot model and user model 1. Normal stuff, works great, no issues.

    But because I'm doing a lot work near the base and J2, it occurred to me that it would be a good thing to protect against the user model violating the robot model. Especially for the customer's maintenance folks that may not be watching where they jog the robot. Any thoughts on how this can be done?

    Its a procedural language, not unlike BASIC, with simple math capabilities and then a set of robot move commands (like a macro). Its not G-Code like you'd find in a CNC controller. And its not ladder, SFC, or FBD like a PLC but not unlike structured text. TP programs can be made to execute in the background with limited capabilities.

    I don't believe I've ever designed a robot cell without a PLC, they pair well with their individual programming language strengths.

    ABB programming looks suspiciously like Modula-2 (same country of origin so makes sense).

    You may ave already examined this list but here is what I would do to find this stuck digital output.

    From the DO configuration display, what is mapped to DO706? Rack and slot? DCS can't impact a DO unless CSO, CPC, JPC, etc is mapped to it.

    Go through the system/config menu display to see if DO706 is listed as a status output?

    Have you gone through all of the interconnection menus to see if DO706 is mapped to something?

    Any background tasks running that could set this output?

    When the indication from the cell safety PLC is reporting a DCS signature change, do you mean "safety network number"? This number has to be perfectly matched between scanner and adapter in order for safety CIP messaging to be successful. If the PLC programmer is making PLC downloads with old safe network numbers, that PLC error may come up. Otherwise, this number does not change when making changes to DCS. Once established, it can be left alone (except for aforementioned PLC downloads). Even changes to the size of the number of bytes won't make the change. So it may mean that there is something wrong with the DCS processor or the ethernet/ip scanner/adapter or both.

    The devil is in the details.

    I use safety components (CIP safety, Profisafe, etc) controlled by the safety PLC and the enable/disable of power/air follows the robot's teach pendant safety enable when the fence is open. The robot program makes digital requests to the PLC for EOAT motion. Eventually, the issue comes down to pneumatic valves and rodlocks aren't safety devices. so you try to minimize the impact so its rarely if ever perfect. It can be scary with a 300lb diesel head or 500lb block being swung around.

    Some things that come to mind.

    Is the robot also using a fieldbus (ethernet/ip, profinet, EGD, etc.) on the same ethernet connection?

    What is the network connection to the PC routed through? Managed or Un-managed switches? Un-managed may mean the robot is exposed and overloaded with network traffic.

    Can the ICT guy force the network connection to a low speed?

    Can the ICT guy inspect the connection with diagnostic tools to check for dropped / incomplete packets? If not, there are a lot of free ethernet tools available for simple diagnostics that can be run on the PC.

    Can you temporarily isolate the PC-Robot connection from the plant network?

    I wasn't asking anything specific, just wondering about anyone's experience. I'm experienced with RMU & DCS w/collaborative just not RMU's collaborative and was wondering if anyone has had any pitfalls (there is always something).

    I've got a project coming up with one of these, anyone here worked with one yet? Any differences other than some changes to the RMU?

    Can't imagine its too different, Fanuc's version was just an additional change to DCS.

    TP programming. I've got a customer that requires I not use Karel.
    I want to read the reference positions I've set up and write them to PR's. I want to access R[21] = $RefPos1[R[20]].PerchPos[R[19]]

    Anyone got an idea?

    Not sure about using indirection (R[20] & R[19]) but if you can, R19 will have to go from 1-8 and the values returned will be that joint's position in radians.