Serial Comms Issue

[Michael_Burgess]

Hi all,

got a uni assignment on @ the moment - revolves around a car simulator running on 2 PCs, one is the controls, one is the 'car' itself

talking over serial port

I have got a bit of the way into it but think my underlying framework is wrong - as for the workings of the car itself I have a fairly good idea of what needs to be done.

It's the sync'ing of comms that's the issue really

as it stands i have one while loop housing each vi. within that, on the controls VI I have a while loop that continually collates the value of the controls (steering etc) and whacks them into a string. Another while loop sends this string to the serial port. Another loop reads from the serial port. Another loop is dealing with the returned data and processing.

on the car itself VI the same principles apply. One is reading from the serial port and extracting the data, one is writing stuff back to the serial port, one is dealing with the received controls

I suppose the problem lies in the syncing of sending and receiving

the delay from moving the steering wheel to the wheels (for now using a meter to represent) moving on the car is bad - takes about 2 seconds which seems wrong

anyone got any suggestions on the basic framework upon which to build - thinking about starting again, but reusing a lot of my functionality on a more sound framework

christmas is going to be fun!!!! any help would be very much appreciated thanks - this is causing serious stress right now!!! :thumbup:

[rkanders]

Check if your loops are running at full speed. If you have multiple parallel loops running at full speed (or even one loop) it will starve the CPU. If that is the case, put a ms delay timer in you loops for say 50ms delay after each execution.

Also use profiler to find the slow parts of your code.

RK

Hi all,

got a uni assignment on @ the moment - revolves around a car simulator running on 2 PCs, one is the controls, one is the 'car' itself

talking over serial port

I have got a bit of the way into it but think my underlying framework is wrong - as for the workings of the car itself I have a fairly good idea of what needs to be done.

It's the sync'ing of comms that's the issue really

as it stands i have one while loop housing each vi. within that, on the controls VI I have a while loop that continually collates the value of the controls (steering etc) and whacks them into a string. Another while loop sends this string to the serial port. Another loop reads from the serial port. Another loop is dealing with the returned data and processing.

on the car itself VI the same principles apply. One is reading from the serial port and extracting the data, one is writing stuff back to the serial port, one is dealing with the received controls

I suppose the problem lies in the syncing of sending and receiving

the delay from moving the steering wheel to the wheels (for now using a meter to represent) moving on the car is bad - takes about 2 seconds which seems wrong

anyone got any suggestions on the basic framework upon which to build - thinking about starting again, but reusing a lot of my functionality on a more sound framework

christmas is going to be fun!!!! any help would be very much appreciated thanks - this is causing serious stress right now!!! :thumbup:

3084[/snapback]

[Louis Manfredi]

Also, be very wary of trusting Windows to do anything near promptly with serial comms. It Might go off and do routine housekeeping, or whatever else it does that takes time, and spend several hundred milliseconds doing pointless stuff before it actually gets around to putting your message out the port, or reading the incoming message from the port.

If you think this might be your problem, let me know. I've struggled mightily with this issue :headbang: :headbang: and I can discuss at (much) greater length if you think that this might be your problem. There's fairly easy things that help a fair amount, but it gets pretty tricky to get comm timing on a regular serial port down to the microsecond.

Any possibility of doing both jobs on a single machine? Nah, I suppose you would have if you could have.

Best Regards, & Good Luck, Louis

[Michael_Burgess]

hey guys - thanks for the replies - what is this profiler? Will the help function explain it well? I do have delays on my loops - for the reason you stated - around the 150ms mark, just to stop labview thrashing away too much this is such a hard assignment lol!

Louis - i'm fairly sure what you said is the issue - labview is thrashing away at the port but it seems to take a computing age for things to get through if you have any tips it'd be much appreciated cheers

the assignment is using 2 PCs - bit daft - I have 2 so can do it at home, but most people won't and means they'll need access to uni over xmas instead of going home!

cheers guys

[rkanders]

Tools->Advanced->Profile VIs

shows you how much time/memory is spent per VI

I personaly have never had much of an issue with serial ports, but I have never done anything that requires even ms response from serial port. IMHO serial port is more limited by coms speed then anything else.

Your problem is probably some sort of coms termination character issue, that would be only reason why labview spends time at the port. So make sure that when you read from the port that your timeouts and termination characters are setup properly.

RK

hey guys - thanks for the replies - what is this profiler? Will the help function explain it well? I do have delays on my loops - for the reason you stated - around the 150ms mark, just to stop labview thrashing away too much this is such a hard assignment lol!

Louis - i'm fairly sure what you said is the issue - labview is thrashing away at the port but it seems to take a computing age for things to get through if you have any tips it'd be much appreciated cheers

the assignment is using 2 PCs - bit daft - I have 2 so can do it at home, but most people won't and means they'll need access to uni over xmas instead of going home!

cheers guys

3098[/snapback]

[Louis Manfredi]

