Posts by RustyRSA
-
-
In which direction? Parallel to the linear axis, or otherwise?
Over 10m, very tiny errors can multiply. My first test would be to duplicate the calibration point at multiple locations along the length of the rail, and test for accuracy at each one, using:
1. use anti-backlash motion of the rail at each position before measuring
2. Keep the arm pose identical
See if the positional error is constant over the length of the rail, or if it varies. If it shows a linear progression along the length of the rail, then your $RAT_MOT_AX is probably very slightly incorrect. I've had this happen a lot.
You need to use anti-backlash on the rail (and even on the arm) to ensure that this test is 100% valid.
A further step would be to repeat the test but deliberately inducing backlash on the rail by approaching the same target point from opposite directions. The degree of effect this can have is often surprisingly large. I've often had to write my programs with anti-backlash routines to protect against this.
OK - I checked the gear ratio and it's fine. If I tell the E axis to go 10 meters is does - physically measured on the rail. I had to adjust the gear ratio in Work Visual axis properties. As a matter of interest I can't find the $RAT_MOT_AX variable in my Work Visual project.
-
In which direction? Parallel to the linear axis, or otherwise?
Over 10m, very tiny errors can multiply. My first test would be to duplicate the calibration point at multiple locations along the length of the rail, and test for accuracy at each one, using:
1. use anti-backlash motion of the rail at each position before measuring
2. Keep the arm pose identical
See if the positional error is constant over the length of the rail, or if it varies. If it shows a linear progression along the length of the rail, then your $RAT_MOT_AX is probably very slightly incorrect. I've had this happen a lot.
You need to use anti-backlash on the rail (and even on the arm) to ensure that this test is 100% valid.
A further step would be to repeat the test but deliberately inducing backlash on the rail by approaching the same target point from opposite directions. The degree of effect this can have is often surprisingly large. I've often had to write my programs with anti-backlash routines to protect against this.
Oh - and parallel to the linear track.
-
Simple stuff to check for:
- when you read out the values when you jog vs. your program double check you're using the same tool and base values.
- Possibly touch up your tool / re-teach your tool
- check that your rail is flat. you may have a low spot where your checking?
- same goes with your work surface (base). When you teach the base it's just 3 points. Could very well be a low spot along such a distance. In the past with large work surfaces I've used RSI and a force torque sensor to help guide the piece to flat with the working surface.
I have a strong suspicion you're dealing with a low spot with such a distance.
Thank you - no low spots - we have used lasers to ensure this is the case - it's a progressive change along the length of the 10 meters. Always use the same tool and base. Thanks. Tool has been retaught and also checked on PowerMill.
-
In which direction? Parallel to the linear axis, or otherwise?
Over 10m, very tiny errors can multiply. My first test would be to duplicate the calibration point at multiple locations along the length of the rail, and test for accuracy at each one, using:
1. use anti-backlash motion of the rail at each position before measuring
2. Keep the arm pose identical
See if the positional error is constant over the length of the rail, or if it varies. If it shows a linear progression along the length of the rail, then your $RAT_MOT_AX is probably very slightly incorrect. I've had this happen a lot.
You need to use anti-backlash on the rail (and even on the arm) to ensure that this test is 100% valid.
A further step would be to repeat the test but deliberately inducing backlash on the rail by approaching the same target point from opposite directions. The degree of effect this can have is often surprisingly large. I've often had to write my programs with anti-backlash routines to protect against this.
1. OK - I'll re-check the track calibration and make sure anti-backlash is used.
2. The arm pose is always the same A1: 90 A4:0 and A6:0
3. I'll check the $RAT_MOT_AX but I have actually measured the movement of E1 physically and it is a perfect 10 meters.
4. I'll try other options. I have also set my ROOT position of they robots so that my $WORLD is in between the robots at the X=0 position (a reference point for start of work envelope)
-
Hi,
We are installing a client system with dual Linear Rails - I am working on one rail at a time.
The issue I have is this.
1. I am using a KRC4 controller.
2. The rail/track is custom built - connected on the E axis and part of the kinematic chain.
3. We have a 10 meter measure on the physical track and in the workplane area - and have set gear ratios accordingly.
4. The tool we are using has been calibrated on the controller and PowerMill - both concur.
5. If I set the tool tip (a calibration spike) to the 10 meter mark on a point on the workplane and the the robot to halfway down the track the X-movement is perfectly calculated by the controller and matches a physically measured distance.
5. However when I program a point to meet the calibrating position at 10 meters there is at lease 5mm+ on the one track and 2mm- on the other.
How can this be so - when we orient the robot into the workplane and jog it along the rail from one measured point to the next the values displayed on the SmartPad match those measured physically?
Please can someone provide some guidance on what may be causing these discrepancies?
Thank you.
-
Greetings Forum. There are bits and pieces of information on the forum and I can't quite connect where my problem is.
I am trying to program 4 PTP movements using the 4 status buttons on a KRC4 controller.
I have the following .src file which runs fine as a module.
Quote; Created by Titch Taylor 15 Apr 2024
; Run as .src file from TP
; Basic Code compliment Panic Mode
$FLAG[15] = FALSE
$FLAG[16] = FALSE
$FLAG[17] = FALSE
$FLAG[18] = FALSE
LOOP
;FOLD +> Status Key detection
; check if status key is pressed
$FLAG[11] = is_key_pressed(14)
$FLAG[12] = is_key_pressed(15)
$FLAG[13] = is_key_pressed(16)
$FLAG[14] = is_key_pressed(17)
; detect rising edge of the button press
; by comparing current and previously saved state
$FLAG[1] = $FLAG[11] AND NOT $FLAG[15]
$FLAG[2] = $FLAG[12] AND NOT $FLAG[16]
$FLAG[3] = $FLAG[13] AND NOT $FLAG[17]
$FLAG[4] = $FLAG[14] AND NOT $FLAG[18]
; save current state of the button to check toggle
$FLAG[15] = $FLAG[11]
$FLAG[16] = $FLAG[12]
$FLAG[17] = $FLAG[13]
$FLAG[18] = $FLAG[14]
;ENDFOLD
; allow status keys to control some outputs
; but only if in T1 and drives are enables
;FOLD +> Status Key control
;IF $T1 AND $PERI_RDY AND $USER_SAF AND NOT $PRO_ACT THEN
IF $MODE_OP == #T1 THEN
; for momentary state change (toggle) use flags 1..4
IF $FLAG[1] THEN
;Pointloader and System track Home
;IF $PERI_RDY AND NOT $PRO_ACT
IF $PERI_RDY THEN
PDAT_ACT=PFast
FDAT_ACT=FTravel
BAS(#PTP_PARAMS,100)
PTP xHome
ENDIF
ENDIF
IF $FLAG[2] THEN
;P1
IF $PERI_RDY THEN
PDAT_ACT=PFast
FDAT_ACT=FTravel
BAS(#PTP_PARAMS,100)
PTP XHome1
ENDIF
ENDIF
IF $FLAG[3] THEN
;P2
IF $PERI_RDY THEN
PDAT_ACT=PFast
FDAT_ACT=FTravel
BAS(#PTP_PARAMS,100)
PTP XHome2
ENDIF
ENDIF
IF $FLAG[4] THEN
;P1
IF $PERI_RDY THEN
PDAT_ACT=PFast
FDAT_ACT=FTravel
BAS(#PTP_PARAMS,100)
PTP XHome3
ENDIF
ENDIF
;for continuous outputs use flags 11..14
; Put operations here
ENDIF
;ENDFOLD
ENDLOOP
END
I then modify it to run using the sub interpreter using the code below and get all sorts of errors - I have commented out the BAS instructions for obvious reasons.
The error when running the sub interpret is two fold.
I get a message waiting for non LoadFirstArray - which won't go away and then 'invalid command'
Quote; Created by Titch Taylor 15 Apr 2024
; Called from sub interpreter
; Basic Code compliment Panic Mode
;FOLD +> Status Key detection
; check if status key is pressed
$FLAG[11] = is_key_pressed(14)
$FLAG[12] = is_key_pressed(15)
$FLAG[13] = is_key_pressed(16)
$FLAG[14] = is_key_pressed(17)
; detect rising edge of the button press
; by comparing current and previously saved state
$FLAG[1] = $FLAG[11] AND NOT $FLAG[15]
$FLAG[2] = $FLAG[12] AND NOT $FLAG[16]
$FLAG[3] = $FLAG[13] AND NOT $FLAG[17]
$FLAG[4] = $FLAG[14] AND NOT $FLAG[18]
; save current state of the button to check toggle
$FLAG[15] = $FLAG[11]
$FLAG[16] = $FLAG[12]
$FLAG[17] = $FLAG[13]
$FLAG[18] = $FLAG[14]
;ENDFOLD
; allow status keys to control some outputs
; but only if in T1 and drives are enables
;FOLD +> Status Key control
;IF $T1 AND $PERI_RDY AND $USER_SAF AND NOT $PRO_ACT THEN
IF $MODE_OP == #T1 THEN
; for momentary state change (toggle) use flags 1..4
IF $FLAG[1] THEN
;Pointloader and System track Home
;IF $PERI_RDY AND NOT $PRO_ACT
IF $PERI_RDY THEN
PDAT_ACT=PMed
FDAT_ACT=FTravel
;BAS(#PTP_PARAMS,100)
PTP xHome
ENDIF
ENDIF
IF $FLAG[2] THEN
;P1
IF $PERI_RDY THEN
PDAT_ACT=PMed
FDAT_ACT=FTravel
;BAS(#PTP_PARAMS,100)
PTP XHome1
ENDIF
ENDIF
IF $FLAG[3] THEN
;P2
IF $PERI_RDY THEN
PDAT_ACT=PMed
FDAT_ACT=FTravel
;BAS(#PTP_PARAMS,100)
PTP XHome2
ENDIF
ENDIF
IF $FLAG[4] THEN
;P1
IF $PERI_RDY THEN
PDAT_ACT=PMed
FDAT_ACT=FTravel
;BAS(#PTP_PARAMS,100)
PTP XHome3
ENDIF
ENDIF
;for continuous outputs use flags 11..14
; Put operations here
ENDIF
;ENDFOLD
END
Please can someone guide me on what needs to be done?
-
We have a Fanuc styled (G&M Codes driven) Plasma Cutting robot that I need to repair.
The system 'controller' is made up of a number of components from various manufacturers.
But I have a problem in one area that is driving me dilly.
There are a number of Panasonic MBDLN25SG drives in this unit with a matched Panasonic MHMF042L1U2M motos.
I have reset the drive using the Panasonic PANATERM software (v6.x) directly on USB to the drive and running the drive in Position Control Mode (P).
When I switch the drive on and monitor the status with PANATERM it comes up as normal and no alarm BUT the 'Troubleshoot' options shows I have CP07 (Factor of No-Motor running) condition. Also monitored on the drive monitor d17.ch.
This occurs even before I try any operation from the HOST (other than hard wiring SRV-ON to be active after the drive switches on).
The manual 'Factor of No-motor running' says this condition is as a result of the Command pulse input frequency being too low and is result of;
The position command per each control cycle is 1 pulse or smaller due to,
• No correct entry of command pulse
• No correct connection to the input selected with Pr0.05.
• No matching to input status selected with Pr0.06 pr Pr0.07.
From the manual this condition suggests I have a configuration problem with the following drive settings;
Pr0.05 =1: Exclusive Input for Line Driver
Pr0.06 =0: Command pulse rotational direction setup
Pr0.07 =3: Pulse Train + Signal (PULSH and SIGNH)
Other relevant settings;
Pr0.01 =0 Position Conrol Mode
Pr5.04 =1 Over-travel inhibit input
Pr5.17 =2 Counter Clear Input Mode
Pr5.18 =1 INH input deactivated
I am using the following connections from the drive to the HOST
DRIVE HOST
PULSH1 (Pin 44) S+
PULSH2 (Pin 45) S-
SIGNH1 (Pin 46) D+
SIGNH2 (Pin 47) D-
ALM+ (Pin 37) Input of HOST
SRV-ON (Pin 29) Output from HOST
COM+ (Pin 7) Power supply + from HOST (+24V)
COM- (Pin 41) Power supply - from HOST (0V)
BRAKE+ (Pin 11) There is no BRAKE on the motor so not used at this stage
If I monitor values on the drive for the following all seems fine;
SRV-ON - the drive picks up the change in state so no problem there.
d06.cPS Command Pulse Sum I get a constant command pulse incremental value on the drive display for each mm moved from the HOST - both positive and negative values are displayed if I move negative or positive from the host.
d05.nPS Feedback pulse sum I get feedback from the encoder in resolution pulses,. All fine there.
I have also cleared Absolute data and zeroed the counter values.
Everything seems to work fine from the HOST except the Motors won't come on and no matter what I change on the drive I still get the CP07 issue (monitored on the drive via d17.ch).
If I remove the SRV-ON signal to the drive then the Factor of No Motor goes to CP02 (monitored on the drive via d17.ch) - which is correct. So the SRV-ON side of things is working.
Is there something I am missing and can someone please help.
-
Hi Panic mode.
Thanks - Panic Mode - I have tried Advantech's web site and cant find the Device Manager pack needed for this motherboard. I have raised a call with Advantech and hope they can help. I'm not getting much joy from Kasry in China.
-
I have an update. The serial ports are connected directly onto the motherboard (RS232 ports) for both hCom1 and Com2. Now I am looking for the device manager CD or drivers for the motherboard which is a;
Advantech AIMB-562 Kiosk Rev:A1
TO1435BAOM-A-4
P/N: 19A7B56220-01
AKAK242761
96AD945G31-0B002A-1
Model: AIMB-562L
I have the manual just looking for the device drivers.
-
Dear Forum Members,
This post is a bit all over the place and I apologies for the quantity of information.
We have a Kasry/Yomi machine which we have been repairing for our customer in South Africa. The drive crashed and we have spent some time restoring files from a C_PAN.GHO image we have. The unit is made up from a number of supplier parts (Panasonic, Delta TAU, Keyence, Kasry and then some smaller bits). In a nutshell it is technically a CNC robot in component form.
The Robot setup has the following components;
1. A Kasry provided PC with the following software;
(1A) Windows XP 32 bit SP3 - I can't get away from this.
(1B) Microsft.net 3.5
(1C) 111.exe (KASRY 360 Robotcut.exe) and FACE.exe the main cutting design and program 'post processor' program (mostly in Chinese). These are Chinese based applications without available documentation. I have tried the supplier (Kasry) and little comes back from them). When I run this and try to read the encoders from the drives it reports a serial port error. This has something to do with the two RS232 ports in the PC - as one port is connected to the drives through an RS485 hub.
(1D) Pewin32 Pro which is working fine and we can access the drives and certain I/O (This is a Panasonic piece of software used as an interface to setup and monitor the PMAC2 unit.
(1E) PipViewer 1.07 with SoftDog USB key unit installed. This is a piece of software that takes .pip files for viewing. I have an issue with this as it keeps coming up with attempted operation not supported error.
(1F) FAST wireless USB unit - no problem here
(1G) CH341SER – not sure what this is used for in the system but it's a USB/serial driver.
2. The following hardware has been established
(2A) Delta TAU Turbo PMAC2 CPU Configuration (I4908) (DSP56303 CPU) (Part Number 0964) (Ver 1.947)
(2B) 8 x Panasonic Motors connected to Panasonic Drives
(2C) 8 x Panasonic A6SG series Drive Controllers
(2D) 1 x PMAC ISA Motion Controller used for RS485 motion control communications?
(2E) 1 x Turbo PMAC2 PC drive controller unit interfacing to drives
(2F) Dual RS232 PC card (Port1 connected to Laser Sensor and Port 2 to Panasonic drives through RS485 hub to X2 of drives)
(2G) Direct Ethernet connection from PC to PMAC2
(2H) A Delta TAU separate PLC (DVP-64EH) - not worried about this as yet.
(2I) A Keyence Laser Sensor with an RS232 interface to the Kasry PC Port 1 of the RS232 card (on the PC not the PMAC2). This connects to a Keyence IL-1000 laser measurement scanner.
3. I have checked Windows devices with an old printout I had from the original working unit - against the current installation - and they seem fine.
4. We have the following issues we would like some advice on;
(4A) When I select the button ‘Read Absolute Encoder and Loading RCS button’ I get a ‘cannot open serial port’ message – please advise
(4B) I cannot get a version of Panaterm 6.0 to install on the XP SP3 PC to read the configuration on the servo drives – any suggestions/recommendations?
(4C) I need to read the Keyence laser device (through the RS232 port) – please advise drivers and any software that could do this.
We have made good progress in getting this machine to work and would welcome any support to get this machine over this final hurdle.
Many thanks
RustyRSA
-
Do you mean, it's connected directly to the KRC through the X42 connector?
AFAIK, that's only relevant when the MasRef switch is connected to a Safety PLC, and the Safety PLC program passes the MasRef contact signals to the KRC via the JR bit.
Yes - I understood the JR bit was only relevant to a PLC. Thanks for clearing that up.
Yes - the Reference Switch is connected directly to the KRC through the X42 to the CCU.
-
Then, how is the MasRef switch connected to the robot?
Through the CCU (CIB). But I see panic mode suggests monitoring the JR bit - I'll have a look at it.
-
I have tried using the diagnostic monitor see SafeOperation_1.bmp and SafeOperation_3.bmp but can't seem to get a real-time result when placing the steel piece over the proximity sensors.
Please note there is no SIB in this unit.
I also struggle sometimes with the German references in my notes.
Mastering reference switch does not connect to SIB. It connects to CCU, more specifically to CIB (CCU=CIB+PBM). so if there is a live status, it will be in diagnostic monitor for CIB and it will refer to JR.
Thanks. I know the reference switch doesn't connect to SIB - just mentioned that for background. I'll look at the JR bit. Thanks
-
That's possible. In diagnosis menu, and should do the task.
I have tried using the diagnostic monitor see SafeOperation_1.bmp and SafeOperation_3.bmp but can't seem to get a real-time result when placing the steel piece over the proximity sensors.
Please note there is no SIB in this unit.
I also struggle sometimes with the German references in my notes.
-
Hi Panic Mode and Skyefire,
Quote
What are you trying to accomplish?What I am trying to do is find a quick way to see the status of the proximity switch by simply placing a piece of steel over the proximity sensors and checking their status on the KRC4 Smart Pad.
-
Hi All,
Is there a direct way to monitor the status of the Proximity Switches (part of the KRC4 Safe Operation Reference Switch).without running the Safe Operation programs?
I am assuming the 2 proximity switches must be mapped somewhere to the internal Kuka I/O. I have searched on the TP and Work Visual with no luck.
We have Kuka KRC4 controllers with the option package Safe Operation 3.x installed.
Controllers are KRC4 8.3.x
There is only one Reference Switch connected through X42 to the CCU.
I have examined MasRef_Main.SRC, MasRef_User.SRC and can't seem to find an I/O reference for the 'proximity switch status'.
I see there is a Safe Operation $MASTERINGTEST_SWITCH_OK variable but that's just the condition of the Reference Switch and not the two individual proximity switches.
Any guidance would be most appreciated.
-
OK - so it looks like I can't interface the encoder directly with the Panasonic drive and that I need something in-between like a Kuka RDC?
These are the signals on the Kuka encoder
Stator Excitation
pin 7 R2
pin 10 R1
Stator (SIN)
pin 1 S2
pin 2 S4
Stator (COS)
pin 11 S1
pin 12 S3
RTD (Temperature)
pin 8 +1R1
pin 9 -1R2
The Panasonic drive only has these encoder inputs on a 6pin connector;
pin 1 E5V
pin 2 E0V
pin 5 PS
pin 6 PS(NOT)
pin 3/4 not to be connected.
Any suggestions?
-
So where I am struggling with this particular motor is to work out what I need to connect.
I've managed to get some info on the 1FK7080 motor but not the 1FK7081. At this stage I can't locate a specific wiring diagrams for the encoder side.
The encoder connector is a 12 pin and has the following signals;
R1 - pin 10
R2 - pin 7
S1 - pin 11
S2 - pin 1
S3 - pin 12
S4 - pin 2
+1R1 - pin 8
-1R2 - pin 9
There are no connections on Pin 3,4,5 & 6.
I would love to know how to wire this up and what these signals mean.
I'm assuming the excitation is 24V but need to know whether the feedback will mate with the Panasonic PS and PS(NOT) inputs.
I'm trying to work out a wiring configuration of the servo on a test bench so that I can get feedback to the Panasonic drive. It's really for test purposes and the only spare motors I have are the Kuka ones.
-
Thank you #panic mode and #m.dinio.
I have attached the Kuka label to help. Sorry about that.
Kind regards