sounds like your ram is the issue. what are your LED codes on the motherboard when it locks up?
run your output to a safety relay and have your systems safety voltage run the coil. DCS I/O is your best bet, it is all dual-chain and can give you a safety rated signal for T1/T2/Auto. you can also set it up to ensure that it remains in an area, restrict joint positions, speeds ect.
its possible the change of frame is not the cause. if there is too much logic between one point and another the motion interpreter cannot determine a path. try teaching a dummy place point using the pick uframe. if this eliminates the hesitation then you are on the right track. i suspect however you are chasing the wrong problem. There are a couple of common culprits. a lot of call/macros between when the last path was generated and the new one is declared. any decisions that have to be made between the two, what pallet to go to for example, can keep the robot from calculating a smooth path. using the same PR's for dynamic offsets can sometimes cause problems as well. if possible remove and LOCK/UNLOCK PREG commands. the other one i have seen is excessive loops. anything that jumps up in the program. ie JMP LBL or an ENDFOR can really slow the robot down. if that is the case you can can try to modify $PG_CFG.$jmpwait_upr. you can also look at $SCR.$maxpremtn. though that one has not generally produced as good of results for me as the name would suggest.
probably have it in the wrong port. the standard R30iA has 3 RJ45 connectors on the main board. CD38C is at the bottom and is normally only used for vision systems. at the top you will find CD38A (port 1) and CD38B (port 2). each port has to be set up in the host com screen, you can change the port by using the F key labeled PORT. each one has to be on a unique subnet mask. they are isolated and traffic does not cross them. in order for any changes to take place the controller has to be restarted.
karel has some built in routines for parsing the currently assigned tasks. i have looked though the variables and have found nothing that will do exactly what you say without more information. you can try the $MOR_GROUP.$CUR_PROG. that will have the name of the last program that generated motion for that motion group. that might be sufficient for your task. beware though as it is invalidated as soon as the robot is jogged.
any user generated *.PC files will be saved, as well as a select few from Fanuc. mostly built in macros for options installed. ie MATRIX.PC or IRSNAP.PC etc. There are a lot of them that are hidden however.
confirmed. Fanuc got back to me and it is as you say. interestingly enough the CLOSE FILE does not update the status with a fault even if it generates one. I agree that it is good practice, and will continue to use it. I just like to know what exactly i am asking the robot to do. call it a programmer's quirk.
use the wrist joint motion instruction. WJNT will regard the wrist in joint so it should go to the configuration specified in the final position.
you are correct sir. i should have known better. the lack of leading zeros threw me off. I should have used POST_ERR(IO_STATUS(inputFile),'',0,0) then i would see the dictionary entry posted on the Teach Pendent. That does however reinforce my point. why even use the CLR_IO_STATUS?
Return an INTEGER value indicating the success or type of failure of the last operation on the file argument
Clear the results of the last operation on the file argument
in all of the program examples i find in the Karel manual whenever IO_STATUS is used it is immediately followed by CLR_IO_STATUS. This does not seem to be needed. i put together a quick test and it read out as follows.
open MC:\IO.csv failed
To me this means that the CLR_IO_STATUS is not needed as the value will be replaced by the next operation that uses it. the CLOSE FILE built in always sets it to zero. my favorite part is that 2014 is not a listed code in the table. i would expect either 12327 Open file failed or 12328 file is not opened.Code
PROGRAM fileopentest %NOLOCKGROUP VAR STATUS, entry :INTEGER devicePath :STRING inputFile :FILE BEGIN GET_VAR(entry,'*SYSTEM*','$DEVICE',devicePath,STATUS) -- path was set to wrong location for this test MC:\IO.csv does not exist. file is saved at UD1:\IO.csv -- FILE_LIST('IO.csv', n_skip, format, ary_nam, n_files, status) devicePath = devicePath + '\IO.csv' OPEN FILE inputFile ('RO',devicePath) IF (IO_STATUS(inputFile) <> 0 ) THEN -- CLR_IO_STAT(inputFile) WRITE('open ', devicePath, ' failed',CR) WRITE(IO_STATUS(inputFile),CR) -- returns CLOSE FILE inputFile -- sets IO_STATUS back to zero by default devicePath = 'UD1:\IO.csv' -- set path to correct location OPEN FILE inputFile ('RO',devicePath) WRITE(devicePath, ' opened',CR) WRITE(IO_STATUS(inputFile),CR) ELSE WRITE(devicePath, ' opened',CR) ENDIF END fileopentest
i really like those fortress locks. there is even a model that if the lock is opened from the inside, it cant lock again without the supervisor key. they are a little complicated to wire up, but they are slick. small form factor as well.
thats a large bump in memory size. i would would put a memory card in the robot and write a Karel program to swap files out as needed. if you have Ethernet you could FTP them as well.
you could do a servo lockout. that way the 220V is in fact shut down, the 24v circuit does not control anything other than a few lights and a teach pendent.
Zero mastering an axis is you telling the robot that you know the axis is at exactly 0 degrees. the robot will take the current encoder counts and form a relationship between them and the angle. it will happily go about its business but the robot will be the wrong shape. it will not be able to make right angles, and your frames will be warped. most of the time a small error is not an issue, and user frames help reduce this error further.
in mastering any joint you have several pieces of information that have to be considered.
Real world data
current angle of joint
current encoder count (encoder position and motor revolutions)
Mastered angle of joint
Encoder count at mastered zero (encoder position and motor revolutions)
If quick reference was setup
Reference angle of joint (in radians)
Reference encoder counts (encoder position and motor revolutions)
The relationship between the angle and the encoder count must remain static in order to restore mastery properly. ie $DMR_GRP.$MASTER_COUN=26218 and J1 = 0. It is important to note that the master counts from the factory don't actually all refer to 0 degrees. the count is a 32 bit number and i want to say the first 18 bits are for the motor revolutions. i back calculated the master position for a robot once, and it appeared to be the way it would sit in a jig as they build it. the quick mastery data will find the current angle based off of this relationship, and correct the real world angle. if you provide the robot with two pieces of information, it can provide the other one.
real world angle ? somewhere near zero
real word encoder count = 285255646
reference angle -1.527 (90 degrees)
reference encoder count = -17521654
the robot will calculate the real world angle (within one motor rev)
in a Zero mastery you are providing all of the information.
real world angle ZERO (probably not)
real world encoder count = 285255646
master angle = ZERO (because you told it to)
master encoder count = -17521654 = this number recalculated by based on the robot form factor.
this changes the relationship between zero degrees and the encoder count.
fanuc makes a couple of tools to recover mastery on robots, the fixture mastery involves replacing the EOA with some dial indcators and touching off of the robots base. they have iRCalibration to do it with cameras. i have not worked with it yet, but i hear it works great as long as you have the space in your cell. otherwise you are left with setting up a reference point somewhere in your cell that is saved in JOINT representation so that when the world frame is recalculated it still attempts to go to the same point in physical space. put a dial indicator or a feeler gauge and there and run the robot there. adjust the joint in question untill it reads properly and single axis master it. this will NOT give you the correct mastery, but it will give you the SAME mastery that you had before which is what you want.
provided that the physical connection between the encoder/motor/reducer is exactly the same as when the image was taken. The above procedure will recover the robot regardless of the position relative to when the image was taken. i use this all the time when i am working on a production machine off shift. take an image before you start, and dump it back in when you are done with your shift.
the last thing you ever want to do is zero master a robot. you are never going to get it perfect, and even if you did, it is unlikely that it was perfect before.
if it is a frequent problem for a cell, consider automatically resetting the chain fault.
$MCR.$CHAIN_RESET=(SI[1:Fault Reset] OR UI[5:Fault Reset])
a more simple solution would be to put the values into a PR[#] and use it as a tool offset instead of a frame offset.
PR[1,6:Tool Offset] = PR[1,6:Tool Offset] + 8
L P[10:Original Point] 500mm/sec FINE Tool_Offset,PR[1:Tool Offset]
the MATRIX.PC program is included with the vision support tools option. possibly with some others as well.
the version i have can be set to the following fieldbus types:
i assumed the IO link that you were using was the CC-Link option.