Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

problem by continuous serial communication

Solved!
Go to solution

Hello,

 

 I wrote a VI to communicate with a converter through serial interface RS-232. I am sending speed set point and reading actual speed and Torque value continuously for the motor control. The program alone works without any problem . But when I integrate the VI in the main program which measure the voltages and currents through DAQ (rate = 5kHz), the serial communication is disturbed somehow, I mean I get some zeros from time to time for the values of speed and Torque which harms my control loop.

 

 I integrated my new VI simply as a seperate while loop in the main program and tried to play with the time delay but it did not work. What annoys me that this problem occurs randomly, like sometimes the readings are perfect for 5 min and sometimes from the first seconds I get some zeros.

 

Any idea what could be the problem?

 

Thanks alot

0 Kudos
Message 1 of 23
(4,619 Views)

Hi,

 

A bit difficult to say without knowing what your made in LV.

 

You are not (re)initializing the COM more then once ?

 

How does the data look like ?

 

And show us the VI.

 

Kees

0 Kudos
Message 2 of 23
(4,611 Views)

So the VI I programmed which works perfectly alone is shown in the figure attached. When I simply add it to the measurement program (which was developed by engineers before me) as shown in the program attached the problem occurs. To monitor the outputs from my converter I am drawing the outputs and when combining both programs (or running them in parallel) the wavefrom grapth shows some zero values from time to time, this does not happen when running the converter program alone.

Download All
0 Kudos
Message 3 of 23
(4,596 Views)

And here is the waveform of my data, these (zero spikes) never occurs when running the program alone. By the way I am using the USB port with RS-232 connector for communicating with the Converter. And the measurments through a DAQ device.

0 Kudos
Message 4 of 23
(4,590 Views)

Hi,

 

Scary diagram. I always try to keep my program in one window (not full screen) and use sub VI's. But I understand that other 'programmed' this.

 

Take a look at the picture. You should realize that execution order is forced by dataflow and not by the placement in the diagram. The time-out of 200msec will be executed at any moment. Use the time-out terminal of the event structure. (red circled)

 

The blue circled part is also executed at a random moment within the while-loop.

 

I don't know if this is the real problem.

Can you also post the sub VI's that are shown in the picture ?

 

Kees

 

0 Kudos
Message 5 of 23
(4,589 Views)

Thanks first for the fast reply Smiley Happy.Here is my program with the sub VI's attached, for the operation in the blue circle; it just activate or deactivate the numerical element "Frequenz Eingabe (Hz)", I removed it totally but it did not change anything. And for your suggestion of using the time-out terminal of the event structure(red circled), well the program didn't work at all! I mean the read/write operations inside the event structure were not executed! ( I can't expain why Smiley Happy )

0 Kudos
Message 6 of 23
(4,577 Views)

Hi,

 

The time-out is now 0. So the time-out event is executed as fast as possible. I think it is better to use a figure higher than 0.

The COM port is set to COM1. Maybe that is the reason why is does nothing.

 

Still missing VI's 'Rand-ary' and 'Sum check'

 

The real problem is, I think, the write and read data sequence. I see that you write data and read the returned bytes without checking if there are enough bytes available.

I think you have to change the read data into (a sub vi) wait x time (1 sec) for y bytes available before the read. So a while loop that will exit either at the x time-out (error) or if y bytes are available. Assuming that you know in advance how many bytes are returned.

 

Even if this is not the cause of the error I think it will make your program better for the future.

 

Can you try this ?

 

Kees

 

0 Kudos
Message 7 of 23
(4,574 Views)

Hello,

 

I'm sorry about saying that, but your style of programming is not the optimal one. When you open LabVIEW and klick on new...from tamplets...design pattern... producer/consumer design pattern events, there you can find an example of the producer/consumer design. Probably this will solve your problem. Because you have to encouple your frontpanel objects from the code. Furthermore you use a eventstructure and take a timeout of 0. What do you want to do in tihs way? I'm of the oppinion, you want to always execute the timeoutcase, want you? So why an eventstructure?

 

Exist any other case in the eventstructure? The 0 in timeout is in ms. If any other event in another case will appear within a few microseconds or so, I think that case will be executed. And then you perhaps become a 0 in your graph.

Hope this was helpful

 

regards Tobias

0 Kudos
Message 8 of 23
(4,561 Views)

I'm having a similar problem... I'm using VISA for Serial. It's a SubVI in a major loop. It works for a while, but then starts giving me back the wrong number of bytes. This causes the "zeroes". Do you know if it's in the way we're passing the VISA to the SubVI? Would that cause multiple opening of the COM4? Perhaps passing to the SubVI as a VISA Reference instead would solve it?

0 Kudos
Message 9 of 23
(4,556 Views)

Hi JFerrara,

 

Like I said at the beginning: 'Never open a COM port more than once in a program'

(Except when you close it)

0 Kudos
Message 10 of 23
(4,549 Views)