VI is not dealing with changing data in the loop too fast

[jeandebrem]

---

@pincpanter wrote:

---

So you tried with a 1 s delay and it works? You didn't mention this before. You should share with us those important information.

---

---

---

---

---

---

In my opening post I wrote: "motor is moving quite slowly (one move in one second), and after few (7-8) position changes is stopping" - so I wrote, that motor is doing some move. If it wasn't clear to you - I'm sorry.

---

@pincpanter wrote:

---

You need to use another method. I could not suggest one, since I don't know in detail how the device is working.

---

---

---

---

---

---

---

In 2 seconds, shaft of my servodriver should realize sinusoidal motion. That's why I divided values into certain number of parts.

---

@pincpanter wrote:

---

You need to get the Tick Count just before sending the command and just after receiving the answer, then subtract the second from the first. Doing this, take into account LabVIEW's dataflow! The result will you give a hint on the maximum rate you can actually reach.

---

---

---

---

---

---

I made it. I am attaching print screen. I am also attaching videos of my VI and servodriver working. I hope it will help you in understanding my program.

[pincpanter]

Honestly they don't help much. The time is almost uniformly 30 ms. Did you put any Wait in the loop?

Did you check the answers from the servodriver? Are they as expected?

[jeandebrem]

---

@pincpanter wrote:

Honestly they don't help much. The time is almost uniformly 30 ms. Did you put any Wait in the loop?

Did you check the answers from the servodriver? Are they as expected?

---

Yes, I put 30 ms wait time in the loop. That is why times are 30 ms.

Answer from servodriver you can see on my video. They are not as I have expected. I expected 33 moves in 1 second, and I have only 2 moves.

[pincpanter]

With "the answer" I mean the string returned by the servodriver through the serial port.

When you send a command to a device, it's always important to check the answer - as explained before - not only the behaviour.

Unless a command does not involve any answer, of course; but, according to the manual, this is not the case.

[jeandebrem]

---

@pincpanter wrote:

With "the answer" I mean the string returned by the servodriver through the serial port.

When you send a command to a device, it's always important to check the answer - as explained before

---

How can I do it? I have done as you wrote - I wired a large number (say 100) to the byte count of the VISA Read function but nothing has happened.

[pincpanter]

So you don't know that VISA Read returns a (sometimes empty) string? Wire the read buffer output to the loop border and create an indicator.

[jeandebrem]

It looks ok, I think. Reply seems to be good. But nothing has changed in acting of my motor. It is still working unproperly...

[pincpanter]

Obviously nothing changes. It was an attempt to get more information and a hint on how to proceed anymore.

However, all seems to be formally OK (I assume you checked all answers and not only the last one), so your device is simply not able to properly execute the commands, although they are acknowledged. This may indicate a bad implementation on the device side.

As a general rule, you should in any case compare the command sent and the received answer and terminate the loop if they don't match.

(Again: this is a general suggestion, in this specific case it should not change anything in the actual behaviour).

[jeandebrem]

---

@pincpanter wrote:

I assume you checked all answers and not only the last one

---

Yes, of course.

---

@pincpanter wrote:

This may indicate a bad implementation on the device side.

---

Ok, so I will look further on device settings.

---

@pincpanter wrote:

As a general rule, you should in any case compare the command sent and the received answer and terminate the loop if they don't match.

(Again: this is a general suggestion, in this specific case it should not change anything in the actual behaviour).

---

Ok, thank you very much for your advices.