Check out Dedicated signals (Input and Output) Aux Function 0601 and 0602
Posts by kwakisaki
-
-
Quote
WAAAAAITTT!!!!
I need a moment to understand deeply this matter
Hmmm.....I may started something I did not wish too...……………
If you have used D Controller you will understand what I mean about T0, it is not a ghost.
If you have KROSET, please try D Controller and watch Tool Interpolation Icon no.
QTOOL OFF - will change it to T0.
QTOOL ON - will change it to T1-T9.
On E Controller (maybe also F Controller, but I have not tested) you will not see T0, only T1-T9.
QTOOL is function to tell Controller either to use BLOCK Tool (T1-T9) or use AS Tool (T0).
For certain reasons and necessity I didn't have a TOOL setted
You will ALWAYS have a Tool Value set otherwise the robot could not be moved in Base/Tool Modes.
It will either be using values set in T1-T9 (Aux func 0304) or the T0 purely depending on QTOOL setting.
I do not wish to confuse topic, so I will start a new topic tomorrow with video of KROSET showing D Controller and E Controller and effect of QTOOL.
What Tygerdawg has experienced is the QTOOL functionality and the 'warning signs' of QTOOL change all because there are 2 areas to select Tool to use and very easy to make mistake/confusion.
This is why it is paramount to always set and check correct TCP for application, as incorrect TCP can cause collision, damage or possible injury.
-
Ah right, when you mentioned QTOOL OFF and also NULL TOOL, I assumed you were referring to using this as AS Tool reference, what you experienced makes complete sense now and thinking about it, I could have highlighted this for you...……..
I can give you a breakdown into this now.
Kawasaki Generically with ALL Controllers has 2 Types of Tool/Fixed Tool Coordinate selection:
- Aux 0304 or Aux 0305 T1-T9 values for Tool and Fixed Tool (if enabled).
- AS Commands TOOL or FTOOL (if enabled) which write to an address reserved called T0.
- QTOOL Function controls whether to apply T1-T9 (ON) or T0 (OFF) values to the Tool Coordinate system.
Therefore you could address T0 at any point by use of the TOOL or FTOOL command just by typing it in.
- If QTOOL was OFF, then that would be your current tool.
- If QTOOL was ON, then it would make no difference as it would be accessing T1-T9 BUT.....you would of still set T0 (unknowingly).
So by action of toggling QTOOL ON/OFF, you then invoke either T1-T9 or T0.
By the sounds of it you may have set an AS Tool at some point, but totally forgotten about it.
By action of toggling Qtool, you then invoke the retained value of T0.
This is part of a known bug, which they have never addressed.
What they further did.....…. is that they removed the 'indications' for this in the E Controller that were present in the D Controller.
Along with a 'lack' of clear documentation relating to Qtool On and Off functionality.
This is not a good selling point, as you are training, could place you in an embarrassing position.
In D Controller:
When you simply toggled Qtool Off/On.
- Tool interpolation icon would change between T0 and T1-T9.
- Fixed tool interpolation (if enabled) would change between F0 and T1-T9.
- A clear visual of which Tool address was currently selected (ie if Qtool is on or Off).
In E Controller this does not occur - T0 never is displayed, irrespective of whether Qtool is On or Off:
- Tool interpolation icon only ever displays T1-T9.
- Fixed tool interpolation (if enabled) icon only ever displays T1-T9.
- Therefore no indication of T0 at all (ie no indication of whether Qtool is on or off).
- Resulting with incorrect motion for the T'x' displayed if Qtool is Off.
Ask your Kawasaki guy about this, if he truly knows the Controller, he will confirm it.
If he doesn't then ask him to test it on both D and E Controllers either on live systems or in KROSET.
It is possible this is also present in F Controller too (I have not tested).
KHI really do need to resolve this...……...….
The underlying rule I adopt is:
BLOCK Programming = QTOOL ON:
- Use Aux 0304 and Aux 0305 to Set Tool or Fixed Tool Coordinates.
- Use Tool interpolation/Ftool interpolation and select T1-T9.
AS Programming = QTOOL OFF:
- Use Tool or Ftool commands to set Tool or Fixed Tool Coordinates via keyboard or program.
- Ignore T'x' value in Tool/Ftool Interpolations.
- If you require to change tools, re-execute another Tool or Ftool Command in keyboard/program.
If you are intending on swapping between BLOCK and AS mediums I recommend:
- Use BLOCK Steps for motion instructions (QTOOL ON).
- Use AS for all logic and non motion instructions.
Glad you've resolved this though...….but like you say...Mystery of Japanese logic and design......
-
Welcome to the forum...…….
Unfortunately no.
Every step of a BLOCK program contains several elements which contain parameters associated with the programmed step, not just a position.
To list but a few elements of a BLOCK Step:
Interpolation Type
Speed No. 0
Accuracy No. 2
Tool 1
Timer 1
Inputs to wait for
Outputs to turn on/off
Position (which is only a Joint Angle not Transformation)
To accomplish the above in AS, can not be achieved on 1 step and requires separate steps.
So a simple AS equivalent of the above would be:
SPEED 10
TOOL T1
ACCURACY 10
SWAIT 1001
JMOVE #position
TWAIT 0.2
SIGNAL 20
Now picture this conversion, with a 300 Step BLOCK program.
2100 Steps in AS minimum plus the added confusion factor of repetitive commands, which WILL require some attention, not too mention the sudden memory usage in comparison, not too mention if you want to store the positions as joint angles or transformations aswell as choosing variable names for the positions/locations and constants associated with the speed, accuracy and timing values.
Now IMHO, this is precisely why Kawasaki did not provide a solution to convert......too much work to re-invent the wheel.
-
Excellent news...………
You're very welcome, keep that card VERY SAFE.., you never know when it'll come in handy again.
I cut my teeth on the C Controller and I considered it a very good product for Kawasaki, shame they have discontinued it, but always nice to support keeping them alive.
I've gained lots of additional knowledge from other users experience here at Robot Forum, these experiences are not written in manuals, that's what makes Robot Forum a great source of global information.
What bolsters this, is the fact that you also post back results, this then allows for this community to grow and become another 'tool' in your toolbox.
So always a team effort and many thanks for your comments and your feedback of results, this is what promotes people to assist others in areas they can.
Look forward to seeing you on the forum...…..
-
I've just started to get my head into the Fanuc family and have visited your website too for some background reading.
Found it very informative and tried your fexcel spreadsheet very useful indeed, whilst using Roboguide helped me to set some basic templates quickly without 'like you say key bashing'.
Makes it a whole lot easier for sure...……..
Many thanks as I have found your information very useful indeed.
-
It appears you are using AS Command to set Tool Coordinate.
Standard Kawasaki are always default with function QTOOL ON.
This uses Tool data set in Aux 0304 (T1-T9) which is allocated to BLOCK Programming.
I suspect you still have QTOOL ON.
Either use Aux 0502 to access system switch area and check/remove QTOOL Enable mark.
Or use QTOOL OFF command in keyboard/terminal/program.
Setting should then remain retentive unless you or program makes changes.
-
Robot positions do not change, unless someone or an instruction changes them.
If a robot goes to a different location other than programmed, this would be very dangerous.
Therefore, the robot checks throughout it's path where it is in relation to the processed path and target.
If there is deviation, the robot should stop and produce an error, from what you are describing then mechanically the robot appears in a different location.
This suggests the feedback of the motors is still functioning correctly and tracking therefore the robot is not producing errors.
Slow the robot down through the cycle, does this reduce the shift amount, if it does, then check the following:
- Backlash in gearbox(es) - Check this in T1, energise motors, zero speed and have someone push/pull on joint to check if there is motion.
- You mentioned remastering due to 'slipping', this suggests possible motor shaft wear/belt wear/pulley wear, requires investigation for integrity.
- Check Tooling mounting bolts, alignment.
- Check Robot mounting bolts.
- Check pedestal mounting bolts.
- Check target peripherals are secured and are not moving.
- If you are re-teaching and find those positions are not staying the same, check the program is not loading default positions.
- Often a programmer will use master locations and re-prime these at some point, reversing any change an operator does with touchups.
What you are describing suggest overall, this is mechanical in nature and will only get worse, but remastering inaccurately can cause deviation over long distances too.
-
Hmmmm…….I don't quite follow that in it's entirety...…., however thanks for the reference information, I shall have a read up on that and now I've got my hands on Roboguide, I shall apply a few instances so I can see the path trace effect by using the BREAK instruction in relation to a motion and non motion instruction so that I can understand it more.
My confusion comes in with CNT, I am used to dealing with accuracy units (mm) as opposed to percentages and it's taking me some time to get my head around this concept.
Many thanks retobor, greatly appreciated………
-
Not to sure if anyone has had any success with 'no name brands' and formatting/downsizing.
It's possible some of the oddball cards may just work, I personally gave up and stuck with a brand I knew worked as it just was so unpredictable.
Also I think Transcend was a favoured brand too which Kawasaki supplied.
Sadly without a compatible CF card, turns it into a job stopper really as there's no other way of getting data in.
-
Quote
So the runtime will not attempt to execute any instructions following that line until after it has completed the motion instruction
The command used as an example of CNT35, therefore where exactly would the robot be in relation to the actual target location when it decides it has completed the motion instruction, would it go to the actual location instead (decelerate to it) before executing the next instruction?
I am asking as in Kawasaki, there is an identical instruction called BREAK which ignores any accuracy value associated with the target and travels to the exact location instead - in short, it breaks the continuous path transition, turning it into an accurate visit to the location (point to point).
This however, does not halt/pause execution of the next step if it is a non motion instruction such as an output or logical instruction.
This will be executed at the accuracy value associated with it.
- It is an optimisation technique that prefetches the following instruction if it is a non motion instruction.
I am wondering if this is the same on the Fanuc too, would you know this at all?
-
I've been playing around with KROSET in reference to the STWC and STWE commands and they do work as per dedicated signals and parameters set.
However, any external axis added is always connected to the Kawasaki Controller, so I cannot simulate true STWC/STWE commands on a rotational model.
My simplistic opinion of submerged arc weld AS code using STWC and STWE commands would be:
W1SET 1 = 100,120,60,0,0,0
W2SET 1 = 1, 80,60
HOME
JAPPRO weld_start,10
LWS weld_start,1
STWC 5,1,10 ; Turn on Positioner Signal, Speed BCD 5, Weld Cond 1, Duration 10s
STWE 0,1,1,0; Speed BCD 0, Weld Cond1, Weld Crater, Duration 0s, Turn off positioner signal
LDEPART 10
HOME
The external axis can be set as an external positioner or as a spin axis, however in KROSET, I do know the spin axis commands work, but do not rotate your live model, so I cannot utilize the spin axis either to reflect the true simulation of the application by just turning a motor on and off and controlling the speed.
If you or someone has accomplished this, I would love to see it.
From my perspective, you could create a simulation of what you would expect to see, but from a code perspective, I don't think it could be achieved in KROSET as a direct code that you could transfer to the Controller.
This is bugbear of mine, KROSET does not have the ability of simulating the spin axis or as this topic is related to STWC and STWE, a way of simulating this too.
Again, if you or anyone else has achieved, this I would love to see it.
-
Wow...……
From what you wrote though in terms of the direction of the axes you mentioned, it is in line with Kawasaki left hand rule, which leads me to think some 'tinkering' may have gone on.
The obvious question is in what way did this issue suddenly appear:
- During normal use, whilst using it.
- During reloading of data or upgrading/downgrading of firmware.
- During a re-zeroing exercise.
- Are you using Fixed Tool option and is it currently highlighted in the Teach Screen (FLIN).
- During some maintenance on the arm or controller.
- After a power cycle.
Some additional checks I would recommend as confirmations to eliminate zeroing or even incorrect motors (swapped minor axis connections):
- All joints when individually driven in joint mode go in the correct direction (as per the arrow indications) and to their set software limits.
- Using Base mode and BASE NULL confirm the robot travels in the correct direction relative to the left hand rule including rx, ry and rz.
- If the above yield correct results, it does indeed point to a tool coordinate issue in my opinion.
You have tried to null the tool in a way I would recommend, and I would put my exploratory head on and:
- Get all the joints to zero degrees.
- Perform a full file save.
- Hardware Initialization by use of the dipswitches on the 1TA/1VA (CPU board) and rebooting but do not load any data into it.
- Then set the ZROBOT function to match your robot model (via the keyboard).
- Re-zero again.
- See if the issue has been resolved.
- If it has, take a full file save again with the joints at zero degrees, use winmerge or other txt comparison application to compare the before/after file saves.
- This should highlight any data differences and may just reveal not why, but what has possibly changed which may connect into the moment it occurred.
If the above initialization fails to resolve it, then it could only point to some corruption within the AS/SV firmware then, which would be very strange indeed.
If you can get a full file save and send it over, I can put it into KROSET and see if it replicates it?
Would be interested to hear how this evolves for sure......
-
-
In KROSET, you need to use the 'Wizard to set external axis' plugin in order to setup an external axis within your project or else your system will just be a standard 6 axis system.
When setup, correctly (you will also require a suitable stl to represent an external axis), you could then jog the external axis and interface with it in terms of speed and taught locations just as you would on a live controller.
-
Yes, it's the CF card itself.
I have tried many times to try and utilize 'out of spec' CF cards by using various software to 'downsize' a CF card with no success......
The 'format' function in the controller, I have only ever got to work when using a CF card supplied directly from Kawasaki, any other CF card I have thrown in it, even though within spec, never successfully ever formatted it...
You need an 'off the shelf' 4Mb, 8Mb, 16Mb or possibly a 32Mb CF card to really guarantee read/write access within the controller, you have to consider the age of the controller, the internal drivers would have been written by some boffin over 20 years ago when the range of manufacturers and memory sizes were not as varied as they are today, therefore universal compatibility today would not have been considered back then.
The only recommendation I can give in this area is try and hunt down Sandisk 8Mb or 16Mb, these I use myself.
Unfortunately in the C Controller, there's no other way of getting software into it except via CF interface.
This is what your target is:
https://www.ebay.co.uk/itm/SanDisk-Co…l8AAOSwTrpdgfaD
https://www.ebay.co.uk/itm/Sandisk-16…QIAAOSwpXFdEQl~
-
-
Welcome to the forum...…………
As far as I'm aware, the positioner configuration is just communication signals to a positional controller.
This Controller then controls the positioner independent to Kawasaki motion.
(ie like a variable speed drive controlling the motor of a conveyor - The Kawasaki just sends an enable and speed request to it).
I don't think the function STWC/STWE commands are intended to control an external axis attached/configured within the Kawasaki.
I maybe incorrect in this as I am just reading the operation manual and all it references to is:
- Sending a Positioner ON signal (which I think is just an enable signal to turn on the positioner).
- Sending speed signals (8bits) using dedicated outputs (a BCD value sent to the positioner).
- The positioner then runs at the BCD value configured speed.
- The robot will use the time value set in the STWC/STWE commands respectively to apply the weld.
- Using parameters either configured in the weld condition if using BLOCK or via the W1SET/W2SET commands if using it in AS.
- It will carry on welding until either the program ceases the weld, or if a STOP signal is received on the dedicated input if allocated.
If you were intending to configure the positioner as an external axis and control this (and the exact position of it), then I don't think the STWC/STWE commands apply in that scenario as you would set the external axis to operate in cooperative mode which will synchronise the external axis with JT1-JT6 respectively therefore the external axis positions are included in the path of the robot JT1-JT6.
What is your intention:
1. To Control the actual position of the positioner and speed.
2. To just rotate the positioner.
-
You're welcome...……
Just remember, touch sensing can be applied in many ways:
- Locate an actual workpiece.
- Locate a start point to weld.
- Measurement for work deviation or checking.
Try different methods when you completely understand the function, this way you will produce a good 'working template' for future installations.
And I have learned something from your example too, so thank you for that also...……
-
I've had a look over it and it works quite well (in KROSET).
I look at things with very simplistic glasses and what you've written is very clearly broken up into sections, easy to follow and flows in terms of sequencing and does the job indeed.
Very difficult to offer any recommendations, except alternate methods.
I would definitely consider incorporating the XMWIRE command though to set an even wire length prior to touch sensing.
- This will give you the best results for touch sensing/tcp values and reduce errors.
- Especially if you are using high crater currents to finish the weld on the previous cycle.
You could adapt to using dedicated reference points on the work piece for X and Y touch sense points as opposed to very close to the intended weld start and end points.
- Only because this allows for more flexibility around any shape workpiece you intend to weld.
- Also if you were to introduce a work object frame, then the X/Y Planes of this could be references.
- By using references too, you could then locate the start weld point based on the XY shift results too.
Also, DECOMPOSE is very good command to use however if I was targeting just X and Y, then I would favour DX and DY to create the x difference and y difference values.
However, using the DECOMPOSE gives you access to more which is there if you need to access it, and to be honest, I personally am trying to use this more and more as opposed to just DX/DY/DZ.
Additional to this, I would possibly utilise the SHIFT in the LW commands, then incorporate the x difference and y difference values into them.
- This incorporates a slight protection of users being able to POS MOD them easily, which can be good or bad depending on your customer.
I've attached a video and displaying the running code.
I wrote it based on what you wrote, but condensed it somewhat......but other than that, what you have done thus far looks ok to me...………