Posts by EnergyAddict

    In the Run Panel, you can adjust the Synchronize Time and Run-Time Refresh Rate to speed up the simulation.

    Your simulation will run quicker, but I've found that different settings for these will give different timing results (on the exact same program). So, as long as you're only looking for "Ball Park" times you should be okay.

    Even with an speed limit for only one axis... your overall speed will be lower on the other 5 axis.

    This much I understand wholly. However, I have an application (4-axis robot) that runs the same motion command for many different PRs, some of which are up to 180deg different from each other

    At the placement position where J4's rotation is most similar to the pick position, J4 doesn't need to spin as quickly to arrive at the destination at the same time as the other joints.

    However, rotate the J4 position180deg for the placement, it now has to spin quicker to arrive at the destination along with the rest of the joints.

    I can slow down the programmed motion, but it would slow down the motion for the "easy" rotation as well. I basically would love for J4 to be the limiter/Speed clamp for that specific motion command, rather than programmed speed being lowered for all moves.

    I would agree with HawkME, back it all up, and then filter out what you need

    However, I have split up things in the following ways in some of my tools:

    • AOA - mget *.*
    • ASCII - Mget *.ls, Mget *.va, Mget *.dat, Mget *.dg, Mget *.xml
    • Vision - Mget *.vd, , Mget *.vda, Mget *.zip
    • Application - Mget *.Tp, Get Numreg.vr, Get Posreg.vr
    • Sysvars - Mget *.sv
    • Tp only - Mget *.tp

    Can fruit be run from the command line?

    I'm not sure, so probably not, again this really isn't my area of expertise I just hobbled FRUIT together with a lot of trial and error and got it to fit my needs at the time.

    As far as the FTP backup, since you are familiar with OneRobotics, take a look at Jay's Article USING FTP FOR INCREASED PRODUCTIVITY. This is the basics for the FTP backup that FRUIT uses. I basically open FTP, turn off prompting, and then do an "mget *.*" command to get all files.

    I sometimes do FTP straight from the command line, I've also written batch files to do backups for certain customers.

    I'm sure there is a way to have multiple threads run FTP across multiple robots, but if there is that's outside of my wheelhouse. I have run ftp on a "For Loop" to include multiple robots, but it's still backing up one at a time.

    Hope this info is helpful.

    Is this the only Alarm code when it happens?

    According to Fanuc:

    R-30iB Plus:SRVO-473DCS CLLB CC_EXTF alarmThe result is different in 2 CPU for Collaborative Robot.Check the other alarms for more information. Note: You need to cycle power to release this alarm.

    Tool Changing is usually just firing whatever I/O to Lock/Unlock your tool. So no, you should not need any other options.

    As far as simulating it, it depends how in depth you want your simulation.

    If you actually want to show picking and placing the tool. You would do it similarly to picking and placing a part in roboguide. Add the slave side of your tool as a part, and then pick it.

    The following video is one of many pretty good roboguide tutorials.

    External Content
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Bummer. I found that same thread, so made the suggestion.

    Do you have 2 robots of a similar model?

    A trick I use sometimes to find System Variables is using a comparison software (I use WinMerge) to compare ASCII backups of a ( is the ascii version). look for the differences, and maybe get lucky finding the Variable.

    I suggest you troubleshoot it. Add a pause at line 55, and rerun each iteration, look at the value of GI1 (and R1) before you resume. Your HMI might be telling you one thing, but the GI is telling you another. The code you posted isn't doing any math, it's straight up applying the GI to the offset.

    Basically you move from MiniAboveRest to MiniNearReset to MiniPlaceReset but are applying an offset that is given to you in your GI.

    (Which by the way you can program more efficiently using the "Offset,PR[...]" motion instruction option. Lines 57-70 could be reduced down to about 5 lines)

    Your offset is currently only applying an X offset which is input from GI1, you're not actually doing anything with GI2 or the Z-Offset, at least from what you have shown.

    If you are returning to the same position in multiple iterations of this program, than the value of GI1 hasn't changed between those iterations. Find where/How GI1 comes to you. At the very least, STEP through the program for all 48 places, and keep track of what the GI1 value is for each iteration.

    I am facing the same issue in CRX 10 iA/L too


    You should look at doing your dressout/cabling differently, that looks like its pretty tight to me.

    Also, looking at the speeds in your program, It doesn't seem like you are really going collaborative speeds, if contact stop is causing you issues, you could disable it in places where it's not necessary. But be sure to do your risk assessment, I'm making a judgement call off a single photo.

    I don't disagree with the Tablet TP. As I stated, it has connection issues.

    I am facing an issue with CR 15 iA cobot

    I am not a fan of Cobots to begin with, as I feel there are few and far applications that make sense to be Collaborative, and the term gives end users an unrealistic expectation. But let's be fair here, the question was asked around a CRX, and you are basing your opinion off the CR-Series. As SkyeFire states, the force sensing is different between the 2 series. I think Fanuc came a long way from the CR to the CRX.

    As far as the CRX goes, I find most of my problems relate to me wanting it to be a Yellow Robot, and expecting it to be the same. They take some getting used to. Fanuc has gone down a path similar to other brand cobots trying to make a robot that is easily deployable, and therefore "easy to program". But the step by step menus, and Icon programming, take away some of the more in depth tools/settings, that (at least I as an integrator) am used to using.

    That being said, software wise, I find myself utilizing the conventional TP Views, rather than the Icon Editor or other menus. Being a bit too "Dumbed Down" compared to what I can do on a traditional TP, the guided menus are just a bit of a nuisance.

    Hardware wise, they seem to be alright. Biggest issue I've seen is the Tablet TP loses connection. Also, its a touch screen tablet, so dirty fingers, gloves, etc. can pose issues.

    Biggest gain, Grab that sucker in Manual Guided Jogging and throw it where you want it. (or at least relatively close. But that feature is not limited to Fanuc/CRX.

    If you are trying to do it at the pre-stage when production is slow during the pallet build, I would suggest the following:

    • Have a signal telling you the pre-stage is in place.
    • Set up a flag that says whether a sheet was placed on pre-stage or not.
    • Monitor the Flag and the "In place sensor", if you have a gap and see a sheet is needed, then place the sheet
      • Turn the Flag on after Placing the sheet
    • Reset the flag whenever you lose the pre-stage pallet in place Sensor.
      • Right before resetting, Set a separate Flag that says you have placed a sheet on your Build Pallet.
    • Before beginning to build your new pallet, check the status of the second flag for whether you need a sheet or not and continue as necessary.
    • Reset the second flag whenever you finish the Pallet you are building on.

    If you are trying to place the Sheet during the transferring Gap Follow a similar setup to above with the first Flag, but don't let the prestage pallet advance before it gets a sheet.