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.
........so I could be chasing ghosts then....
