I’m using V2014r-2. I can’t get Serial1.RequestToSend or Serial1.DataTerminalReady properties to toggle these outputs at the DB9 connector. The COMport works fine with a terminal program.
I am afraid there is not enough information from you to do any sort of guessing as to an issue.
The serial class is so simple that its likely to be a code issue in the application or an issue with the hardware you are connecting.
I say this as I have used Xojo for a significant number of years, and the majority of projects are serial based.
I have never yet seen an issue with the serial class, I have had non working code, but that was down to errors on my part or hardware not doing what was expected.
Please send some code that shows the issue and what your hardware system is for the serial converter, I am sure something can easily be figured out.
Win 7 Pro.
PCI Express dual serial card.
The Serial.writes work.
This is in the Timer Action
running at 1000ms
if Secs > 0 then Secs = Secs - 1 TextFieldS.Text = Str(Secs) else Minutes = Minutes - 1 TextFieldM.Text = Str(Minutes) Secs = 59 TextFieldS.Text = Str(Secs) end if
if Secs > 0 then
Secs = Secs - 1
TextFieldS.Text = Str(Secs)
Minutes = Reload
TextFieldM.Text = Str(Minutes)
if TextFieldOUT.Text = “ANTENNA A” then
TextFieldOUT.Text = “ANTENNA B”
Serial1.RequestToSend = TRUE
TextFieldOUT.Text = “ANTENNA A”
Serial1.RequestToSend = FALSE
Forgot to add that if I enable the DTR in the inspector window before running, it is asserted when I connect to the COM port.
I believe you need to call Reset after you change those settings, but I can’t find the reference that I now only dimly remember. But I know there is something you have to call before DTR/RTS changes take effect.
I am assuming you are able to test the physical voltages on the hardware ports connector (I have also used a real win7 laptop with PCI card to do this).
From my experience I never used the RESET nor the POLL methods.
I do not believe the RESET command is required to do what you wish, as Tim suggested, it is used as far as I know, if you wish to refresh a current ports settings, baud or bits etc (happy to be corrected on that!)
Your code targets RTS, and the language reference, for some reason, has this property able to set or get, distinct to CTS and DTR, which have separate methods.
I would be inclined to experiment with the DTR and CTS properties and see how the interaction with your hardware works out.
The PCI card is not guaranteed to be compliant with the underlying driver, perhaps testing with a generic FTDI converter as a reference could prove useful.
I am not sure the use of POLL in your example is useful.
The system used in my projects, using your example, would be (notes are related to my own code):-
Serial1.Write("B")//the data we wish to send Serial1.Flush//immediately send the data without the buffer holding on for more data Serial1.XmitWait//wait for all characters to go before exiting this routine
following this code I might be inclined to set the DSR/DTR/CTS.
In my experience there are some layers of code between expectation and actual hardware function, things get missed out, that appears more so on windows unfortunately(I have found), PCI hardware may not be as useful as the USB converter cables that I have found are working without issue on Mac, Linux, Raspberry Pi and win, using exactly the same Xojo serial code.
73 de EA8/G0EBB, Espaa 35510
Have you tried the “SerialLineIndicator” Xojo example. It is a very simple, yet effective, way of checking the serial port functions.
Adding Serial1.Reset fixed the problem. Thanks
I found the post where one of the original engineers mentioned serial.reset: http://forums.realsoftware.com/viewtopic.php?f=1&t=2827
[quote=Aaron Ballman]REALbasic queues up changes to the serial device so that you can modify multiple properties of it without them all taking effect immediately. For instance, you can set the baud, parity and stop bits as one operation instead of three. The same thing applies to the line state properties.
Once you’ve made all your changes, you need to call .Reset on the serial device to reset the device to the new settings. So put a call to Serial1.Reset after each assignment to RequestToSend, and you should be fine.[/quote]
On a side note, I would argue that this isn’t a typical usage scenario for the serial port, so I’m not surprised that Mark hasn’t bumped into this one. I’m not convinced that David is approaching this in the best way. Is it really necessary to toggle the control lines yourself?
You’re correct. This is for a customer that needs to use the RTS line to switch between two different “objects”. This is actually my first Xojo project so I’m unfamiliar with the syntax. I’m usually programming for PIC32 projects in C.
Not to hijack this thread - but being a programmer for both Atmel AVR (soon to be Microchip) as well as Xojo and VB, it is required to assert or de-assert RTS, unless of course the hardware will do that for you. In the uC world this is done in code, again unless some other hardware has been designed in. If you do not change the state of RTS, RS485 transceiver cannot send/receive.
In RS485, Modem and other worlds, RTS is not transmitted over the line. The state of RTS at the Chip is what is important. At some point, the two ends can be “fighting” with both trying to send. This is where a scope and code come in handy.
As for Xojo/RS I had trouble with the RTS state. It would change as commanded, then change back - according to my digital scope. I added hardware to manage this for me so RTS is no longer an issue, but I sure wish the problem did not exist. Filed a big report years ago, along with another fellow from Australia I think.
Maybe the strange behavior I saw has been fixed…
I just looked at the link that Tim sent. Maybe the use/placement of .Reset is the key for me too…
interesting subject regarding the lines and reset, I will keep this in mind if ever such a requirement is needed for me, thanks all.
This is quite common in Ham Radio circles. I wrote a program for my brother a few months ago to do exactly this as the one that he was using before didn’t work on Windows 10.
It listens for RTS’s on multiple com ports and sends out a special string on another com port to the radio to activate its microphone. Multiple apps/devices can then use the ham radio without “cross talking”.
I wrote it in a different language so I can’t shed any light on the thread, sorry.
de EA8/G0EBB hi