Is it possible to obtain internal 12ms "tick" as (any kind of) output?
Cez
KRC2 internal 12ms "clock"
-
cezex -
February 7, 2014 at 7:45 PM -
Thread is marked as Resolved.
-
-
you mean something like
my_flag = not(my_flag)
you can do that on the robot, but getting it out into the world is another story.
-
I don't know, I need some kind of stable clock from KRC2, it must be related to program execution and robot movement, especially the start of the move.
you mean something likemy_flag = not(my_flag)
you can do that on the robot, but getting it out into the world is another story.
-
That's a very different thing from wanting a 12ms "clock." What exactly are you trying to do? Signals and subroutines can be precisely tied to motions using TRIGGER commands. PULSE functions can control a signal with timing precision down to 12ms.
-
The goal is to sync the robot with camera running 24 or 25 frames per second. This leads to make a separate generator synced by PLL with kukas PULSE.
This is the case when camera genlock is slave.
I wonder if it's possible to sync kuka with camera as MASTER.
Any ideas?
Cez -
Generating a pulse train with a 12ms period from the SPS is fairly trivial. However, you need to define what you mean by "syncronizing to motion," as that is an entirely different question.
-
Ok, so on what is the 12ms pulse is based? On motherboard CPU clock? What PPM value is has (if it's custom motherboard it should be lower than typical (customer PC) value, right?)
-
Eh? Just using one of the system $TIMER variables, and linking it to a $OUT in the SPS. Period controllable in 12ms resolution.
-
cezex, we are still in the dark about what you really need to do (big picture please).
I guess you are looking for a 'stable clock', but why? what camera needs external clock for (what is the make and part number of the camera?)?
if it is not a camera but 2D laser scanner for example, than external time or position reference makes sense (to build 3D image from bunch of 2D scans).
-
No, it's normal film camera. It has input called "genlock" to synchronize it's shutter. When robot moves the camera, it's very importand the shutter is opened (and closed) in sync with the move.
In this way a picture (a frame) is taken in specified position. I want stable clock from robot because every next pass must be the same. -
I still don't see what you need a "clock" for. A simple TRIGGER command can generate a precisely timed pulse relative to the start or end of a particular motion. Why can't a TRIGGER do what you need?
-
Ok, if the pulse generated by TRIGGER is precise, I will use it for triggering my genlock generator.
And what output is the best to take it out from controller? -
With trigger, you can get an output at precise point of the robot trajectory. all robot outputs are of equal "quality", there is no better or worse. if you are using physical I/O as an output to trigger camera, use one with transistor outputs to avoid bounce (and false triggers). relays are mechanical devices and have bounce. also they need longer to actuate (which can be compensated for in TRIGGER command).
-
Thank you guys but to clarify what I need, I must add this:
http://en.wikipedia.org/wiki/Genlock
Triggering (switching on and off) camera is one thing and having camera synchronized to genlock generator is another thing.
And I'm looking to have genlock generator synchronized with robot move.
And if TRIGGER is repeatable - ok. -
Okay, what, exactly, do you need to generate? A pulse based on robot position? A pulse train? A square wave? If the robot is moving from point A to B to C to D, what signals do you need where?
-
There are most common camera generator frequencies:
23.98 frames per second, 24fps, 25fps, 29.97fps and 30fps.
I guess it's not possible to obtain these square waves from robot, so I guess I have to make my own generator. Very stable and accurate, ok.
The question is IF and HOW can I trigger this generator (its start wave edge and further) to be simultanously (and accurately) run together with robot move.
Repetition of opening camera (mounted on the robot as a TCP) shutter in XYZABC in every pass (many of them) is crucial.
I'm sure it's possible. -
You're still not describing what you need. What does the waveform look like? What's the duty cycle? What's the frequency? When does it need to be triggered, and for how long?
For instance, something like this could work:
Code
Display More;in the SPS ;generate 24ms period 50% duty cycle square wave on $OUT[1] as long as $OUT[2] is True IF $TIMER_FLAG[1] THEN $TIMER[1] = -24 ; every 24 ms IF $OUT[2] THEN PULSE ($OUT[1], TRUE, 0.012) ; generate 12ms pulse ENDIF ; in the motion program TRIGGER WHEN DISTANCE=0, DELAY=0 DO $OUT[2] = TRUE ; enable output waveform to camera at start of motion TRIGGER WHEN DISTANCE=1,DELAY=0 DO $OUT[2] = FALSE ; disable outputwaveform to camera at end of motion PTP P1
-
agreed, still unclear... what is the path (straight line?)? what are the tolerances?
I like the example from SkyeFire. I would also check mode and $OV_PRO before turning on $out[1] (and display message if not ok) to avoid producing garbage captured data.
-
I asked a very similar question to Kuka a couple of years ago. I had a need to synchronise an external device with the robot via a TTL clock signal (or similar) so that the robot and the external device shared a common clock. I was told that there is no way to access a hardware based clock signal from the controller and eventually gave up trying. I'm still convinced that there must be some way to do this, but it's not going to be easy.
-
Well, I don't know about "hardware based," but doing it from the SPS should be entirely doable as long as the overal SPS size is kept low enough that the SPS execution time is less than one timeslice (4ms?). This isn't hard to test.
Hm... the SoftPLC options for the robot are supposed to have an even higher cycle rate, IIRC. My experience in that area is pretty limited, but I'd bet that would be another way to work it. Especially if you needed something better than the 12ms resolution of the system $TIMER variables.
Probably the trickiest issue is syncing the first "clock edge" to a particular position or event. But with TRIGGER commands and Interrupts, this ought to be achievable with some degree of experimentation and tuning.
-