I am modifiying the terminal.bas program to do some simple tasks and it works well, until i built up the program to now have a second com port open . Lets call that second port #Cpp
#cpp is simply to receive data from a device that occasionally spits out data.
the device works perfect with hyperterminal when i use hardware controls, the problem is that I can't find that liberty basic supports hardware flow control. on the device is a light that indicates it is waiting for hardware, so that gives me high confidence that is my problem.
more details: device x usually prints to a parallel printer. we replaced the parallel printer with a cs-zn2 from photologic.ca so that we can have a serial data stream to read. Without hardware control ideas, I am stuck. The cs-zn2 supports xon/xoff but liberty basic doesn't so i am stuck again trying to bypass that idea.
There is code at the end of the tutorial that allows the DTR and other handshaking pins to be read and activated. But be sure it isnt as simple as using the full open statement with the handshaking parameters set.
Post by malteseone on May 20, 2021 16:50:07 GMT -5
it turns out that I believe the device X is waiting for DTR to go to -5 volts. I had a chance to use my ancient 25 pin signal indicator for serial. I saw that during hardware handshake with hyperterminal, DTR was -5V, but with liberty basic it was positive voltage.
i tried snipping the following code in, to no effect . It could be because i am using 2 serial ports for this project but only want it for com2. I am limited on this because i know only basic BASIC (also i tried resetting DTR and setting it as well. I have also tried to do the code snippet before and after the other com port setup )
could my problem be because i am using 2 serial ports, port2 and 10? If so, how can i fix that with this code?
lpFileName$ = "Com2" dwCreationDistribution = _OPEN_EXISTING hTemplateFile = _NULL calldll #kernel32, "CreateFileA", _ lpFileName$ as ptr, _ dwDesiredAccess as ulong, _ dwShareMode as ulong, _ lpSecurityAttributes as ulong, _ dwCreationDistribution as ulong, _ dwFlagsAndAttributes as ulong, _ hTemplateFile as ulong, _ hFileHandle as ulong
calldll #kernel32, "CloseHandle", _ hFileHandle as ulong, _ result as long
'hFileHandle now contains 'the #handle, a number, that identifies the port
'Create a struct to receive the incoming handshaking data 'this data contains CTS DSR RI and RLSD info. 'For more detail go to 'http://msdn.microsoft.com/en-us/library/aa363258(VS.85).aspx struct modem,DSRCTS as long
'Now open the com port in Liberty and use the hFileHandle value in API calls open lpFileName$;":9600,n,8,1,ds0,cs0,rs" for random as #com
'now set reset and read the handshake lines like this print "setting DTR" CALLDLL #kernel32, "EscapeCommFunction", hFileHandle as ulong, _SETDTR as long,_ result as long
The code has worked in the past and should not care if more than one port exists. Print the port handle hfilehandle, when you open the port check, that’s what you use when you set DTR. If you monitor the pins you should see the change. I have not had a problem toggling DTR on or off but it’s been a while.
A dongle made from a male and female 9pin plug and socket would be a really effective solution.
When you say “snipped in” the api code really needs run in advance then just use the handle and short DTR setting code in Liberty. Printing the handle should get you a decimal number, dechex it to see that it is in the com port range.
Post by malteseone on May 28, 2021 11:21:19 GMT -5
well, the delays didn't work for me in several different methods, so I made a small battery powered device that disconnects computer's DTR and inserts my own voltage. Just means I need to check a battery (until i spend time to get an ac adapter set up).