AutoHotkey Community

Hey

thanks for a great script aobrien

Is anyone using this to transfer data files reliably? as in 0% dropped characters/extra characters? I'm interested in using it for CNC machine program transfer, but can't risk a single character misplaced. In tests it seems good, but I need a more thorough file compare method i fear...

also, is simultaneous communication over two com ports possible?

thanks aobrien and all
- joel

Hi Joel,

I'm glad that you like the script.

Well, I am currently using a modified version of the COM subroutines [modified to receive the COM specific filehandle] to simultaneously control 5 different serial ports.

I have had some good luck and bad luck with serial port reliability. The system that I am working with at the moment seems to eat characters off of the end of the string being sent. Other systems work flawlessly.

One idea to test the integrity of the path is to set up a loop and just cycle a file between PCs "n" number of times and then when it is finished check that it has been unmodified. Also, I would build some sort of checksum into the file transfer so that you could be very confident that the file is identical to the original.

aobrien

Thanks aobrien,

I have also had some success accessing multiple com ports, but haven't really pursued it much farther after also losing a couple leading and ending characters and getting worried.

I was never able to get it to replicate the problem reliably, but i like your idea of sending the same file back and forth n times and then checking it. I like to do the testing on the actual machines, but I'll probably set up the script to loop read/send, and then at the machine i can read/send/delete/read... manually a dozen or so times and see what happens...

a checksum would be difficult to handle with the limited processing capabilities on the machine controls (as far as a permanant solution) but on some of the newer machines might be possible...

thanks again

- joel

Hi aobrien (or other AHK experts),

I tried your marvellous COM script, and I noticed something weird about the processing of Space characters; they do not get printed in Notepad. Look at the 'COM port receive' loop.


If ASCII_Chr is a space, then nothing is appended to ASCII

If I use := instead of =, then the space is appended.


Does anyone else observe this?
_/ Louis

To facilitate observing the 'disappearing space' character, I paste a test script here for someone to try.
Would anyone know if this behaviour is by design?
_/ Louis

It is. You have to set AutoTrim, Off. By default it is On.

Hi Rabiator,

Thank you for clarifying this for me.

_/ Louis

can this script be used to read data from usb too?

no

Has anyone solved the problem of using a usb-serial adapter and higher com port? aobrien mentions about a "BuildCommDCB" error, which i've gotten. I know the fix; remapping the port to a lower number. It'd just be easier if you didn't have to do this.

hi guest3,

I ran into that same problem again (not being able to use USB-Serial adaptors on COM10+) and still haven't found the solution. Sorry.

It is starting to become a biger problem for me because I now have 10 serial ports connected to my test PC. I have to reconfigure the ports depending on the type of test I want to run... serious PITA.

WankaUSR, USB? As in a USB flash drive? I wish! I don't know anything about probramming a USB driver, however, I suspect that it is about 1000 times more complex than this little script. You can, however, use USB-Serial adaptors... I use them all the time as long as the COM port number is 9 or less.

aobrien

I solved the problem of the using USB-to-Serial adapters on COM10 and up.

The following instructions are modifying the original code from the second post(the one NOT using Port.dll).
I'm pretty sure this is the one that most ppl are using.

First, remove the COM_Port reference from the Script Variables section.

to



After reading through topics on MSDN, the COM port does not need to initialized in the BuildCommDCB; just in CreateFile. AFAIK, this is were the hold up was for aobrein and myself.


Next, I modified the Initialize_COM function as follows:

Remove krisky68's format area:and replace with


And then, under the Create COM File section, change:
to



Removing krisky68 code was needed because the COM port no longer exists in COM_Settings. This is also why COM_Port was made global.

@aobrien:
hope this works for you too

ps. i was guest3 in the previous post

AWESOME! trenton_xavier, you da'man!!!

I just tried your suggestion of removing the com# from the BuildCommDll DLL call and it allowed one of my USB-Serial adaptors to work at COM18. I tried again with the old code and it gave me "Failed Dll BuildCommDCB" error.

I didn't implement the change exactly as you suggested. I was able to implement your fix by moving krisky68's code up and adding only more one line of code to Initialize_COM().

Excellent work! Thanks so much!
aobrien

Hi, thank you for the great forum. I have a concept I would like to introduce, and wondering if any guru(s) know how to work this,

I have an application which binds to a COM port #. But, I would like to see the datastream. The way it is going so far, I am basically locked out from doing anything with the port while it is active.

Is this a no-win situation, or any ideas how I can make it work?

Thank you! --Golericas

@Golericas

I've been trying to do this as well and have been unable to(in AHK). It is possible and I use a program called PortMon from Sysinternals. It's free and works great. The trick to using it is to open PortMon and connect to the com port first, then open the program you want to 'snoop' on. If you try and connect after, it will lock you out.

PortMon @ Sysinternals: http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx

Maybe [aobrien] will have some input...