Most reasons for IO not functioning is wiring, the connectors are not the best and very easy to create short circuit and connect to incorrect pin numbers etc.
A picture of the inside of the CNx connectors would be nice.
Most reasons for IO not functioning is wiring, the connectors are not the best and very easy to create short circuit and connect to incorrect pin numbers etc.
A picture of the inside of the CNx connectors would be nice.
The next thing, if all your wiring is correct (something is telling me it's not) is to clean out the controller and return ito back to defaults.
Thus removing all data and then trying again.....sounds like overkill to have to do this, but nothing make sense.
I would check insider connectors CN2 and CN4
Tell me:
1. Where is the 24V and 0V lines in your panel from the PSU going to on CN2 and CN4 Connectors
- CN2 requires 24V on VIN1 and VIN2 (18 and 19)
- CN2 requires 0V on COM1 and COM2 (36 and 37)
- CN4 requires 0V on COM1 and COM2 (18 and 19)
Yes, that's why KIDE is shite......you're relying on 'beta' application and automatic functions.
Better sticking with KCWin.
That backup you sent is 100Kb greater in file size that from KIDE.
Tell me:
1. Where is the 24V and 0V lines in your panel from the PSU going to on CN2 and CN4 Connectors
- CN2 requires 24V on VIN1 and VIN2 (18 and 19)
- CN2 requires 0V on COM1 and COM2 (36 and 37)
- CN4 requires 0V on COM1 and COM2 (18 and 19)
OK, so you're connected via ethernet then.....so it will be valid.
What happens when you use CTRL+F9 option then?
Personally, I don't think you're wired up correctly.
Need to see CN2 and CN4 inside the connectors?
Can you show me a video of what you're doing when using the IO screen to turn on the signals?
So the backup you've been sending is not what's in the Controller then................................so I could be chasing ghosts then....
The error is relating to you using incorrect syntax.
The command should be SAVE followed by a filename not exceeding 8 characters, no spaces and not starting with a number (but can contain a number).
eg. SAVE backup
So the logic is being executed correctly then, so that's something.
If you move the red box over a specific output (don't just leave it on No 1, move it and try) in the IO monitor screen:
1. when pressing (and holding A) and then pressing no. 1, that should turn the highlighted output on - go from light grey to yellow.
2. when pressing (and holding A) and then pressing no. 2, that should turn the highlighted output off - if it is on - go from yellow to grey.
Are you saying that is not working?......as that does not make sense.
No I never said CN3 should have a cable in it, it may have a cable in it.
Do not worry about CN3, if the jumpers are set to what I said, it will not be in use.
Can you send pictures of your wiring to the CN2 and CN4 connectors - some good quality ones?
Also pictures of the 1HW board itself showing the jumpers?
So you cannot make a backup from the Controller - is this what your telling me?
Ah, lots more emails to put on the spam lists now.......
So glad really, as a lot of people of late have been using their 'conversation' options to exchange emails etc which meant a huge reduction in my spam lists, but now it's starting back up again, I'm back in business.....
Thanks everyone for sharing.....
How would I possibly know where this file comes from or in what state of editing it is at?
Therefore the only thing that is relevant when trouble shooting is exactly what is in the controller, not on a PC. unless you are testing in KROSET etc.
Saying that also, without specific information, we have to trawl through reams of data without knowing what programs are being used or tested, so we need as much updated/to date and accurate information as possible - this will always reside inside the controller as that is what it is executing.
Comparing the 2 files, they are different and not identical.....which proves my point.
- Granted, there is nothing that points to what you're experiencing.....But it could do.
- I don't mean it to come across in negative way though, but you could by accident send a file from last year and we'd be chasing ghosts.
- I have spent many hours trawling a backup only to be informed, they'd provided the wrong one...........
- This is why a current backup is necessary.
Ok, So we can ignore the KLOGIC allocations and as there is no LSQ program exist/running then.
Reviewing the 'small' program:
Your inputs from the peripheral sensors providing feedback/status are turning on internal signals, not outputs.
- I assume you are aware of this, if not, then you need to do some research about the Kawasaki IO and Internal Signal purposing and usage.
- Inputs are referenced as 1001 - 1032
- Outputs are referenced as 1- 32
- Internal Signals are referenced as 2001-2255 (these are like internal flags only - no electrical connection to CN2 or CN4).
- So no indication on CN2 will be seen regarding the status of these.
- If you check the INT screen in the IO Monitor screen, you should be seeing these signals reflect the logic your using in the small program.
- These are also being sent to the 2 Data registers (if the autostart.pc program is running) you should see these values in the INT Data Monitor window too.
- This will provide you evidence of whether the peripheral sensors/inputs are working depending on there status.
The outputs in your motion routine (speed and distance between points dependent) will be executed when the robot is 20mm from the preceding target.
This could actually mean they are operating too fast for you to see......I doubt it, but it is possible, you could go real slow and see if this is the case.
The other thing I have noticed, is that the general fieldbus is disabled with an old configuration that uses signals 33-64 and 1033-1064.
However, as this allocation is not the 1-32 and 1001-1032, this should not be causing any issues.
So on the face of it, what I can see, there is no reason for the IO to not function as far as the controller logic is concerned.
If you can proceed with those 2 tests I mentioned, then we will be in a position of whether there is an underlying configuration issue or board problem.
Why do insist on providing a backup that has not come from the controller, you always seem to provide your offline file?
Has any other backup ever been loaded up to the controller from a different one of different source?
Are you using KLOGIC, as it appears in your backup, yet the LSQ program does not exist.....where is it?
In future, please take backup directly from controller and post it.
In Kawasaki AS Language:
- Inputs are referenced as 1001 - 1032
- Outputs are referenced as 1- 32
- Internal Signals are referenced as 2001-2255
I don't really see any program in your backup that you are using to test.
You have unallocated all IO from any dedicated signals, so all IO should be available in code.
Put the following in a PC Program and execute it and look at the output monitor screen outputs.
FOR .tmp = 1 to 32
SIGNAL .tmp
TWAIT 1
SIGNAL -.tmp
TWAIT 1
END
Each output should turn on and off over 2 sec period and be displayed sequentially on the screen, the physical output if connected to a peripheral should operate to.
As I don't know what is connected to CN2, you should remove it during the test so as not to inadvertently trigger external peripherals.
To test the Inputs, do the same program again except this time change it to:
FOR .tmp = 1001 to 1032
SWAIT .tmp
TWAIT 1
SWAIT -.tmp
TWAIT 1
END
The PC Program will wait to see input 1001, then wait to see it turn off, then move onto input 1002 etc.
You will need physical switch on inputs to test to cycle through inputs.
This would test your inputs are working.
Aux 0603 is just the area to attach a 'name' to IO, which is just a label and has no bearing on functionality or not.
IO Monitor screen as images:
Light grey indicates OFF
Yellow indicates ON
Dark Grey indicates Dedicated Signal is OFF (if allocated).
Orange indicates Dedicated Signal is ON (if allocated).
You see the red box on the output side, use the cursors to move it around the output screen.
Stop on an output and press A and 1 on the teach pendant to turn it on - it should turn yellow.
To turn off, just press A and 2 and it will return to light grey.
You cannot force inputs, they need to see the relative to voltage on the input pin to show it is on and no voltage on the relative pin would remain light grey.
Have a look at this screen and let me know your results.
As long as the controller has been set to 'look' for the 1HW by setting the total IO in blocks of 32 and the 1HW is addressed correctly, you will not receive any errors if they are both 'talking to each other'.
You will not receive any errors if IO is not reading/sending.....unless controller and 1HW is not communicating with each other along the VME bus.
Even though these are considered digital IO, you still need to remember the analogue aspect of the circuit - especially C and D Controller 1GW/1HW.
Inputs:
- Inputs are rated @ 10mA in order to operate the optocoupler.
- Even at an input voltage of 21.6V to 26.4V the specs say it should operate.
- The circuit design (optocoupler) will always incur a voltage drop across the optocoupler led possibly as much as 1.3V (forward voltage for current source).
- This led drives the output transistor to the low level logic on the control side.
- As long as this optocoupler is receiving 10mA of source current, then the output transistor should switch the transistor on the low level logic side.
- So within these, it should operate - providing the optocoupler/input circuit is correct and is not damaged.
- Now if your 'source' 24V to the board is dropping, then that is a different matter, as either the source cannot deliver the current, or there is a short circuit.
Outputs:
- Each output are rated @ 100mA of source current via an optocoupler isolated transistor array.
- Internally this is just a transistor that is turned on of off by low level logic from the control side firing the optocoupler led.
- Inductive loads will require suppression such as surge absorbers (freewheeling diodes for example).
- Small signal relays are the preferred method as opposed to direct peripheral wiring for devices requiring >100mA.
- Output voltage will depend on the load attached, otherwise voltage output maybe low or transistor is damaged in the transistor array (S/C or O/C).
- Now if your 'source' 24V to the board is dropping, then that is a different matter, as either the source cannot deliver the current, or there is a short circuit.
1. C and D Controller IO boards have 2 different flavours:
- 1GW (US and Japanese Spec) - NPN Configuration.
- 1HW (European Spec) - PNP Configuration
- Use external IO manual to wire up according to correct flavour of board you have, failure may cause damage to the board or connected peripherals.
2. If 1GW/1HW board Standard Jumpers:
- Check J1 Jumper for correct address setting in line with total IO set in Aux 0611. (each IO board contains 32 inputs, 32 outputs).
- Check J2 jumpers are correct (B-C Setting OFF), any jumpers left in A-B setting will disable the outputs.
- Check jumper J3 and J4 are correct (B-C setting), this will allow outputs 9-16 to be available on CN2.
- Check jumper J5 is correct (A-B setting), this will allow inputs 13-16 to be available on CN4.
3. Check you are connecting to correct CNx connector:
- CN2 is output connector (male).
- CN4 is input connector (female).
- CN3 may have cable - this is for arm signals, to disable these, check J3/J4/J5 Jumpers as outlined above.
4. Check the wiring is correct to CN2 and CN4 relative to flavour of board.
- IO pin numbers are not pin for pin for all inputs and outputs (CN2/CN4 pins 1-16 = IO 1-16), (CN2/CN4 pins 20-35 = IO 17-32).
- CN2 pin 17 is N/C
- CN4 pins 17, 36, 37 are N/C.
- Check VIN1 and COM1 (for 1st 16 IO) and VIN2 and COM2 (for 2nd 16 IO) are connected correctly.
- VIN1 and VIN2 can be tied together and COM1 and COM2 can be tied together if required.
The above points are very often overlooked when new to Kawasaki and many assumptions are made, so please review and use external IO manual for correct wiring and configuration and confirm correct for type of board in use.
5. What is being displayed on the IO monitor screen.
- Do your inputs light up when inputting a signal - if it does, then the controller is seeing it.
- Do you outputs light up when outputting a signal - if it does, then the controller is sending the logic to the 1GW/1HW board.
6. Have you got dedicated signals allocated to the 1GW/1HW - Check 0601 and 0602.
- If so, then these cannot be activated by commands, only functions.
7. Provide a full backup including your test program so I can check for abnormalities.
Yes, very scary indeed regarding your follow up, don't know which put the frighteners in me more....the wiki, or your description....
Makes you think just how much equipment is in use today that hasn't come to light with some fundamental issues buried deep and just a few incorrect key strokes could turn it all upside down.
Technology at present, very much reminds me of the Johnny Depp film - 'Transcendence'
so we are just talking to ourselves now.
Yes and thanks to the forum, I've managed to stop talking to myself....although, I have no alternative now as the other day my reflection in the mirror turned round and walked off.
I've just been reading the wiki on Therac-25, very interesting and a bit of an eye opener, but also probably not the whole story.
As you say, this occurs in all fields and the fact we don't hear publicly about these situations can often make people naïve to think it's all ok.
I remember being called in to troubleshoot a problem by the end user on a new install that was common across 8 individual Kawasaki robot systems, alongside the PLC programmer who had coded the PLC's (Siemens).
Profinet comms would not come back up after a Robot Power cycle without unplugging the RJ45 connection and re-connecting it again.
Without going into too much detail, the problem lay in the 'file' he was using to configure the PLC in TIA.
I re-configured the PLC from scratch and fixed the problem, then loaded the 'file' they were using, and the problem returned.
The PLC programmer could not configure this from scratch as they had always used the 'file' (which someone else gave them) to do it as it was quicker.
The PLC programmer was very open and honest with this and also stated on the last installation they did, they had the same issue which was never resolved.
So we spent sometime going through the 'file' to locate the issue and resolve it.
All the 8 robots were resolved and also the last installation happened to be on the same site, so we resolved that too.
The point of this, is that without knowing the fundamentals, it makes it extremely difficult to troubleshoot things when they don't work.
An old teacher of mine had a very good representation of this:
You cannot build a wall from a photograph using the correct equipment without first understanding the foundations (you can't see) the whole thing sits on.
If you decide to adopt this philosophy, whatever you do, will eventually collapse and possibly be fatal.
Yes, I only mentioned it as it lay in the same bracket as my reply.
I still slip up in my posts from time to time, and I have a very good female friend involved in robotics who keeps pulling me up over it.
It's on the increase too, so watch out fellas, there are some very clever ladies continuing to join the industry now and well deserved too, it's about time the engineering doors are becoming universally opened, may it long to continue.
No need to apologize, I myself have some very strong opinions I would love to vent.
But irrespective of numbers, figures and statistics (accurate, false or correct), I got the impression this was going to be turning into a 'rant' thread.
Also Visitors reading this may just well be experiencing this first hand and with the deepest respect, this is why I mentioned it.
Nope being totally serious.......have a read of panic mode post #13, remember we are talking about robotics here and not some mobile phone app that makes a monkey dance around on a bungee when you receive a text.
Oh and not forgetting, robots can cause some serious damage as well as injury and harm as it is the program that drives it.