Does anyone know what system variables are changed in addition to $MCR.$GENOVERRIDE when turning the speed to FINE and VFINE? I know $MCR.$GENOVERRIDE remains at 1.
Thanks
Does anyone know what system variables are changed in addition to $MCR.$GENOVERRIDE when turning the speed to FINE and VFINE? I know $MCR.$GENOVERRIDE remains at 1.
Thanks
One small correction to the comments below: you can also map your UI and UO to digital inputs and outputs in addition to flags (ie, map the UO to inputs, and the UI to Outputs. . These would be mapped to rack 0 then. The rest, as everyone said, is up to you.
The fence fault will write a specific error code. You can write the error codes to a register, and when the register is equal to the specific code, you could execute your logic in your bg logic program. Alternatively, in your ES, you can configure an output to the fence signal.
Do you want to see them actively update or just look at a static value? If static, you can browse to the robot homepage on a pc and view IO states. You need to set up the host comms (menu--> setup --> Host Comm) and enter the appropriate ip you would like to use.
Anyone yet decipher the actual modbus addressing for the robot for use with a generic driver? I found an old GE/Fanuc Doc which has some info which I will try. It would sure be nice to know the actual addressing instead of having to rely on the 30/90 driver, as that could open up a whole host of options.
I have used a Proface HMI to make free remote IO, for instance. You can write logic in it. I wrote the fanuc io bits to output bits to a separate PLC, essentially working as remote IO. This would be more streamlined and usable if I knew the actual addressing.
Autobackup is a crapshoot for sure. Generally the only way to get out of that scenario is to do exactly what you did. If available, I prefer doing autobackups using a CF card, as it has been historically more stable for me. Also, if using usb, i prefer using UD1 (controller usb), not UT1 (teach pendent usb). UT1 has been the most unreliable for anything.
Thank you both. I gathered any variables declared with "$" are system variables. Fanuc is structured similar. Similarly, one can cause some serious issues changing or deleting the wrong sys var. They are accessed in completely different ways though. Now, in fanuc's tp (teach pendent programming), only system variables that are of integer type are accessible via programming through the teach pendent. If you want to access any other variables (strings, arrays, bools), you need to use Karel (not surprisingly, very similar to KRL).
I do like the fact you can utilize a robot moving signal in Autoexternal. That is a feature Fanuc should get behind! You can access some system variables in fanuc, but you have to get crafty with your code. A combination of variables in fanuc can be utilized to tell if a user manually jogged the robot. You need to be sure to reset your logic in your main program, but it comes in hand for homing etc. Is something like this available and accessible in the Kuka?
Regarding $INs an $OUTs, is there a maximum number declared by default, or is this assignable? In the fanuc, if you want to use any internal signals, you must assign them to digital inputs or digital outputs. The default number available is 512, but you can increase this to 1024 (I haven't tried assigning more in the past couple years, but this may or may not have changed), really a small amount in the scheme of things. All the other system IO must be assigned to the same digital inputs or outputs. Of course, for most cells, this is not an issue, but large systems can consume that pretty quick.
As far as workvisual goes, I believe in archiving frequently, and I do plan on archiving last backups prior to pulling new from the robot. That way if I do overwrite the old file, I still have a record of it.
Now, when loading a Workvisual project to the robot, are things like robot calibration copied over too?
Sorry, as I go along I may ask more questions, as
I must say, the Kuka is a lot different animal than ABB or Fanuc, but Workvisual seems like it will be pretty nice. I have a lot to learn; a lot of idiosyncrasies to be sure, but it seems like a decent platform. I only wish modifying logic on the pendent was a bit easier and faster. Once I learn the tips and tricks though, it shouldn't be bad.
Again, thanks.
Panic Mode,
I did read "Read First."
I have the Programming manual for system integrators. It does have a lot of good information, but definitely seems to be lacking in details, or the details don't quite match up super well with the robot pendent (there were a few small items). That said, some of the verbiage passed around is also a tad bit different, so I was looking in some of the wrong spots. Thanks to the manual and everyone's help, I was able to accomplish my goal today though, and I learned a lot in the process.
1. I successfully backed up the WOV project.
2. I saved said project with revision notes and the date/time for revision integrity.
3. I set an output that is on when the robot program is running. Instead of directly using $Pro_Act and changing the I/O configuration (just in case the signal was used somewhere else - I didn't check YET (yes, I will though), I instead modified the submit interpreter program (sps) and added a line of code "$DO[22] = $DO[8]. It worked well and doesn't mess with the integrity of the program (again, until I look up all instances of $Pro_Act and $DO[8], it is the SAFE way to modify the program (I did already look for any and all instances of $DO[22], of which there was none).
4. I backed up again and saved for revision integrity again.
I started reading the manual a lot more - both the Workvisual and programming manual.
Now I can finally look at re-configuring the output card I must replace.
Thanks Skyfire.
So I found the settings in the Diagnostics, as per the manual. I didn't see a place to modify those settings. The robot was being used at the moment though- maybe this is why?
Also, the $Pro_Act output is currently assigned to output 8, which is configured as a system output. If I do change this output to a different IO point, will it have any effect on any other aspect of the operation of the robot? I didn't look at the written code, obviously that could be an issue if it is used, but I want to make sure there wouldn't be anything else to surprise me..
Also, can I just change this in WorkVisual and upload the changes?
Panicmode, what is the best manual to get? I have KSS 8.2 programming manual, but it lacks a lot of the technical details such as the info you exchanged above. I would like to download the best and most applicable manuals so I don't have to bother people with questions, but I don't know which manuals those should be, and which ones are applicable to my software (V 8.2).
Kris
: string[1] - this means your string is a single character long
READ file_com (str::1) The colons control how much data will be read. In this instance, just 1 character will be read from file_com and that data will be saved in the variable str (which was a variable type of string 1 character long)
i = i + 1
endif
until i > 106 ********how many iterations do?? This will repeat until the integer, name "i" is counted up to 107. Somewhere the value of i should be declared in some way or fashion. It is missing in the code below, but it is indexed in the statement i=i+1
-- Obtengo los parĂ¡metros de rutina TP ************ is collecting parameters that are written in the TP? The easiest explanation is this. If you have a program call with arguments (example CALL HOME(2,3), the get_tp paramter 1, would be the first argument, which has a value of 2. The rest of the statement is resolving the data received
GET_TPE_PRM(1, data_type, int_value, real_value, str_value, status)
THe above is getting argument 1, data_type will be populated with the type of data the parameter is (example, the above is an integer, so data type would be 1), Since it is an integer, the value will be saved in int_value (which would have needed to be declared above). If the argument was, for instance, 2.2, the data type would be 2, if I recall. The value would be output to real_value, etc. Status will get populated based on if the statement completed successfully.
If you don't have it yet, I do recommend getting the karel manual from edocs.
I 2nd the DCS option, or basic interference check. Basic interference check is a much cheaper option and a little simpler to learn and implement. It does NOT offer a "safety" rated level of protection however, but that may not be an issue assuming your current system already has a safety fence that is adequately positioned.
Newegg, ebay, best buy are all good options. Theres nothing special about the adapters. Very old robots are limited to 1Gb flash drives. Keep that in mind, as small CF cards are getting difficult to find.
Can you tell us how the tool is mounted on the faceplate? Is the screw perpendicular to the faceplate? Is is parallel? Is it parallel and rotated? Also, is the robot itself level? Usually none of these scenarios pose much problem. but once in a while they do. It shouldn't be an issue if you are jogging in World in the X,Y,Z planes alone, but if you happen to be jogging in User in a frame that is not perfectly straight it could be.
Also, have you looked at your frame data to see how it looks? Is there data in the W,P, and R data? Menu-Setup-Frames-Type User, select the applicable frame you are having issue with and look at the data.
Sometimes, when touching off, your Z height is off a tiny bit and this will induce some angle into your frame. I have already manually adjusted the frame data and zero'd it out in a couple instances.
You can mask the groups after creating a program so long as there is no positional data saved in the program. Removing the positional data is the "difficult" part, as you may need to delete then re-load the program after modifying, as the positional data doesn't just disappear when you delete your positions. If you have ascii loader or roboguide, you can delete the positional data from the .ls file directly.
Just a tip if that situation ever comes up.
How are you teaching your tool frame? How is your eoat mounted? We have observed if the tool is mounted in rotation on the eoat (ie, you must have J6 rotated to have your tool in "normal" posture[done to help avoid singularity in many cases]) when teaching tcp using any manual teach methods will lead to a tcp with close X,Y,Z values (often don't have a point to touch up on in space), but W, P, and R's that are completely incorrect. This will be very noticeable if jogging the robot in "Tool," as your X, Y, and/or Z jogging will not be perpendicular or parallel to the tool. You can see this if you model the tool and exact data in Roboguide.
For the most accurate TCP, I always recommend getting it from solidworks and direct entering it. Again, build a cell in roboguide with this same information and adjust W, P and R to correct your trajectories if you like.
KK
As we had a lot of systems in the field that suffered from loose lenses due to vibrations, we started putting a bead of silicon on the camera across the lens assembly. This works super well and can be removed if the camera needs to be changed.