Gordon and Petr,
Here is a function I wrote that does the trick for me. I hope it helps you
(beware of line-wrapping):
connect-mpps: has [err ports tmp][
err: true
foreach port ports: [port1 port2 port3 port4 port5 port6][
if not error? try [
mpps: open/direct/no-wait rejoin [serial:// port
"/19200/8/none/1"]
][err: false break]
]
if err [
view/new tmp: layout [
text "Unable to open any serial connections"
button "OK" [quit]
]
wait 30
unview/only tmp
return false
]
mpps/rts-cts: off
update mpps
true
]
I had the same behavior as Petr with REBOL not returning until I defined the
ports for each machine individually using system/ports/serial. I normally
put this in the user.r file.
I suppose you could access the system via libraries (if you are using View/Pro)
to determine which COM ports are installed on the system.
An idea if you need the hardware handshaking: Perhaps you could scan with
handshaking off and once you find your device, turn handshaking back on.
-Bo
>
> Hello Bohdan;
> I would also be very interested in any serial port information; having
> similar problems as Petr described.
>
> Gordon Raboud
>
>
> On 28-Jun-02, you wrote:
>
> > Petr,
> >
> > I have scanned serial ports in the past, but I don't have the program
> > handy to see how I did it or what refinements I used. It was using
> > View/Pro 2.1, so I'm not sure if the behavior will be the same as in Link.
> >
> > I'll send you information later today when I'm at the location where I
> > have the program.
> >
> > -Bo
> >
> > At 12:43 PM 6/28/02 +0200, you wrote:
> >> Hi,
> >>
> >> I am trying once again to find some answer regarding serial port
> >> functionality in rebol:
> >>
> >> Could anyone help me to reverse the following logic? It is info taken
> >> from docs for Serial port, but it comes from 2.3 Core transition phase,
> >> which was later switched back to blocking-ports-by default:
> >>
> >> Serial ports are always opened as direct ports in much the same way as
> >> console and network ports. They may be opened as either /STRING or
> >> /BINARY with the default being /STRING. They are opened by default as
> >> asynchronous, but may be made synchronous by using the /WAIT refinement.
> >> When operating asynchronously, any attempts to copy data from the port
> >> will return NONE if no data is present. When operating synchronously, the
> >> copy will block until data is available.
> >>
> >> A timeout value can be specified by modifying the timeout field in the
> >> port structure. The timeout value only applies to serial ports that are
> >> opened with the /wait refinement. When the timeout expires, a serial port
> >> timeout error will be generated. To set the timeout value do:
> >>
> >> ser-port/timeout: 10 ; 10 second timeout Qs:
> >> - is serial port being opened by default in /Direct mode? - is it opened
> >> in /STRING mode and if so, does rebol do any special char (newline, tab)
> >> conversions here? - is it blocking by default, so I have to use /no-wait
> >> to get async behavior? - is timeout taken in account in default
> >> (blocking) mode?
> >>
> >> I have following problem: I try to dynamically scan serial ports, and
> >> don't know what setting to use best. So I tried to use following
> >> technique, but am not sure, if Rebol behavior is consistent and the way
> >> it should be:
> >>
> >> ser: open serial://port1/19200/8/none/1
> >> ser/timeout: 5
> >> update ser
> >> insert ser "1"
> >>
> >> Console hangs forever - no timeout applies. I have no defice connected to
> >> COM1, maybe motherboard uses it somehow, but anyway - should it block
> >> that way?
> >>
> >> I use small and hande PortMon utility and here is the output ...
> >>
> >> 0.00005448 rebol-link.exe IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS
> >> Rate: 19200
> >> 0.00000754 rebol-link.exe IOCTL_SERIAL_SET_DTR Serial0 SUCCESS
> >> 0.00000587 rebol-link.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS
> >> StopBits: 1 Parity: NONE WordLength: 8 0.00000503 rebol-link.exe
> >> IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11
> >> XOFF:13 0.00000587 rebol-link.exe IOCTL_SERIAL_SET_HANDFLOW Serial0
> >> SUCCESS Shake:9 Replace:80 XonLimit:2048 XoffLimit:1024 0.00000000
> >> rebol-link.exe IRP_MJ_WRITE Serial0 Length 1: 1 0.00000670 rebol-link.exe
> >> IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR
> >> 0.00000000 rebol-link.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0
> >>
> >>
> >> The same state continues regardless if I add /direct, /direct/no-wait,
> >> timeout or not. It starts to work however, once I turn off hardware
> >> handshake:
> >>
> >> ser/rts-cts: off
> >> update ser
> >>
> >> 0.00001090 rebol-link.exe IOCTL_SERIAL_SET_BAUD_RATE Serial0
> >> SUCCESS Rate: 1200
> >> 0.00000419 rebol-link.exe IOCTL_SERIAL_SET_RTS Serial0
> >> INVALID PARAMETER
> >> 0.00000754 rebol-link.exe IOCTL_SERIAL_SET_DTR Serial0
> >> SUCCESS
> >> 0.00000670 rebol-link.exe IOCTL_SERIAL_SET_LINE_CONTROL
> >> Serial0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
> >> 0.00000503 rebol-link.exe IOCTL_SERIAL_SET_CHAR Serial0
> >> SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
> >> 0.00000922 rebol-link.exe IOCTL_SERIAL_SET_HANDFLOW Serial0
> >> SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:1024
> >> 0.00002430 rebol-link.exe IRP_MJ_WRITE Serial0 SUCCESS
> >> Length 1: 1
> >> 0.00001173 rebol-link.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0
> >> SUCCESS Mask: RXCHAR
> >> 0.00000000 rebol-link.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0
> >>
> >>
> >> As you can see, _SET_RTS was was said to have "invalid parameter". But -
> >> the only one real real difference to me seems to be in "Shake: 1" mode,
> >> while previous state was "Shake: 9". What does it mean?
> >>
> >> Our folks told me to not turn-off hw handshake though, as they use it -
> >> but then I can't do automatic scanning to find our device. The problem
> >> also is - what is the best mode I should use? While communication using
> >> Windows Hyperterminal works nicely, I have various strange difficulties,
> >> e.g. uploading following help into device:
> >>
> >> h: read %help.txt
> >> insert dev "HWE" ;HelpWriteEnglish
> >> insert dev h
> >> insert dev escape ; end of upload
> >> close dev
> >>
> >> ... it uploads nonsense chars into device, while the same file sent thru
> >> hyper-terminal works OK ... I will have our device today for further
> >> test, but am just curious, if anyone used serial port
> >> succesfully/consistently already?
> >>
> >> Anyway - help of any kind would be appreciated :-)
> >>
> >> Thanks
> >> -pekr-
> >>
> >>
> >> --
> >> To unsubscribe from this list, please send an email to
> >> [EMAIL PROTECTED] with "unsubscribe" in the subject, without the
> >> quotes.
> >
> Regards
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