Louis - i'm fairly sure what you said is the issue - labview is thrashing away at the port but it seems to take a computing age for things to get through if you have any tips it'd be much appreciated cheers

cheers guys

3098[/snapback]

Hi Michael:

Here are some of the easy things you can do to tighten up Serial communications:

1. Turn off the FIFO buffers for your serial port. In Windows XP, one path to this is:

Control Panel>System>Hardware tab>Device Manager>Ports>COM1(or COM whatever)>Port Settings>Advanced...>Uncheck the Use FIFO buffers checkbox.

(While you are in there, click on the resources tab of COM1 and make a note of the I/O range setting for the port. If you are really desperate, you'll use that data to bypass the operating system and control the port manually, more on that later.)

2. (Now obviously this is something you might NOT want to do for other reasons, use your

judgment, and only do things you ar certain you can reverse...) Uninstall all Network adaptors and drivers especially for types of networks which are not connected. Windows spends lots of time, and quite often, checking network connections. I've heard-- though I never checked this out myself-- that it takes more time looking for network connections that don't exist than serving those that do. (Thank you Bill Gates... :ninja: )

3. Try to minimize background processes. Turn off automatic file compression. Don't run other applications while you are running your program,especially MS Office applications-- They bog thing down by taking huge amounts of memory, and some processing time, even when they are in the background. Virus checking is another background process, but I'm reluctant to suggest you shut that off-- unless you have had a recent scan, and are sure that your machine is isolated from sources of infection while you have it shut off. Make especially sure that any application which might be trying to share your serial port is firmly shut off.

4.Put a Priority on your application with the system scheduler. For XP, one path to the setting is:

Right-click on My Computer Icon > Properties>Advanced Tab>Performance settings button>

In the Visual Effects tab, click adjust for best performance (If your current settings are "Custom" and you like them, make a note of what is checked first!). Then, in the Performance Options>Advanced tab, select "Programs" button for both processor scheduling and Memory usage. (These settings seem to have far less impact on things than I recall from my old days working on Macintoshes-- there you could really make the OS take a back seat to the job your were trying to get done... As far as I know you can't really do this in Windows. (Again, :ninja: but if someone else knows different, speak up, I want to know how too!)

5. Use the VISA read/write VIs rather than the older Serial vis. (Looks to me like the older serial VIs are gone from the menu in version 7.1.1-- I hadn't noticed when they disappeared -- for a while both were present.) The old serial VIs relied more heavily on the high-overhead operating system while NI did some more efficient programming of their own to implement the VISA routines. If it seems like you have choice, try the VISA routines.

Medium difficulty things:

1. Check basic LabView Programming style-- Understand the priorities on any potentially competing VI's which may be running in parallel. Make sure that you have put delays in all your User Interface routines. (If you are updating a digital display, it doesn't need to be done more than once every 200 ms or more-- most of us can't read that fast. For analog displays tachometer dials, etc) updating every 50 Ms or so should be plenty to make needle movement seem smooth (assuming the data displayed is coming to it smoothly.

2. Do a timing budget on your comm channel-- probably not your problem, as you are probably dealing with simple short messages, but good habit to get into. Take the number of bytes in your outbound and inbound messages, add them, multiply them by ten, and divide by baud rate. Add the latency of the device that's sending you the data. Draw a timing diagram. If there's a problem, increase your baud rate if you can, make your messages shorter if you can, look at changing the order you do things for efficiency. For example the straigtforward:

Poll for data>Wait for data>Receive data>Process data>display data

approach puts things strictly in series.

You might want to:

Poll for Data Frame n>Process data frame n-1>Display data frame n-1>finish waiting for data>Receive data frame n.

This puts some other tasks in parallel with waiting for the data to come back.

Difficult approach:

You can write directly to the serial port, using the "Out Port" and "In Port" Vi's and the port addresses you got from the COM1 resources tab. You only want to do this if you really have to. Its considered pretty poor style, but I've found occasions where it was the only thing that would work. If this is a class assignment, check with your professor first, he or she probably doesn't want to get into this level of detail. If you really need to do this, back up your system first, you'll be treading in the minefields of register programming. Then look up the data sheet for the 16550 UART, or see chapter 12 of "The Undocumented PC" by Frank van Gilluwe, Addison Wesley, ISBN 0-201-47950-8, or check with me if you can't find the references. Using this approach I have been able to transmit serial messages usually (but not always) within a few hundred microseconds of when I wanted to, and to transmit serial messages on multiple ports almost always within a few dozen microseconds of simultaneously to each other.

In any case, best Luck, Louis

[Mark Balla]

I posted some serial vis it the Hardware section in the beginning of December.

take a look at them and see if they help you out.

http://forums.lavausergroup.org/index.php?showtopic=927

[Michael_Burgess]

thanks for all the help on this guys

I got 90% and am very chuffed!

was worth 50% of a final year module!

thanks!