has anyone made a custom com-1 output?

[binary_sandman]

[color=Green]our programing team has made a wonderful custom com-1 output and has a problem with establishing a connection and wondered if any other teams had this problem.The program via hex file has a problem sharing with the custom com-1 output their we have to run one at a time. when we have the custom com-1 open the the controller dose not Respond to drivers vies versa.
we think it has to do with program Identification with robot code.

[Justin Stiltner]

Sounds like your custom program is opening the com port and keeping it open or busy while the IFI loader is trying to open the port. Your programmers should be able to fix this by having their custom program close the port before the IFI loader attempts to use it. As most programs will not try to use the serial port if it is already in use by another program.

Also you may want to be more descriptive in your posts, by telling us that you have a custom com-1 output this could mean hardware or software, and what it does we don't know you are more likely to get responses and help if the person reading your post doesn't have to guess at what you meant or what is going on. Also com-1 is the designation that windows uses for the first logical serial port. Also spell check is a feature that you should always use before you submit your post. Welcome to the CD community and we love to help others and share information, just try to be a bit more descriptive about things in your posts

[Rickertsen2]

Windows allows access to serial port by only one program at a time. If one program already has it open, additional connection attempts will fail. To my knowledge, there is nothing you can do about this other than have one of the programs close the port before the other tries to open it.

As a side note, if your program crashes with the serial port open, there is no way to close it and make it available again other than restarting the computer. This is true in windows 2000. I assume it is true in other version as well. I share this because it caused me a day of frusteration thinking there was something wrong with my program.

[Mike]

Originally Posted by binary_sandman

[color=Green]our programing team has made a wonderful custom com-1 output and has a problem with establishing a connection and wondered if any other teams had this problem.The program via hex file has a problem sharing with the custom com-1 output their we have to run one at a time. when we have the custom com-1 open the the controller dose not Respond to drivers vies versa.
we think it has to do with program Identification with robot code.

I'll try to translate this...

Our programming team has made a custom program that attaches to COM1, but it can't establish a connection. Have any other teams had this problem? The program that downloads the hex file has a problem sharing the connection with our program, it only lets us run one successfully at a time. When we use our custom program, the RC will not respond to drivers commands via the OI. We think it has to do with the robot identifying the program.

Spelling and grammar are your friends. Thanks Dave =)

So from what I understand, you made some kind of a system to communicate with your robot. What is this program trying to do? The only data you can get from the RC is the hex file... not much use having that.

Assuming your using the programming port to send data and you are using this program to grab that information... there's no need for a custom program. All you need is a terminal program. I recommend Bray's Terminal, it's simple and it works. If you can't download anything onto the laptop, Windows comes with a terminal. It's called HyperTerminal and can be accessed by going to Start > Run and typing in hypertrm. However, if you do use this, be aware that it is a Windoze program and most likely won't work as expected.

Your interference problem will still consist with another terminal. You can't have two programs accessing one RS232 port... the one that got there first will lock all others out.

-Mike

[Alan Anderson]

Originally Posted by Rickertsen2

As a side note, if your program crashes with the serial port open, there is no way to close it and make it available again other than restarting the computer.

Restarting the computer to release a port is not always necessary. It's usually sufficient just to log off and back on again.

[Mike]

Originally Posted by Alan Anderson

Restarting the computer to release a port is not always necessary. It's usually sufficient just to log off and back on again.

Couldn't you also go into Device Manager and Disable/Enable the port?

I've never had this kinda problem happen to me, but I assume that would work.

[Matt Krass]

You can also get a utility from www.sysinternals.com to monitor and close the ports I believe, don't recall the name but take a look around it can't be too hard to find.

[Mike]

Originally Posted by Matt Krass

You can also get a utility from www.sysinternals.com to monitor and close the ports I believe, don't recall the name but take a look around it can't be too hard to find.

http://www.sysinternals.com/utilities/portmon.html
Portmon

[Astronouth7303]

Originally Posted by Rickertsen2

As a side note, if your program crashes with the serial port open, there is no way to close it and make it available again other than restarting the computer. This is true in windows 2000. I assume it is true in other version as well. I share this because it caused me a day of frusteration thinking there was something wrong with my program.

When I killed the cygwin version of picloader, it freed the serial port. (Windows XP.) Could be driver-specific, or a fixed bug.