unexpected hexadecimal 00 send over serial communication

[Christine T]

Hi,

I'm connecting a Tesa tt20 with a serial port. TT20 measures thickness and returns a 6 digit fractional number (0.0000). Communication works fine on most desktops and/or laptops. I have to say that i throw away the first measurement, because values where not to be trusted.

In one case, the following occures :

Sometimes there are gaps between the numbers.

Something like this : 1. 23 or 0.0 2

Examining this string in codes display, the gap appears to be \00 or in very rare cases \s

When we connect a laptop on the same TT20, communication works fine

It seems to be a problem with the desktop, some kind of setup -parameter ?

I was wondering if anyone has encoutered the same problem ?

Thanks in advance

Regards

Christine

[Wayne.C]

Christine,

You may be seeing some sort of transmission error.  When VISA encounters a byte of data that arrives with an error ( parity, etc ), it uses what is called an Error Replacement Character.  The default just happens to be  /00 (null).  I suggest you change the default to some other character and see if you mystery character changes.  This character can be changed by using a property node to set Property: Serial Settings : Error Replacement Character.

There may be some small timing differences between the two PC's that are affecting your vi.

One question, is the /00 an extra character in the expected data or is it replacing a character in the expected data?

[Christine T]

Centerbolt,

I will certainly try to change the replacement character ! Thanks

Answer to your question : The mystery character replaces a character in the expected data

Thanks in advance

Regards

Christine

[Wayne.C]

Christine,

If you verify that it is a transmission error, then the hard part starts.  What BAUD rate are you using?  You could try slowing it down and see what happens.

[Christine T]

Centerbolt,

The baud rate i am using is 4800, as specified for TT20

I will try to slow it down, but i thought that baud rate's are to be as specified ?

All serial Init parameters are hard coded. No operator is able to change them

It's strange that it works well with the laptop and not with the desktop.

It is not the usual serial communication

After i send the command, i have to set the DTR State to Asserted, and the RTS State Unasserted

Thanks for the advice

I'm going to make a test version of the program and send it through

Regards

Christine

[Wayne.C]

Christine,

I was assuming that the TT20 could communicate at different BAUD rates.  If the TT20 can only talk at 4800, then you are stuck at that rate.  This rate is so slow that I really don't expect it to be the problem.

There can be all kinds of timing differences between different computers.  Especially between laptops and desktops.  That means that a potential source of the problem is the hardware handshaking and the DTR and RTS lines.  Any chance that the state of one of these two lines is being briefly toggled at the wrong time? 

So lets consider what other things might be different.  You said this works on some computers and not on others.  Are you using the same physical cable when you use different PC's?  Are the laptops using a builtin serial port or are you using a USB-232 adapter of some sort?

Can you post a copy of your code that sends the command and reads the reply?

[Christine T]

Centerbolt,

I can only assume they use the same physical cable. The one that was delivered with the TT20

But i am not sure

This whole constellation is in China at this moment, so i can't pop over easily to check things out -)

I will ask the responsibles over there, to answer this questions

Regards

Christine

[Christine T]

Forgot to post the code

Christine

[Wayne.C]

Christine,

Looked at your code.  You are only setting the values of the DTR and RTS lines one place.  That seems a bit strange based on handshaking schemes I've seen in the past.  Do you have a copy of the communications spec for the TT20 you can post?  I'd like to review the protocol.

I did notice that you are writing the property node in the same sequence frame as your time delay.  The way this code is written, you don't know what will happen first.  It could be the delay or it could be the writting to the property node.   I am suspecting that this maybe part of the problem.  What version of LV are you running?

[Christine T]

Centerbolt,

I gathered a bit of info.

The same cable is used on desktop and portable

It seems to be an optical RS232

In attachment you will find the communications spec for the TT20. Not much to go on. But i am not a specialist on this.

I am using labv 8.2.1

You are right about the timing. I will make a version where i will make sure that the wait comes before the property node

Many thanks

Regards

Christine