As far as I know, a few automotive manufacturers are able to run different F numbers between the cabinets and controllers on certain spray lines. This is likely a unique and proprietary setup. Not the news management wants to hear.
Posts by fastfingers
-
-
This isn't the easiest one to solve...
If you have a newer controller, you can setup a digital output for 'Program Aborted' on the Cell Interface I/O screen and you'd know if an Abort All has taken place, then RUN the timer program if the aborted output is on. I don't recall if the aborted output will remain on if you restart the main loop. If it doesn't stay on, its state could be captured with a flag using bg logic. This isn't the best solution and it's getting a bit sloppy.
I looked around in the docs for a variable that tracks multitasking programs and didn't have any luck.
-
Can you issue the the RUN above the loop to avoid the error? I'm guessing this would cause another problem.
-
I've done this before by turning on a flag at the top of the RUN program and turning it off at the end of the RUN program. You can then monitor the flag status and use that information to RUN the program with the timers again.
I'm not sure if there are variables that can be used to monitor the status; hopefully, others will chime in.
-
Quote
In looking how to find the search tool on the webserver, I actually stumbled upon a "Find and Replace" tool through the teach pendant. In OLPCPro, under the Teach tab, it has a find and replace window that shows you which program it is in and what line of code it resides. You can even limit which program you are searching.
dixon20, I looked in Roboguide and found this tool. It works nicely and will be a huge time saver. Good find!
-
This was due to MAINT pressing Abort all and then pressing cycle start on the HMI.
The 1st call program in MAIN is PR[1:HOME POSITION] so the robot took the shortcut back home- Causing Chaos!
I've had this issue before and it is no fun. I did the same things motioned above: LPOS and monitor DCS and/or reference positions to figure out where in space the robot is and how to get it home.
On one installation with 4 motion groups in a rotisserie setup:
1. The operator needs to get the robot or other axes home after an e-stop condition or something else that left them in a place other than home
2. Abort all is required. This is done to prevent the HOME program from running (or possibly running) every time the loop restarts as this cell is pretty complicated.
4. The operator presses a button on an HMI screen to run the HOME program
4. Monitoring UOPS (if I remember correctly) will show that the robot has been aborted and will allow the HOME program to execute
5. Monitoring system variables, if the robot has been jogged by a human since the last motion instruction, the HOME program will end and display a screen that says the robot or another axis has been jogged and will have to be moved home manually. This is done to get the robot home from a general area where we can expect the robot to be during normal operations. I was unable to account for all the possibilities the robot may have been jogged to. The other 3 motion groups were rotary and fairly easy to get home.
6. Operators and maintenance are instructed to never jog anything on this cell unless they have tried to abort and run the home program. One of the very few times an abort all is encouraged.
Hope this helps...
-
Add the .stm file to the 'Files' folder in the Roboguide cell browser, then right click on the .stm file and click on 'Load'. You can then add the .stm file as a favorite in the browser menu on the virtual TP (same way it is done on a real robot) and the page should display.
-
Does this robot have a second servo amplifier and an aux or process axis?
-
Per the HandlingTool manual, calibration applies to axes 5 and 6 and accounts for differences in the servo motors and gearboxes, etc. from one robot to the next. Assuming you have the auto payload ID option on this robot, you need to run calibration before any payload schedules are set up. With no tooling or dressout on the end of arm, set calibration status to ON and execute. The robot will move J5 and J6 through some simple motions to perform the calibration. When it is done, calibration status will change to done. Read up on this in the manual before you get started so you know how to position the robot before you start and how it will move during calibration.
-
Use R[n]=$MNUFRAME[n] with 'n' replaced with the motion group number. Probably 1 in most cases.
-
This is good info. Thanks everyone!
-
HawkME and Fabian both mention risks and I am curious as to what issues you two have seen when performing software updates. The CRC seems to push the software updates to solve problems for which they can't find a straightforward answer. In my experience, I had one update that couldn't complete; I reloaded an image I took before the update and all was good. It ended up that a corrupt file on the controller caused the original problem and also caused the update to fail. Have you two experienced worse than this? Thanks in advance for your responses.
-
Sounds like SHIFT_Lock might be onto something... An aux axis needs a separate set of batteries for the pulsecoder(s) and they are typically mounted on the controller cabinet door. Are the batteries in the base of the new axis functioning?
The SRVO-068 DTERR alarm also mentions the pulsecoder could be faulty. Do you know if the pulsecoder worked before?
-
You need the original core software card that shipped with the robot when it was new. This will be either a PCMCIA card or a USB memory stick. Do you have it? If you don't have the core software, you might be able to reconnect the old pendant (if you still have it) and backup the firmware. If you already have a firmware backup, you can then use that to update the new pendant's firmware. Firmware backups, to the best of my knowledge, are separate from an 'all of the above' backup and there is a specific procedure to backup the pendant firmware. Fanuc would be happy to reburn the core software for a fee if you don't have the original core card.
-
Controlled start>Maintenance>Upgrade iPendant software>Update whole firmware>Select source device.
The manual warns that the update might take a long time. In my experience, it has never taken longer than 15-20 min.
-
Update: I found the iPendant firmware update procedure in the HandlingTool documentation.
-
You probably need to update the iPendant firmware. The firmware is located on the core software card that originally shipped with the robot when it was new. The documentation (controller maintenance manual, I believe) covers the procedure very nicely. Changing teach pendants is typically the cause of the issue you are experiencing.
-
I have found that Sharepoint works pretty well to generate the HTML code needed for custom HMI screens. If you're really good (unlike me), you can write the code in a text editor. The iPendant Customization Guide does a pretty good job outlining what needs to be done.
-
I agree. I'm thinking the failures are somehow related to scale and/or training stability.
-
One thing I see is the training stability for location is 'P' which means poor. This could be contributing your problem. Maybe reteach the locator tool and try to improve the location stability? You could copy this whole vision process and modify the copy, keeping the original as-is so you have something to refer back to. The contrast seems a fairly low; are you able to improve it? One other thought is to check the aspect box and leave the values of 98 and 100 for min/max. You are currently expecting the process to find the same exact image with no 'tilt' or aspect skew and this may be difficult due to the poor location stability.