The simplest solution is to standardize the Screw Numbers used between the robot and the PLC (HMI). You can prevent the robot from sending coordinate data or labels with non-existent register numbers by implementing restrictions on the HMI side.
Posts by saberlars
-
-
That operation level is at 2 which for all i know is the max and the Auxiliary function is incorrect input.
But when i open the aux function window it shows nothing but system and then Change operation level. So i think something is locked away for some reason. Any Idea why? And how to unlock it?
In Manual mode, if the basic AUX function menu appears grayed out, it is most likely due to user level restrictions as previously explained. All functions become available with Level 3 access. Since the method to obtain Level 3 access is not publicly available, please contact your local dealer network for technical support...
-
Check out
"0898 Change operation level"
"0897 Select Auxiliary Function"
Aux function enable / disable related each selected "Operation level" -
For devices like the E_Controller, there is a command called USB_LOAD (Load from memory stick). This allows you to load pre-written *.as or *.pg files. However, if a routine (Program) name is duplicated, an error will occur, so you need to delete it first using the 'DELETE /P' command before loading.
If you're using a D_Controller, it's also possible to load data from a PCMCIA (CF card). Alternatively, regardless of the controller type, if a PC is connected, you can control it using terminal software like KCWin32 with commands such as LOAD and SAVE.
If you only want to update coordinate values in real time, you can run a program in the background—either using the PCEXECUTE command or by registering it in AUTOSTART.PC—and have it receive data from the PC and apply it to the TRANS coordinates. Data communication is open by default via RS232C, so you can implement it according to the ASCII protocol. Alternatively, you can use the TCP/IP (Socket) method as well
Check out "AS Language" manual. -
Check out RSR enable & disable each numbers.
-
Main (RSR or PNS or STYLE)
CALL SubProg1
CALL SubProg2
CALL SubProg3Main
CALL Sub1
CALL Sub2
CALL Sub1 -> Logic ErrorIf a called TASK is called again with the CALL command before it ends with the END instruction, an error message will appear. The program needs to be reviewed.
-
.TRANS
cyl_ref[1] -489.942078 2070.860352 -29.955811 -178.842010 180.000000 0.000000
cyl_ref[2] -489.942078 2070.860352 -29.955811 -178.842010 180.000000 0.000000
cyl_ref[3] -489.942078 2070.860352 -29.955811 -178.842010 180.000000 0.000000
cyl_ref[4] -489.942078 2070.860352 -29.955811 -178.842010 180.000000 0.000000
cyl_ref[5] -489.942078 2070.860352 -29.955811 -178.842010 180.000000 0.000000
.END.PROGRAM sample()
.layer_z = INT(.quantity/4); Define layer
.height_z = 200; Layer to Layer
.ofs_z = .height_z * .layer_z; Final Offset
.index = (.quantity MOD 4)+1; Calc index (1~4)POINT part = SHIFT(cyl_ref[.index] BY 0,0,.ofs_z)
LMOVE SHIFT(part BY 0,0,50)
LMOVE part
CALL grip_unclamp
.quantity = .quantity+1
.ENDDon't forget define trans position with [ ] symbol.
-
What are you doing when the errors occur? Directly after booting the controller or when you run a program? Is your DSQC1030 unit running again? Did you try an I-Start?
This alarm has occurred either when executing the routine to return to the home position (even when the robot was already at the home position) or while waiting during the automatic cycle because a certain signal condition was not met. It seems to be related to an error or a judgment being made based on position data, but it's hard to pin down exactly what's going on.
I would ask for a replacement under warranty.
I contacted the robot service team in Korea, and they responded that downgrading to RW6.11.02 would be the least troublesome option. I plan to proceed with the work as soon as I get on-site tomorrow.
It may be a computer unit issue; seen odd software issues related to computer. Agree with Lemster68 on contacting ABB. Did find this note in manual regarding RW6.15:
I also believe it's a computer-related issue. I'm hoping that the [Internal Error] won't occur after the downgrade
-
The robot was initially running on RW6.15 at the time of delivery. After a reboot, a message repeatedly appeared indicating that the DSQC1030 unit was deactivated. As a result, we updated to RW6.16. However, due to multiple occurrences of internal errors after the update, we have currently downgraded to RW6.14.
We are still experiencing intermittent internal errors and are looking for a solution.
This robot is a brand-new unit, recently installed for a new project.
It is an IRC5 Single controller.The most frustrating part is that it’s unclear whether downgrading to RW6.14 is actually a viable solution. Ideally, newer RW versions should offer greater stability… I sincerely hope that the lack of reliability is just my personal impression.
-
Can I ask you also which versions of Robotstudio are you using?
I suspect that the schema reference location might be incorrect.
-
It’s not working... I suspect there might be a compatibility issue with the RobotStudio version.
-
I have added the package, but I cannot find the related functionality in the Ribbon menu section. What is it used for? -
What is the selected robot startup method?
Should it be set to the RSR method?
Please check on the Menu - SETUP - Prog Select screen.
Are there any other alarm logs? -
Check Connection.
Isn't there another event message? Please check the entire event log
-
I have never used the DHCP function, so I am not sure. I am using it by assigning a private IP like this.
-
Did the CVIS-156 error occur when executing the RUN_FIND command?
-
thank you robcad sim for these information but i'm confused :
Indeed My first PR is register as "Joint" but my program allow to use Tool_offset,PR on this.
7: UFRAME_NUM=1 ;
8: UTOOL_NUM=1 ;
9: PAYLOAD[1] ;
10: !Approach N-2 ;
11:J PR[1:take_conv] 100% CNT100 Tool_Offset,PR[99:Offset_Z-100mm]7 Offset,PR[]
3 Tool_Offset,PR[]
This swith parameter only allow "Cartesian (XYZWPR)" position dataUFRAME_NUM = 1
UTOOL_NUM = 1
PR[60] = JPOS
PR[70] = LPOS
PR[70,1] = 0
PR[70,2] = 0
PR[70,3] = -100
PR[70,4] = 0
PR[70,5] = 0
PR[70,6] = 0
L PR[60] 100mm/sec FINE
L PR[60] 100mm/sec FINE Tool_Offset, PR[70]
Even if the reference position value is recorded in Degree format, the additional parameter options must always refer to Cartesian values. When moving to a position that contains Degree data, pressing the POSN button on the Teaching Pendant and switching between JNT, USER, and WORLD modes will show that the robot is always calculating all three frame data. This is why it is possible to apply a Cartesian offset to a Degree value.
-
-
nIndex := 0;
MoveJ p10{nIndex}, v1000, z50, tool0;Alarm number 10021 is often triggered when alarm 10020 has been activated and then cleared. Please check the full event log.
To simply trigger alarm 10020, if the "nIndex" value is 0, the system cannot reference the array, resulting in an "Execution Error" state. This returns alarm 10020. If this state is then reset by receiving a System Input assigned to the "Reset Execution Error Signal" parameter, alarm 10021 is returned, indicating that the error state has been cleared.
-
Robotstudio
(Left treeview)
Controller - Type - Run mode settings
AutoToManual Single
ManualToAuto Continuos