Synchronization problem in seriel master/slave communication using VISA and a COM port

[soeren]

Hi

I am trying to communicate through a serial connection (my COM1 port) in LV 8.6 to a control system,
using a master-slave protocol approach. In this approach the controller (the master) sends out
different hex addresses 10022001100321,10022002100322,10022003100323 etc. and expects a specific answer
to each of these calls or else it will enter an ERROR state. I have created a simple Labview vi
to handle this communication using the following parameters:

baud rate : 38400
data bits : 8
parity : none
stop bits: 1.0
flow control: none

My problem is that the reading part of the program is sort of working. I can read the cycled requests from
the controller, but the controller is only reading small parts of the data I send out usually two hex digits
66 , 99 , 20 etc. I'm not sure how to "time" the vi, I have the possibility of using a couple of delays before and
after reading/writing, and also the loop frequency. But i'm not quite sure how this mathces the
 baud rate and the timing of the VISA-blocks them selves.

My current plan is to emulate my controller using yet another labview vi, just to make sure that this vi is working.
But if anyone has had any problems with this I would be appreciate info.

I'm attacting my vi, so far. Notice the diabled/enabled diagram, which has been toggling between testing and real protocol

[Albert.Geven]

Hi

While cleaning up your code I asked myself the question why you are reading the number of bytes available.

From your discussion I expected always the number bytes to read. 

[soeren]

Greetings

"Number of bytes......" is just something left over from some initial tests, I guess it could be removed without any problems.

[Albert.Geven]

Hi

Is the controller only sending an address of fixed length?

So yes how long and if it is sending no endcharacter, the only clue is to wait long enough after the first byte is sent.

So wait until at least one byte is available and then read the expected number.

[soeren]

Hi

The controller is sending two types of requests:

Type one, which is consists of a header (1002) , the read request (20), read adress (01 or 02 or 03 or 04 or 05 or 06), this is then followed by a trailer (1003) and a checksum (e.g 21 or 22 or 23 or 24 or 25 or 26 respectively). So these are the strings in the labview program looking like this e.g. 1002200x10032x , where x varies from 1 to 6.

Type two, which is similar to type one but includes four more numbers and looks e.g. like this 100290010000100391. (the numbers are HEX values) 

The length is not fixed but cycling through six type one (14 numbers) and then one type two (16). The values always start with the header 1002 and the last characters are the trailer 1003 followed by a checksum of two varying numbers

[Albert.Geven]

Hi

Ok, I understand.

Looking at the numbers I can recognize the controller on 1002 and then discriminate on 20 or 90 to determine how many characters should follow.

Or I could check for the trailer and the checksum after that.

I  am looking at the possibility to use directly the numbers without the hex translation. HEX anyway is only to make the numbers readable for hmans and my pc is not human at all.

I cleaned up the program to fit on one screen (1400-800), now I'm going to implement a correct controller interface.

[Albert.Geven]

sorry it took a few days but some other busy being needed me.

"attached" is a zipfile with a solution that does not work.

You still have to fill in the correct answers to the controller but somewhat simpler than before.

[soeren]

Hi

Thank you for the quick response, this comm link is all that stands between me and an amazing experimental adventure! I looked at the files you sent and used them to create an emulator for the controller system (the master). Which cycles through all the 6 character hex numbers. Then I modifed another version to read these values and respond with the same values. Unfortunately I keep getting a error warning 1073676294. And it looks like the "read controllerstring.vi" is often only reading a 3 byte number i.e. when the controller is send e.g. 10022002100322 the answer program is reading e.g. 1003 22 or 2002 10 or 0210 03 etc. and therefore not sending anything back. I'm not sure how to synchronize this so if you have any more fine suggestions they are most welcome.

I have attached my two vi's (I ran the controller emulator on an old PC with LV 8.5...) 

best regards

[soeren]

A little update...

In "read controllerstring.vi" I have put each of the VISA read blocks in a sequence and tested what was going on. It looked like the second read function reading either 0, 7 or 9 characters. didn't execute all that often, so I comparred the outputs of the two VISA reads, and after changing 0,7 and 9 to 0,4 and 6 the "data" string seems to be ok and not broken as it was before. Sometimes the program stalls or other strange errors occur when it runs for a long time. But at least some things seem to work (only at 9600 baud for now). After these changes, the warning 1073676924 is always present, and I'm not sure what to do about it.

[Albert.Geven]

Hi

That warning is saying that it did what you asked and that maybethere are more characters available that you did not ask for.

The best you can do is to immediately skip this specific warning.

if you  right click on the errorcode value you see a slection and the highest says explain warning.