Serial Communication

[kilaru]

HI,

I have a trouble to take data from balance with respect to time via RS 232 interface. After some time hitting run, it was giving an error message that error occured at VISA read with code -1073807339 and Operation timed out before completion of execution.

I'm Novice in programming with Lab VIEW, any suggestions would be greatly appreciated

Thanks

Kilaru

[Mike Ashe]

HI,

I have a trouble to take data from balance with respect to time via RS 232 interface. After some time hitting run, it was giving an error message that error occured at VISA read with code -1073807339 and Operation timed out before completion of execution.

I'm Novice in programming with Lab VIEW, any suggestions would be greatly appreciated

Thanks

Kilaru

Could you tell us a little more about your application and/or upload a VI/LLB that shows what you are trying to do and the problem? Also, you should take a look at the examples in LabVIEW for serial communications. Finally, are you sure the hardware you are connecting to is working okay? Have you tried to talk to it using a simple serial terminal application on the same computer as you have LabVIEW on?

[kilaru]

Could you tell us a little more about your application and/or upload a VI/LLB that shows what you are trying to do and the problem? Also, you should take a look at the examples in LabVIEW for serial communications. Finally, are you sure the hardware you are connecting to is working okay? Have you tried to talk to it using a simple serial terminal application on the same computer as you have LabVIEW on?

Michael,

I'm uploading my program. Please check this out. I'm not sure how to check whether hardware working properly or not. It was mentioned in the manual that interface should connect with DTE(computer) with female, but I end up with both male at the computer. So I used another pin to change it to female at DTE.

Thank you

Kilaru

Download File:post-3413-1131130946.vi

[WMassey]

I'm not sure how to check whether hardware working properly or not. It was mentioned in the manual that interface should connect with DTE(computer) with female, but I end up with both male at the computer. So I used another pin to change it to female at DTE.

Kilaru

A long time ago (at least in computer hardware terms) the folks who came up with the RS-232 communications specification decided that there would be two broad classes of equipment. DTE (Data Terminal Equipment) and DCE (Data Communication Equipment).

An RS-232 communication link was expected to have a piece of DTE at each end with DCE in the middle. As you might guess, teletypes, terminals and computers are considered to be DTE and things like modems are considered to be DCE.

The specification actually went on to say all DTE connectors would have male pins and be wired in a certain fashion and all DCE connectors would have female sockets and also be wired in a certain fashion. In the case of DB25 connector, for DTE, pin #2 was for transmission of data out from the DTE and pin #3 was for receipt of data coming into the DTE. On the other hand, for the mating DCE connector, socket #2 receives data into the DCE and socket #3 transmits data out of the DCE. This makes sense so far - pin#2 transmits & mating socket #2 receives - and - pin #3 receives while its mating socket #3 transmits - you can practically see the data flow.

But if you go on to imagine what's going on in the DCE you will soon realize it has a female connector on each side of it and, on both those connectors, sockets #2 receive data into the DCE and both sockets #3 transmit data out of the DCE. Obviously the only way that this will actually work is if the transmit and receive lines (and all the other handshaking lines as well) get swapped within the DCE. That is exactly what happens.

The bottom line here is that between any two properly-wired pieces of DTE, you need a piece of DCE to cross the signals over between the transmit and the receive pins. Assuming you don't need a real modem to cover an extended distance, you will at least need a "NULL MODEM" to swap the signals as they pass through.

Null modems usually fit in the palm of your hand and have a female DCE connector on each side and look a lot like a gender changer. You can also get null-modem cables that just plug into the DTE on each end. For that matter, there are also non-standard null modems that are male on each side, or male on one side and female on the other. They are usually labeled "null modem" but you can always get out a continuity tester or ohm meter and see if the pins run straight through or else get swapped.

Many manufacturers of DTE don't follow the RS-232 spec and you can get DTE with female connectors or DTE whose connectors are wired like DCE with the transmit & received signals swapped. All you, as a use can do, is to read the documentation and keep a supply of cables, null modems and various gender changers around and keep reading or trying various combinations until you find the right one that works. It usually doesn't take too long.

Attached is a file from NI that provides some useful info on serial communications.

Download File:post-2800-1131137043.pdf

[Mike Ashe]

I'm uploading my program. Please check this out.

Hmm, doesn't appear that you are initializing the port first. Look at the examples in the Simple Serial library in LabVIEW:

C:\Program Files\National Instruments\LabVIEW 7.0\examples\instr\smplserl.llb\LabVIEW <-> Serial.vi

The "LabVIEW <-> Serial.vi" will give you a very basic template to: Open -> read|write -> Close the serial port. You cannot get much simpler. Make sure you are reading at the same baud rate as the Ohaus (I used to use Ohaus years ago). Remember that these will only give you a single read. There is another example of how to do a read with a timeout. To get real communication you might want to modify this example to put the serial reads and writes in a loop. You can also look for examples on NIs DevZone.

I'm not sure how to check whether hardware working properly or not. It was mentioned in the manual that interface should connect with DTE(computer) with female, but I end up with both male at the computer. So I used another pin to change it to female at DTE.

Assuming you are using Windows, go to Start > Programs > Accessories > Communications > HyperTerminal to get a simple application to read and write to a serial port. Use that to test out your device and make sure it communicates with the computer first, then use LabVIEW.

Gotta go, good luck

[kilaru]

Hmm, doesn't appear that you are initializing the port first. Look at the examples in the Simple Serial library in LabVIEW:

C:\Program Files\National Instruments\LabVIEW 7.0\examples\instr\smplserl.llb\LabVIEW <-> Serial.vi

Assuming you are using Windows, go to Start > Programs > Accessories > Communications > HyperTerminal to get a simple application to read and write to a serial port. Use that to test out your device and make sure it communicates with the computer first, then use LabVIEW.

