Have you looked on what is displayed on the virtual pendant when this happen. Usually it is good informations to know where the problem come from.
Posts by skalactik
-
-
Memory
There are three kinds of controller memory:- Dynamic Random Access Memory (DRAM)
- A limited amount of battery-backed static/random access memory (SRAM)
- Flash Programmable Read Only Memory (FROM)
- SHADOW
In addition, the controller is capable of storing information externally.
DRAM
DRAM memory is volatile. Memory contents do not retain their stored values when power is removed. DRAM memory is also referred to as temporary memory (TEMP). The system software is executed in DRAM memory. KAREL programs and most KAREL variables are loaded into DRAM and executed from here also.SRAM
SRAM memory is nonvolatile. Memory contents retain their stored values when power is removed. SRAM memory is also referred to as CMOS or as permanent memory (PERM).
The TPP memory pool (used for teach pendant programs) is allocated from PERM. KAREL programs can designate variables to be stored in CMOS. A portion of SRAM memory can be defined as a user storage device called RAM Disk (RD:).Flash memory (FROM)
FROM memory is nonvolatile. Memory contents retain their stored values when power is removed. FROM is used for permanent storage of the system software. FROM is also available for user storage as the FROM device (FR:).SHADOW
Shadow memory provides the same capabilities as SRAM. Any values set in shadow are non-volatile and will maintain their state through power cycle. Shadow memory is intended for data which tends to be static. Storing dynamic variables in shadow memory, such as FOR loop indexes or other rapidly changing data, is not efficient. -
If you have access to KAREL, you can do pretty much what you want.
1. Monitor for the occurence of the collision detect alarm with CONDITION ... ENDCONDITION structures
2. Enable/Disable the collision guard detection with $HSCD_GROUP[1].$COL_DET_OFF system variable
3. Display a prompt box with the DISCTRL_DIAG built in and a simple XML fileSure perhaps there might be an easiest way, but this one will work just as well
-
More commands found in various .CM files :
# PCVLOAD namefile - to load namefile.SV
# TXPLOAD namefile - to load namefile.TX
# ASLOAD namefile - to load namefile.AS (assembly files - used internally)#PCCLEAR namefile - to clear namefile.PC
#DELFR FR:namefile.filetype - to delete namefile.filetype from FROM
#DEL filepath:\filename.filetype\ - to delete filename.filetype located in filepath -
If i recall correctly, max amps for CRMA outputs should not exceed 0.2 amps per output (for R-30iB controller).
-
$MOR_GRP.$ROB_MOVE will tell you if the robot is moving (TRUE)
-
Quote
* If the singularity comes, is it sometimes faster?
Are there any more cases where the actual speed is faster than the input speed?Yes. It may temporary increase joint speed when robot cross a singularity configuration.
-
Why not try to load image of the other robot to the one that remember and see if the problem persist. If so, the problem is definetly hardware based.
-
The 0.0KB of Memory for the SYSTEM is also really weird.
-
I took the document from the Karel reference manual in Roboguide and it says that TPIN[153] is the Reset key. TPIN[145] should be the EDIT key. I double check with 2 other manual i got and they all agrees on that.
Wich manual do you got and what version ?
-
Quote
dose anyone know of a way to map the TP reset button to any DO? or how to monitor that it has been pressed.
If you have access to Karel, you can monitor for the occurence of TPIN[153] wich is the Reset key on the TP. -
Just some added info here :
You might also need to map ENBL (UI[8]) to be able to move the robot. Because i dont use any of this signals, i usually map UI[1], UI[2], UI[3] and UI[8] on the same DI that i shunt with one of the 24F pin
It is better to use HOLD in place of IMSTP if you only need to stop the robot.
IMSTP and HOLD are not safety signals, if you need this kind of signals, you need to use the connector on the emergency stop card -
IMSTP (UI[1]), HOLD(UI[2]) and SFSPD(UI[3]) must be supplied to use the robot with the UOP signals.
Either you can wire them directly to the 24V or assign them to another DI.
Also i am unsure if you can use UOP with simulated I/O, maybe you want to give it a shot -
Depends of wich kind of program we are talking to :
TP program may communicate with each other via Register values, I/O or Semaphore
Karel program are more advanced thus they can also communicate via shared variables, pipes, queue ...Also, you are right, usually only one program at the time can control motion.
-
Quote
Not sure, but it seems Fanuc likes to make it as hard as possible for (potential) customers to use their robots and software. Making things expensive is one of the easiest ways to do that.
I don't know where you live but my company is based in France and FANUC been kinda nice to us. We were given 2 Roboguide license for free (including vision plug-in) after we purchased our first robot.
I think it has more to do with which FANUC office you are dealing with than what type of customer you are. -
You can print the content of a screen to a .LS file (text) via the FCTN - Print Screen menu.
However if your robot support it, you could use the robot browser (on a PC) and the iPendant visualization function to screenshot the content as an image. -
I wonder what would happen if you disable the T2 mode via System variables and then use the pendant with Roboguide. Does roboguide will assume the new mode would be T1 and start acting like it is ? Maybe you wanna try that
-
Are you sure the main program is aborted ?
-
You could store the position value before and after the movement in two different PR.
-
Yes.
Use the SET_VAR built-in with the $MNUTOOL[1,*] and $MNUFRAME[1,*] variables where * is the tool or frame number.
e.g. SET_VAR(ENTRY,'*SYSTEM*','$MNUFRAME[1,*]',frame_value,STATUS)
Where ENTRY and STATUS are integer data type and frame_value is a POSITION or XYZWPR data type with the value of the new frame