Procomm cannot access ports over COM9 reliably

[juski]

I have a procomm script which cycles through a number of COM ports to configure units connected to each port in turn.

The script works fine, it goes through and sets everything up nicely.

When the script gets to Com10, Com13, Com14, (and Com20, 23 & 24 for that matter) I get the error "port not responding - COM1".

The host PC is equipped with a 32 port Rocketport serial card - the terminal software supplied with the card works with ALL of the ports, so the problem lies with ProComm.

I have edited pw4.ini as suggested by symantec's knowledgebase and Procomm can 'see' all the ports above COM9 but as I say, it can't open 10, 13, 14, 20, 23, 24, 30, 33, 34 for some reason. The Rocketport ports start at COM5 FYI.

I realise that the pw4.ini file workaround isn't guaranteed to work with all hardware - but - does anybody know of a workaround for this problem? I've already thought about skipping some ports in my setup but I really need all 32 ports to work!

I have hit upon the idea of making a program (or DLL) which gets passed a string to it as a parameter. The COM port to use would also be passed as a parameter...

In the current script I use 'waitfor' quite extensively - so I would also need a program or DLL to replace that.

Can anyone help?

 

[knob]

To the best of my knowledge, no one has been able to get this to work. I tested this when development of this change was being implemented in version 4.7, and it was deemed too "raw" and untested that it was not advertised. I am not certain why Symantec advertises this setting since I have never heard of anyone using it successfully.


aspect@aspectscripting.com

http://www.aspectscripting.com

 

[juski]

Thanks for your reply, knob.

I suspected that nobody here would have got it to work. Because of this, I'm undertaking a crash course in C programming to make two DLLs - one to transmit a string and another to do the same as a 'waitfor' command.

It's a complete pain in the .... but there's never anything wrong with having to learn 'proper' programming I suppose.

Knowing what I've learned about controlling COM ports in the last day or so, I can't understand why Symantec don't just change the way they address the ports... i.e. use "\\\\.\\COMx" with a filewrite function... ho hum...

Of course when I've learnt how to do that, it might even be straightforward enough to write a whole application in C or VB to do what my ASPECT script does.

 

[dblprops]

Juski,

I am having similiar issues with Procomm not being able to access COMM ports above COM9. I did the hack and it now sees them but can't/won't access them.

Did you ever come up with a solution?

Do you know of another Procomm like software that does access ports above COM9?

I need to have 12 simultaneous Procomm sessions going at one time running scripts.

Thanks in advance for your help.

Dblprops

 

[knob]

Here is some information that I received from another Procomm user that, while it won't let Procomm access ports above COM9, may give you another option:

If you really need more than 9 COM ports and you can't get the hack to work, I suggest you use a COM port switch (matrix) that you can control via.. of course, a COM port! This way you can live with only 2 COM ports: one connected to the matrix, from where it will be switched to your various devices you want to talk to, and another COM port to control the matrix itself. Check out these guys, they make some serial matrices:

http://www.cytec-ate.com

aspect@aspectscripting.com

http://www.aspectscripting.com

 

[juski]

Hi again.

I was taken off that particular project for something 'more pressing' and never got round to looking at it again.

I imagine it should be relatively easy to write some VB (eeew!) which uses the correct COM port access technique (fileopen & filewrite). So far nobody at my workplace has taken up the task of cracking this particular problem so maybe I'll get landed with it again.