Dear Michael,

As I opened the Hyper Terminal, window named <new connection> was displayed. In the Name block I have given some name, then it gave, choose the country region to make phone call, area code, phone no,

in the connectiong using block, there were several options COM1, COM2 and TCP/IP

Then Click OK.

then display to set port settings,

I set baud rate:9600

Data bits: 8

Parity: None

Stop bits:2

Flow control: None

Then Hyperterminal window was opened and it was showing connected but not giving any data on the screen.

Its not making any sence to me giving region, area code and phone no. to setup hyper terminal connection. I wanna make sure about that.

I guess I lost somewhere.

Thanks

kilaru

[Harish]

Hi,

Can some one help me with some examples of performing serial communication classes using GOOP?

I am new to GOOP, and want to perform some basic read / write functions using classes and objects.

Thanks in advance!

Harish K

[Aristos Queue]

QUOTE(Harish @ Sep 5 2007, 06:55 AM)

Can some one help me with some examples of performing serial communication classes using GOOP?

I am new to GOOP, and want to perform some basic read / write functions using classes and objects.

GOOP or LVOOP?

If you're wanting to transmit the object from one LV to another LV:

If you're using LVOOP

-- the .lvclass files that are natively built into

LV

in version 8.2 and later -- you can just send the objects to the other system using any of the

LV

data communications protocols. You could, for example, use a Call By Reference node to pass the data by terminal. Or flatten to a string and use TCP/IP prims to send the string and then unflatten it on the other side. You just have to make sure that the .lvclass file itself is already loaded into memory in the remote system. An example that might be helpful is

<labview>\examples\lvoop\Read Write Class Data To File\Read Write Class Data To File.lvproj

Although this shows file IO and not communication, it shows how the object data can be treated as any other

LV

data.

If you're using one of the GOOP toolkits

-- Endevo's GOOP Toolkit, OpenGOOP or dqGOOP -- you'll have to talk to the authors of those tools for information on how to send an object from one system to another. I know that the objects themselves exist only locally, and I don't know what communication systems they've built.

If you're wanting to just create serial output of the object for sending to some device:

In both LVOOP and GOOP,

just create a VI that takes the object in and produces a string output and generate whatever format string you need for the device.

Helpful?

[jdunham]

QUOTE(Aristos Queue @ Sep 5 2007, 07:14 AM)

GOOP or LVOOP?

If you're wanting to transmit the object from one LV to another LV:

...

Helpful?

I think Harish was talking about treating his instruments as objects, and how you would create an instrument driver using an object-oriented approach.

I'm still pretty new to LabVOOP and OOP in general, but it seems like you want to think of all the stuff the instrument driver knows, but which the rest of the program shouldn't care about, and make that your class's private data. Then you would think about all the actions you perform on the instrument and make them into methods, along with other methods to do any necessary manipulation on the private data.

I think it can be pretty easy to make that disctinction between public and private, because you could say "If I changed to a different instrument from another vendor, what items would change and what would stay the same?". Anything which is likely to change should be private to your object.

The open question is how much benefit can you get from inheritance. It's plain that you could make a class for a generic instrument and then a generic oscilloscope which inherits from it, and then have children for different scope vendors, but if you just have one scope on your bench, it probably isn't worth the trouble to create that model and implement the hierarchy.

Of course if someone reading this knows it is worth the trouble, you should use all of the time you saved to tell the rest of us the story! :worship:

Jason

[Jan Klasson]

Here are some serial classes I did in prehistoric time (probably LV 4). Attached is a png describing the design (as I recall it).

The Serial class configures the serial port at object creation (this was a by-reference class so there was a Create method). Send - sends the message string, Receive - makes a blocking call to the serial port driver and wait for data to arrive.

The InputStream and OutputStream packed/unpacked the messages received over the serial bus. A custom application protocol was used.

The InputStream -Subscribe allowed client objects to subscribe for various messages by name.

InputStream:Read - returns the latest message

InputStream:Process - a process VI running in the background. It calls Serial:Receive and waits for message strings to arrive. When a string is received the Process method unpacks it into the application protocol message data structure. Thereafter the message is distributed to all subscribers of that message.

OutputStream:Write - takes a message data structure as a parameter, packs the message into a string and adds it to the internal send queue (attribute "msgs").

OutputStream:WriteContiuousMsg - adds a message which is to be repeated with fixed intervals, otherwise it does the same job as Write.

OutputStream:Process - Executes periodically to ensure the continuous and non-continuous messages are send. Calls Serial:Send to send a string over the serial bus.

I guess the main point of the design is that it separates two protocol layers. The Serial class encapsulates the serial bus driver and sends/receives strings. The InputStream/OutputStream encapsulates the application protocol, these messages where described with a type def.

Jan

[LAVA 1.0 Content]

QUOTE(jdunham @ Sep 10 2007, 04:56 PM)

I think Harish was talking about treating his instruments as objects, and how you would create an instrument driver using an object-oriented approach.

If this is indeed Harish's question, look at this post:

http://forums.lavag.org/Instrument-Driver-...p;mode=threaded

IVI is form of instrument abstaction, but the problem is you can't edit it from LabVIEW. Thats why I prefer Plug-And-Play.

[MikaelH]

QUOTE(Harish @ Sep 5 2007, 09:55 PM)

Hi,

Can some one help me with some examples of performing serial communication classes using GOOP?

I am new to GOOP, and want to perform some basic read / write functions using classes and objects.

Thanks in advance!

Harish K

Here's an undocumented GOOP class I've used in the past (just upgraded it to 821-lvoop style, and haven't tested it).

You need the _goop3.llb in your addons-folder.

(you can get it through the GDS tool).

Download File:post-941-1189566714.zip

Cheers,

Mikael