BAUD RATES?

[PETRAN]

Hi Guys,
does anyone know the maximum Baud Rates and the standardized values of RS 232, RS 485 and USB interface?

Does LabVIEW 6 support communication with RS 485 or USB?? What do I need?

Thanks, Peter

[ThomasD]

Hello Peter,

LV 6 does support communication with RS-485 and USB.

You can see some informations about the baud rates in the following links.

http://digital.ni.com/public.nsf/websearch/2ad81b9060162e708625678c006dfc62

http://zone.ni.com/devzone/conceptd.nsf/webmain/67E175B2AF9AA10286256A9D0078E2E7

Regards ThomasD

[parthabe]

HI!

Baud rates should either be 9600 or 19200, but I'm not sure.

Please check with your requirement.

Regards,

Partha.

[LV_Pro]

What is it you are trying to do? The maximum rate for your port is whatever the manufacturer of your port made it. On this PC WindowsXP would allow me to set the baud rate for the RS232 port to 128000. Its default is 9600, which seems pretty common. But it isn't the PC's port that is usually the issue, rather the instrument or other device that you are trying to talk to, and those vary widely. As to USB under LabVIEW, that is a lot more complicated issue, I suggest you do a search on USB and LabVIEW to see what some of the concerns are. RS-485 is another beast entirely. While strictly speaking you can communicate over the "RS485 bus" be careful to determine what the communications protocol for your connected devices is. RS485 allows multiple devices to all reside on the same 2 wire "bus", using a master/slave set up that allows the master to "address" the specific slave that is to receive the information. The problem occurs with how the addressing scheme frequently works, which is to use a 9th "address" bit to signal that the packet is an address rather than data. This can be done in LabVIEW (and other languages) by playing with parity, etc., but usually the timing is critical. I worked on a project last year where I had to do this and found that if you changed parity too quickly you could actually cause the port to change in mid transmission, while it was transmitting the "character", rather than between characters. Was a pain in the rear to figure out what was happening, would probably still not understand why my program "sort of worked" at that point if one of the engineers there hadn't had a cool little serial port monitor utility and cabling.

So the first question is, what is it you are trying/planning to do?

Putnam Monroe

North Shore Technology, Inc.

Message Edited by LV_Pro on 10-05-2005 08:22 AM

[PETRAN]

The thing that I'm trying to do is to control a digital B/W camera (module m4088 & ov5017 image sensor, 288x384 resolution) via a PIC microcontroller and send its data  through serial port to LabVIEW. The camera sends bytes (1 byte = 1 pixel) which I'm trying to capture and put in an array form (288x384). Then, I convert every byte to picture (via "Draw 8-bit pixmap.vi") That's why I need high Baud Rates (eg: 1 Mbps - 1,5 Mbps) in order to achieve that video streaming. I attach the block diagram of that concept. Could you tell me if it is OK and some advices of how to achieve high Baud Rates.

Regards, Peter

[johnsold]

Peter,

For large arrays and high speeds initalize the arrays outside the loop and use Replace array subset rather than building the array with indexing at the loop border. LV automatically allocates memory for the arrays. As they grow it must re-allocate memory and move the data. Gets very slow for large arrays. At 100 kB your array is not huge, but several reallocations may take place during one picture acquisition.

Decimal String to Number with a datatype of U8 or Typecast to U8 might be faster than the String to Byte Array + Index array that you are doing now.

Take the indicators out of the loop. Writing to the screen will definitely slow things down. What if no byte is received? If Return Count = 0 do not modify output array.

Lynn

[Ben]

I agree with all of the above and am motivated to play the part of the "wet blanket".

Correct me if I am wrong PLEASE!

Baud = bits per second

With 1 start and 1 stop bit, that gives us 10 bits per byte. Do the math... it will take about 100 seconds to transfer 1 image.

So the slow part of this game is the wire (physical) and not the wires (virtual).

Ben

[PETRAN]

Hey Lynn (johnsold),

because of the fact that I'm not that experienced in LabVIEW as you are, I tried to apply your advice in my block diagram but it didn't come off.  Maybe I did something wrong.  (I attach the new vi). Could you please check if that's what you told me to do. Alternatively, if you could correct it, I would be appreciative.

Peter

[johnsold]

Peter,

I may have thought that you were more experienced than you are. I neglected to say that you must also use shift registers.

I have modified your VI to use shift registers and cleaned up a few things. Also, look at Ben's note about data rates.

Lynn

[PETRAN]

As I was waiting for your reply, I managed to make a block diagram that has (I thing) the same result. It contains while loops and misc functions(if you want I'll send it to you). Now I start getting the meaning.

Thanks Lynn, I appreciate your vulnerable help! Your hints are also very useful!

Peter