Two way communication using the COM port

[Russ Puskarcik]

I am using RS232 to communicate with programmable power
supplies, and to a modified data bus that uses the same protocol. The
file I am using has the .btm extension and opens in TCC.

echo 1l. > COM6:
copy com6: con:

This works except the COPY command expects CTRL-Z (ASCII 26) at the
end of the string. The device I am connected to can not be configured
to provide the CTRL-Z.

Ultimately I want to parse the return string... so I'll need to
capture it into a variable. Is this all just a pipe dream with TCC?

 

[mathewsdw]

Rus, I notice that this thread has been sitting here for 9 days without an answer, and that is because I believe that nobody has an answer and that that is inherent in what you are trying to do in the way that you want to do it. You see, since I imagine that the com ports have a "sequence" consisting of "some data, silence, some data, silence..." there is no way for the copy command to know that there is no more data in a given period of time without a Ctrl-Z or some such other character "coming down the line", which the copy command, of course, does not and can not "natively" do. (Why would any copy command do that?) But if what I say above is true in your situation (and I really tend to think that it is), you can't really get around it by having the "read" "time out" at the end end of a given time period and generating an "interrupt" of some kind that terminates the read, because, as far as I can tell, such a thing is inherently "parallel processing" of a sort, and, as far as I know, TCC doesn't do that. And sadly I'm not aware of any other languages that would allow you to do what you want to do easily (again because of the parallel processing nature of it), although it could almost certainly be accomplished in languages such as C and C++ with a lot of work.

Now I might have some suggestions on how to accomplish this in TCC in a batch file, but I need more information. Specifically, is the data that "comes out of" "COM6" "triggered" by writing "1l." to COM6:? And, if so, what "triggers" running the batch file in question? If there is an explicit "trigger" for this batch file then what you might want to do is to have two batch files involved: One batch file just containing the "echo 1l. > COM6:" command and is "triggered", and another that is always executing that does the "copy" command (or an equivalent, more on that in a moment) whose "idleness" while waiting for something to copy doesn't hurt anything (other than taking up a small amount of memory). However, the "copy" command might not be the "best" solution anyway because it probably works (as most programs of a similar nature do) by using a loop that "reads the data into a buffer until the buffer is full" followed by "write the contents of the buffer and then clear the buffer". Since I would tend to guess that you are really only trying to copy a relatively small amount of data in a relatively short time period, am always excuting TCC batch file that reads and then writes a byte at a time (in a loop; "Do Forever", most likely) might be a better solution.

- Dan

 

[Russ Puskarcik]

One batch file just containing the "echo 1l. > COM6:" command and is "triggered", and another that is always executing that does the "copy" command.

How does one access the results of an "always executing" batch file?
As it is, once the copy command is executed, it always runs, because it is looking for a CTRL-Z, which it never gets. What it does get, is a CR character at the end of a short string. I tried using the /B option in every combination, but none of them worked.

If you use /B with a source filename, the entire file is copied; Ctrl-Z characters, if any, in the file are considered ordinary data to be copied. Using /B with a destination filename prevents addition of a Ctrl-Z to the end of the destination file. /B is the default unlesssource files are appended to the target file, or the target is a device, e.g., NUL.

Perhaps there is a third party command that reads the com port... anybody know of one?

Purl is able to read the com port without problems. I wonder if I can pass parameters back from a purl script... seems arcane and overly complex to me.

Is there some other redirect beside "copy" that anyone can suggest?

 

[mathewsdw]

Russ,

I have good news and I have what is probably bad news that completely overrides the good news if it applies in your situation (which it probably does). The good news is that I have some code that completely handles your situation if (the bad news) the Windows ReadFile API function works differently for a COM: port than it does for CON: (the console) or your device sends a cr/lf (or maybe just a carriage return or just a line feed, the second case being more likely to work) sequence at the end of any particular "group" of data. And I have some code here the that you might be able to use to determine whether or not that is the case or whether the Windows ReadFile API function works differently for a COM: port (which I have no way to test) than it does for CON:. And here is some code you can run to check this out for yourself:

@Echo Off
SetLocal
:: Change "CON:" to whatever COM" port you are testing
Set Handle=%@FileOpen[CON:,r,b]
Set Char=%@FileRead[%Handle,1]
Set DemoCounter=0
Do While "%Char" != "**EOF**"
  Set /A DemoCounter+=1
  @EchoS %DemoCounter: %Char^n
  Set Char=%@FileRead[%Handle,1]
EndDo
EndLocal
Quit 0

And here is what happened when I ran the above code (with input coming from the console):

[Z:\Demo]Demo
abcdef
1: a
2: b
3: c
4: d
5: e
6: f
7:
8:
^Z
[Z:\Demo]

To summarize what you are seeing above (because the "Enter" key at the end of the data I entered ("abcdef") is invisible), the TCC "@FileRead" function does not "see" any data until the "Enter" key is depressed and then the data is returned as a "group" and not a byte at a time (and the same is true if you use the TCC "@FileReadB" function rather than the "@FileRead" function). And this is not at all a TCC issue, it is a an issue related to Windows itself.

So the bottom line is this: If your device is sends a cr/lf feed (or, again, maybe just a carriage return of just a line feed) sequence at the end of any given "run" of data (possible) or the Windows "FileRead" API function works differently for a COM: port than it does for CON: (seems rather unlikely to me) there is no solution to your problem (not just in TCC but in any "normal" Windows program that reads a COM: port) other than finding a device driver of some kind somewhere that reads the bytes one at a time off of the COM: port and does not buffer them but rather returns them on a byte-by-byte basis to the program that is using the device driver.

And here is the way you can test that: run the above code changing "CON:" to "COMn:" and if you get any output when your device sends any data I have a complete solution both coded and tested that works fine other than the behavior I am discussing above, and if you don't get any output there is no solution in Windows (XP or 7 and possibly earlier) other than getting and using a device driver to read the COM: port(s).

And I will add that if you can find a device driver with the above characteristic that can be used within TCC (I'm not going to bother going to "how" it can be used within TCC if at all, that depends somewhat on the "nature" of the device driver) the previously mentioned "complete solution" does apply.

- Dan

 

[Russ Puskarcik]

OK, so I tried this code:

@Echo Off
echo 1l. > COM6:
SetLocal
Set Handle=%@FileOpen[COM6:,r,b]
Set Char=%@FileRead[%Handle,1]
Set Count=0
Do While "%Char" != "**EOF**"
  Set /A Count+=1
  @EchoS %Count: %Char^n
  Set Char=%@FileRead[%Handle,1]
EndDo
EndLocal
Pause

...and out of 50 characters received, it only displayed every 16th character. I also tried other characters besides **EOF** but it doesn't get to the end.

If the code is inputting as a file, can this whole thing be saved as a string? I'm a little new at the FileRead function. Could it be that the DO loop is producing the delay? Is there another way to do this?

Any suggestions?

 

[mathewsdw]

Russ, I can't try it myself for a COM: port (since I have absolutely nothing available to plug into a COM: port even assuming this laptop has one which I doubt but I'm too blind and lazy to look), but as I demonstrated previously in this thread I did try it substituting CON: (the console) for the COM: port, and it don't work there, either. So I asked about it in the "Support" forum, and Rex responded by saying, and I quote, "If you want to read / write individuals bytes from / to COMn:, you're going to need an external app (or a custom file system driver). ". (I don't know how to put a link to that response here or I would.) Bottom line is that you can't do it in TCC and you can't even do it at all "natively" in Windows either at this point in time.

- Dan