Serial Port Problem

[Zac]

Hi, I have searched through the serial wiki and some forum topics regarding the use of serial communication in LabVIEW and still have no idea which direction to approach my problem.

My problem is that I am currently developing a LabVIEW program that acquires data from a third party program which accesses a 3 component measurement balance. The third party manufacture is unwilling to co-operate in bypassing their software and working purely in LabVIEW and as such i am faced with a measurement device connected via serial port for which i do not know the commands associated with reading the data. The balance itself consists of 3 displacement sensors, each with a signal conditioning unit. The three signal conditioning units are connected in serial and the output from the last one into the computer.

My main question is how to approach the problem, having little experience of serial communication. My first thought is to open up the signal conditioning boxes and identify the chips inside. Also I have considered running a serial port monitor on the computer and analysing the raw data. Both are starting point which I'm not sure how to follow.

Any and all advice would be greatly appreciated,

Thanks,

Zac

[Zac]

Hi, I have searched through the serial wiki and some forum topics regarding the use of serial communication in LabVIEW and still have no idea which direction to approach my problem.

My problem is that I am currently developing a LabVIEW program that acquires data from a third party program which accesses a 3 component measurement balance. The third party manufacture is unwilling to co-operate in bypassing their software and working purely in LabVIEW and as such i am faced with a measurement device connected via serial port for which i do not know the commands associated with reading the data. The balance itself consists of 3 displacement sensors, each with a signal conditioning unit. The three signal conditioning units are connected in serial and the output from the last one into the computer.

My main question is how to approach the problem, having little experience of serial communication. My first thought is to open up the signal conditioning boxes and identify the chips inside. Also I have considered running a serial port monitor on the computer and analysing the raw data. Both are starting point which I'm not sure how to follow.

Any and all advice would be greatly appreciated,

Thanks,

Zac

[LAVA 1.0 Content]

Spying on the serial connection can be done with 'portmon' however using a device when you don't know exactly the protocol is asking for issues.

What kind of device is this?

Ton

[LAVA 1.0 Content]

Spying on the serial connection can be done with 'portmon' however using a device when you don't know exactly the protocol is asking for issues.

What kind of device is this?

Ton

[Anders Björk]

QUOTE (Ton @ Jan 17 2009, 11:30 PM)

Spying on the serial connection can be done with 'portmon' however using a device when you don't know exactly the protocol is asking for issues.

What kind of device is this?

Ton

Do you have control software from the manufacture, using portmon seems to be a good solution to get the control codes as well as settings for the serialport!

http://technet.microsoft.com/en-us/sysinte...s/bb896644.aspx

[Louis Manfredi]

QUOTE (Zac @ Jan 17 2009, 05:06 PM)

The third party manufacture is unwilling to co-operate in bypassing their software and working purely in LabVIEW and as such i am faced with a measurement device connected via serial port for which i do not know the commands associated with reading the data.

Hi Zac:

Using Portmon, or something like it, is a very good approach. Often serial communications between instruments and the host computer is in printable ASCII, sometimes it is even in a human-readable form.

Another approach is to try getting in touch with different people at the instrument manufacturer. If you can get in touch with a technical back-office person somehow, and chat up with them what you are doing and why you want to bypass their software, you might get lucky and get a copy of the communications protocol specification from them. We engineers love to talk about our work.

At very least, you should try and find out why they don't want you to bypass their host software. A number of possible reasons:

1. There's a lot of complicated and perhaps proprietary final signal conditioning done in the host. (In this case, you probably don't want to try and bypass the host firmware.)

2. Disclosing the communications protocol might disclose something about how the sensors work that the manufacturer would rather keep quiet. (In which case, portmon is the best bet, unless they have taken the trouble to encrypt the communications.)

3. The manufacturer hasn't done a publication-quality specification, and is ashamed to show what they've got. (Offer to sign an NDA, and to take what they have without criticism. Even if its not totally complete or accurate, it will help you when you go to portmon.)

4. The manufacture simply doesn't want to go to the trouble of supporting a bunch of programmers all trying to write slightly different programs, in different languages. It is easier for them to support just the one simple case of the instrument talking to their own software. (Again, offer to sign an NDA and promise not to burden tech support with questions, and they might give you what you need.)

In any case, if the manufacturer is unwilling to provide support for you directly communicating with their instrument and if they actually intend to stay in the business of selling instruments to the technical community, they should provide LabVIEW drivers for their instrument. If worse comes to worse, nag sales staff about this. Unfortunately, I've found that many LabVIEW drivers for non-NI instruments are atrociously written by text-line programmers who haven't got a clue about LabVIEW programming. Often, however, these programmers don't know LabVIEW well enough to know how to lock the block diagram, so the "LabVIEW drivers" are at least useful as an awkward documentation package for the communications protocol so you can write your own from scratch.

Just my thoughts on this, hope to have helped,

Louis

[Zac]

Hi guys,

Thanks very much for all your input. I will definitely try to get some more information out of the manufacturer. The equipment by the way is a 3 component inverse pyramid style balance for measuring lift, drag and pitching moment, manufactured by Aerotech ATE. There is some information on it online but only for the mechanical operation here.

There are calibration matrices within their software which we are hoping to be able to replicate using some basic calibration ourselves, I think the main reason they are unwilling to co-operate is they are pushing the use of their new software, which is currently in beta i believe. But the main reason for needing to bypass is that the final goal is to run via an embeddable device like cRIO due to the required level of stability. I haven't had a chance to work on this project this week but will be back on it by next week and hope to be able to put some time into solving this problem.

Thanks again for your help,

Zac

[loserboy]

ask them if they are using one of the standard serial bus protocols like modbus or hart.

labview has a library of serial communication vi's in modbus.llb

[Louis Manfredi]

QUOTE (Zac @ Jan 19 2009, 11:49 AM)

The equipment by the way is a 3 component inverse pyramid style balance for measuring lift, drag and pitching moment, manufactured by Aerotech ATE. There is some information on it online but only for the mechanical operationhttp://www.aerotech-ate.com/downloads/3%20Component%20Balance.pdf' rel='nofollow' target="_blank"> here.

Pretty cool project-- If it is for a wind tunnel, my previous comment about LabVIEW drivers goes in spades.

Worst comes to worst (and only if worst comes to worst) chuck their software, and also chuck their electronics, and wire the strain gauge bridges directly into a cRIO A/D convertor. (I believe NI makes a strain gauge bridge device for cRIO.)

Best, Louis