Problem with other PCs interfering with Labview serial communications

[tmunsell]

I have created a Labview application for real-time monitoring of jet engine test data.

We are using a Daytronic System 10 data acquisition unit with three 25-pin serial connectors on the back of the DA unit connected to 3 PCs.  We have used this configuration for several years.

If I run the Labview app alone, the data looks fine.  But, if I start any of the other PCs, the Labview data gets corrupted as soon as one of the other PCs starts polling the System 10 for data.  The three PCs use three different types of software and drivers.  One (the one we NEED to have running along with the Labview system) is using Wonderware DDE software to interface with a MS Excel spreadsheet that displays data in 1 second intervals where we can run macros to save certain data points in a specified format.  The next PC uses (obsolete) Autonet software, which is the one we are replacing with the Labview system.  The third uses the Monico Monitoring system software so our customers can connect with WebEX to view the run off-site.  We will soon be using Labview for this purpose as well.

They are all using 25 to 9 pin serial cables.  I've swapped cables and swapped them to different System 10 ports, but the problem still occurs.  The other 3 PCs all work fine together.... no garbled data at all.

Could this be a problem with the System 10 config or something in Labview?  I've tried using the VIs downloaded from both the Daytronic and Labview websites for the System 10.  The basic interface VIs for Labview version 8 don't seem to work at all, so I'm using the version 7 VIs.  Also, for some reason, I have to run, then close the Daytronic "Basic System Config" VI before my app will even start reading the data correctly.  Once I do that, provided no other PCs are running, it works fine.

We have four engines to test next week and I'd like to wring out the application during the tests.  Any assistance would be greatly appreciated!

[Albert.Geven]

The only thing I can think of is that the older software is slower on the bus or taht your new system is using a bad handshake protocol
or no handshake on the serial line.
That would not hinder the receive in LabVIEW but the sending.
Is the labview software (vi's) publicly available?
I mean can you post your application to this forum?

If not first check a possible handshake,
And second I don't understand why that first vi does not belong to your application.

[Wayne.C]

Todd,

You mentioned 3 serial connections to back of System10.  Does that mean that there are 3 serial ports on the device or are the cables just connected in parallel to the same serial port?

[TMC-NI]

Hi Todd,

Are you using your LabView application strictly to get the data from your System 10?  There is no logging right?  So when you say the data becomes corrupted, you mean that your acquisition values coming directly from the Daytronic system are corrupted right?

From what I can see, the default serial configuration for the System 10 is 19200,n,8,1.  This is different from the industry standard, which is 9600,n,8,1. (Where n is the com port assignment).  I am wondering if the issue is simply due to baud rates not matching up for one reason or another.  Have you tried speeding up or slowing down the the baud rate on the System 10 by using the BAU command?  (I do not have the manual so I don't really know how the format would be)

[tmunsell]

Actually, I finally managed to get the problem fixed with some help from our Daytronic rep.  There was one setting on the system 10 that had to be changed on that particular serial port.  All is working well now.  Thanks for the input!  Now, if I can only get the stopwatch vi to work inside the main app without preventing the main vi from running continously.....

[Albert.Geven]

Use a while loop inside the vi instead of the run continuous button.

[tmunsell]

Problems solved.....  I do have a while loop in the main app, and it's working fine now.  I decided to run the timer/stopwatch as a seperate app that stays on top of the main screen's front panel.  Everything is working perfectly now.

The only thing I have left to do is to set a user-adjustable delay (screen update) for a couple of the channels.  Sometimes we have vibration spikes that quickly go away and I'd like to be able to slow the screen update slightly so they don't set off the warning lights.  I finally got a copy of "LabVIEW for Everyone" and it's very good at explaining the software to the new user (like myself).  🙂

Thanks again for your help!


Message Edited by tmunsell on 01-30-2008 05:36 PM