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.
There is a speed limit for each axis, but I'm not sure if you can modify it with a system variable.
Is this set globally somwhere?
Does anyone know of a way to programmatically restart a System Monitor? (I'm on an R30iA Controller if that matters)
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:
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.
There is a motion instruction along the lines of "Skip, Lbl[] PR[]" which is Fanuc's "High speed Skip". it responds faster , but is limited to 100mm/sec.
From a Controlled Start: Menu->Next->Program Setup
Looks like there is the ability to increase the interconnections up to 64.
You could increase the Servo off time: $PARAM_GROUP[1].$sv_off_time[#] but I don't know what the max number is here. Our company sets all robots to 200000 which would be 200seconds.
Is this the only Alarm code when it happens?
According to Fanuc:
| Error | Severity | Message | Cause | Remedy |
|---|---|---|---|---|
| R-30iB Plus:SRVO-473 | DCS CLLB CC_EXTF alarm | The 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.
A 'PAUSE' instruction in the program or the 'HOLD' signal which is UI[2]
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 Sysvars.sv (Sysvars.va is the ascii version). look for the differences, and maybe get lucky finding the Variable.
Try checking the system variable $BACKGROUND
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.
Where is your Group Input1 and Group Input2 coming from?
I am facing the same issue in CRX 10 iA/L too
1. the APPLICATION photo(MACHINE TENDING)
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:
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.
