1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
Everywhere
  • Everywhere
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Members
  3. Silverstamp

Posts by Silverstamp

  • Roboguide TP Function keys are missing

    • Silverstamp
    • March 6, 2025 at 2:12 PM

    Hello,

    I need help with the Roboguide, it looks like the F keys are mission on the keyboard, is there any way to restore them? Or a reason why they can't be? Thanks in advance!

  • How to get time

    • Silverstamp
    • September 17, 2024 at 2:10 PM
    Quote from The Minnesota Guy

    I don't know of a way to get actual clock data or I/O history data into the job environment. What is your ultimate goal from the job environment?

    Here's a couple more options to track time in a job. They still do not capture the actual clock data of the controller.

    The GetReg instruction is nice if you have timers going in the Ladder and want to capture their value into a job.

    Timer Variables can be configured to run during certain conditions, such as Robot not running. They can then be referenced and converted to a custom string that can be stored in the IO terminal using the Print instruction once the robot is restarted.

    Thanks Minnesota Guy. Actually, I created a clock than runs 24hs, and stores hs, mins, and secs in three different registers and I use GetReg to retrieve them. Since the ladder timers count every 0.1s, I set a 10 increments counter to discriminate a second, and then count up to 60 for a minute and 3600 for an hour. I use the PLC to externally overwrite these values using the PLC time to synchronize both clocks. What do I need this for? I compare the timestamp of data sent from the PLC with the local timestamp, if values are within a certain tolerance I validate the veracity of the value obtained from the PLC, since the communication cannot fail.

  • How to get time

    • Silverstamp
    • September 14, 2024 at 12:45 AM
    Quote from The Minnesota Guy

    I have used an I/O message triggered for a very short time in the ladder for timestamp purposes. It is recorded in the I/O message history, which can be saved and viewed on a USB.

    Thank you, good data. Btw could it be possible to extract this data into the job environment?

  • How to get time

    • Silverstamp
    • September 2, 2024 at 2:00 PM

    I created a clock in the ladder using timers, and every 1 hour I get them synchronized with the PLC clock.

  • How to get time

    • Silverstamp
    • August 28, 2024 at 10:25 PM

    Hello, I need help with a YRC1000. Does anyone know a workaround to get a timestamp? either it is at program level, or ladder level, specific outputs. any help is appreciated. Please refrain from getting it from external data..:winking_face:

    Thanks in advance.

  • TOOL definition bounces to zero

    • Silverstamp
    • July 15, 2024 at 2:42 PM
    Quote from Mike01TJ

    The FSU uses the tool data for multiple safety features and changes can create a hazard if not properly accounted for. Like anything safety related, redundancy is king.

    Readback->Write->Confirm -> ✅

    Thank you Mike01TJ!

  • Station data

    • Silverstamp
    • July 15, 2024 at 2:41 PM
    Quote from 95devils

    You teach three points at the same position on the external axis. Between the positions you rotate the external axis to a different location. This creates a Master Tool Frame. Where is the external axis relative to the robot.


    Robot to robot is the same. Three positions taught at three different locations.

    I have no external axis on the cell, just 2 robots, just created a three-points calibration using the robots. It's weird how the controller can still use a calibration file using the same three Cx points that is created in MotoSim using the program command to calibrate the robots using the current layout. Additionally, the SRANG is got from the Coordinate Data option within the Calibration window, DISPLAY --> COORDINATE DATA.

  • ARM TOOL Interference warning

    • Silverstamp
    • July 15, 2024 at 2:31 PM

    Hello 95 Devils,

    Quote from 95devils

    You probably have the Arm Interference Check function or the Arm Interference with Speciified Cubic Area Check function on the controller.


    Probably, the first. In Management or higher under ROBOT, LIMIT RELEASE, will be ARM INTERFERENCE RELEASE or CUBIC/AXIS INTERFERENCE RELEASE.

    Thanks!!! Indeed, Arm Interference Check is enabled. Limit Release works fine, but I need to at least run in Play mode, and the release is driven invalid when the play mode is selected. So I did a new calibration, setting the robots range to a larger distance, avoiding their reach envelopes to overlap. Problem solved.

  • Station data

    • Silverstamp
    • July 12, 2024 at 4:12 PM
    Quote from Silverstamp

    I can't see an option to save or load this file on Motosim EG-VRC, the same thing happens with the real robot. Do you know why?

    Solved, it's within the System data menu. By the way, how is the SRANG coordinates generated in the real robots? Since in Motosim this is defined automatically extracting the relative position between arms, but how do you enter this information in the real arms calibration?

  • Station data

    • Silverstamp
    • July 12, 2024 at 3:37 PM
    Quote from 95devils

    I believe you are looking for the RBCALIB.dat file.

    I can't see an option to save or load this file on Motosim EG-VRC, the same thing happens with the real robot. Do you know why?

  • ARM TOOL Interference warning

    • Silverstamp
    • July 9, 2024 at 6:15 PM

    Hello,

    I've these 2 brand new robots working in coordinated mode and my FSU definitions look empty, I mean no definitions whatsoever. The problem is that the robots are not able to reach certain positions, and the notification ARM [TOOL] INTERFERENCE R1B R2T appear as the cause. I wonder what this might could be, since I understand that only the FSU can limit the movement of the arms according to Robot Range Limits customization. I would really appreciate some help here!:smiling_face:

  • TOOL definition bounces to zero

    • Silverstamp
    • July 8, 2024 at 7:18 PM
    Quote from 95devils

    Do you have FSU installed and not going through the read back and write procedure?

    I have it, I know. But I'd appreciate any advice about how to delete/edit the FSU definition file? in order to avoid this. Why is it hapenning btw? Thanks...

  • Alarm 9127 Collision detect must be enabled

    • Silverstamp
    • June 27, 2024 at 9:43 PM

    Hey, I haven't found other solution to this than invalidating the alarm in the CIO. But, in my case the robots are twinned, so I believe that this has something to do with the calibration of the robots. I'll edit the program and see what is it about.

  • TOOL definition bounces to zero

    • Silverstamp
    • June 26, 2024 at 2:10 AM

    Hey, does anyone know why I modify a coordinate of a tool TCP and when I leave the screen and return to it just a moment later, the coordinate returns to zero?

  • Change Group of a JOB

    • Silverstamp
    • June 24, 2024 at 2:20 PM
    Quote from 95devils

    A possible easier way is to save the job. Open in a text editor. Change the name and the control group from RB1 to RB2. Save and load into the controller.

    I tried this at first but there was an error. Since it was a relative job I also tried this with the user frame definitions and worked just fine, but it didn't happen with the job. Despite this, the mirror utility worked just fine! I'm returning the parameter to original state now. Thank you.

  • Change Group of a JOB

    • Silverstamp
    • June 24, 2024 at 2:06 PM
    Quote from 95devils

    Use the Mirror function under Utility. Change the controller to R2.

    If the jobs are to be a mirror image also, you’re done. If they are to be identical, change S1CxG065 to 0. This won’t multiply the S,R, and T pulse counts by -1.

    Great! Thanks for the parameter tip. I'll try and let you know.

  • Change Group of a JOB

    • Silverstamp
    • June 19, 2024 at 5:26 PM
    Quote from 95devils

    What generation of controller?

    YRC1000, couldn't tell what version of firmware though.

  • Change Group of a JOB

    • Silverstamp
    • June 19, 2024 at 3:14 PM

    Hello,
    I've got these two coordinated twin robots (one controller, two groups), and I have a job created on the R1 group. Is there a way or procedure to change group, or make a copy with a different group?

    Thanks:smiling_face:

  • Weird MOVL Pxxx displacement

    • Silverstamp
    • June 13, 2024 at 9:18 PM
    Quote from WattUp

    If your P-var is taught as a TOOL Coord, all it cares about is the TCP is in location, the other joints don't matter. If you set it as PULSE, then every joint will be exactly in position.

    Correct, but I need it to be as ROBOT or BASE type so I can do math with the coordinates. For instance, how do you add 100mm in X to a PULSE var?
    Despite all this, why the exception of moving the posture while moving along the line in MOVL instruction?

  • Weird MOVL Pxxx displacement

    • Silverstamp
    • June 12, 2024 at 10:16 PM

    Hello!

    I've noticed that when performing a MOVL instruction between two taught positions, if the coordinates are taken from a teaching file, the TCP posture does not change along the moving line, thus, the posture remains, which is normal and correct.
    But, if two position variables are used for the same points, sometimes, it performs 'unallowed' movements. Firstly, the P variable position configuration is not respected (P variable states FLIP and the final posture corresponds to NO FLIP), also while moving the TCP does not remain posture-stationary, is actually rotates around one of the TCP axes to some extent, and then returns to its original state. In other words, the posture and position are correctly maintained at the destination point, but in between the robot posture moves, which is not allowed on MOVL instructions. It is worth to mention that the R axis rotates the other way while doing this. What is going on wrong here? Thank you.

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download