Pulse lenght mismatch

egor

Hi, 

<do_MessageReady> is signal, which pulses every time a message recieved from camera. It doesn't assigned to any device.

SocketReceive clientSocket\RawData:=raw_receive\Time:=WAIT_MAX;
PulseDO\High,do_MessageReady;

Sometimes, I see that this signal can last longer than the default 0.2s. What could be the reason? 

lemster68

One camera message received right after the other?

egor

lemster68 said:

One camera message received right after the other?

Camera couldn't send next message without strobe signal (di_CamStrobe).

lemster68

What, if any, relationship is there between that signal and the one at the very top?  I see that it is on for a longer time when doMessageReady is off for longer , and it is off when doMessageReady is on for longer time.

DenisFR

Hello,

I don't like pulse. It may stay at high some times. Surely if it is already at high when pulse called.

To prevent it I reset always signal before call pulse.

It's better to set signal, wait your camera start signal then reset it.

egor

lemster68 said:

What, if any, relationship is there between that signal and the one at the very top?  I see that it is on for a longer time when doMessageReady is off for longer , and it is off when doMessageReady is on for longer time.

This is an encoder signal, which changes its value for every specified distance. If it doesn't change, then the encoder wheel isn't moving (and the camera doesn't send new strobe signals).

egor

DenisFR said:

It may stay at high some times. Surely if it is already at high when pulse called.

To prevent it I reset always signal before call pulse.

Once there was a situation when strob signal was too long. This signal (di_CamStrobe) is connected directly from camera to the I/O unit (DSQC1030) and I can't control it's lenght. I think, is it possible that signal analyzer distorts signals? It happens about every 60 seconds (see my attachements).

Encoder wheel does not slip, full turn takes a few seconds

DenisFR

In your first picture I see a slip between encoder pulse and camera trigger.

Does your camera can finish its task before next pulse?

Look into TriSpector to get program time.

Does your camera send something when it failed?

lemster68

I agree with Denis, Pulse has ways in which it can fail you.  Many years ago it was even documented that a version of robotware, or versions, had a flaw with pulsed outputs.  Chrysler standard a few years, or more, back prohibited the use of pulsed outputs.  Another instance of pulse failing is when the cell is e-stopped before it can act on the pulsed output.  When restarted, the signal is no longer high and the cell sits idle until someone can figure out that it is waiting on that signal.  Pulse time does not pause for e-stop or other stops.

egor

DenisFR said:

In your first picture I see a slip between encoder pulse and camera trigger.

Does your camera can finish its task before next pulse?

Camera trigger is independent of the encoder impulses. I can change the encoder impulse length by adjusting configuration parameter. It just shows me whether the encoder is moving or not.

Camera can create next strobe before message is fully transmitted. In that case the objects create a queue. But it is not my case, because conveyor moves slowly for camera. 

egor

I can get rid of the pulses in my RAPID code, but I can't figure out why the camera create such a long strobe signal. There's no way I can change the length of the camera strobe signal.