Automation, Robotics?

===== please reply to: [david--vydra--net]

-- Bohdan "Bo" Lechnowsky REBOL Adventure Guide REBOL Technologies 707-467-8000 (http://www.rebol.com) The Official Source for REBOL Books (http://www.REBOLpress.com)

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Einstein

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Einstein

-- Bohdan "Bo" Lechnowsky REBOL Adventure Guide REBOL Technologies 707-467-8000 (http://www.rebol.com) The Official Source for REBOL Books (http://www.REBOLpress.com)

-- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org]

currently runs on a 486 class SBC onder QNX but only because I don't have a lower power board lying around. It drives a serial LCD and serial i/o pretty easily. The REBOL e-mail stuff is pretty handy as is the serial port (exp) control. The biggest problem I've had developing is is the silly license expiration gaps on the experimental releases. Dave Previously, you ([Sharriff--Aina--med-iq--de]) wrote:

-- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org] -- To unsubscribe from this list, please send an email to [rebol-request--rebol--com] with "unsubscribe" in the subject, without the quotes.<

seemed limiting in QNX where a serial port on another node has a node number or name in front of /dev. ie: //4/dev/ser5 refers to serial port 5 on node 4 and can be opened accross the net just like /dev/ser1 on whatever the local node is. Fortunately, QNX allow one to symbolic link (prefix) a remote node into the local namespace. One could thus prefix //4/dev/ser5 -> /dev/ser4.5 and open ser4.5 using REBOL - so REBOL does not to be QNX net aware to benefit.

You miss my point here I think. What I mean is that since QNX allows building symbolic links accross network nodes, REBOL does not need to know about the QNX network features - it just works.

I hope that you'vde reported this to QSSL. I do find it hard to believe though. The GNU stuff I've played with tends to handle the serial ports correctly if it compiles. The QNX 4 posix functions seem to work well in code I've written with the exception that flow control has a funny "lock" bit which is not obvious.

How is changing a port number any easier that changing a name? Don't you still need to either edit hard coded port numbers of build some cover function which creates a port spec given a number parameter?

Great I had assumed that there must be a method, just hadn't a clue on where to find it. This is probably my biggest gripe re REBOL - it does a lot of cool things, but figuring out how is a mystery. Yes, I've read the official guide, but port coverage is pretty skimpy. Of course serial ports are new so I know that I'm out on a limb there. Dave -- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org]

REBOL makes serial port control pretty easy. You open a serial port and get a port which you can read, write and wait on. There are some funny design decisions, but I think that they make sense. Here's some code snippits: path: serial-path-to/options lcd 19200 path == serial://port2/19200/none/8/1 fp: open/mode path [ direct write read binary no-wait ] serial-path-to is: serial-path-to: func [ 'name ; port name ser1, com1, ... /options opts ; baud setting options in REBOL open fmt /loc number ] [ either number: find system/ports/serial name [ number: index? number ][ append system/ports/serial name number: length? system/ports/serial ] ; Append opts or default (redundant) either options [opts: join "/" opts] [ opts: "/9600/none/8/1" ] ; this was the hard statement for me to figure out join serial://port rejoin [ number opts ] ] REBOL (still exp versions) puts the port names in: system/ports/serial The defaults are [ ser0 ser1 ] which will be useless in most cases. In QNX, ports are in /dev and are typically names ser1, ser2 ... In the MS world they are com1 and so on. So the first thing that one needs to do is replace system/ports/serial with valid OS names without the /dev prefix. In my box, I make symbolic links to ser1 and ser2 to lcd and cbr - hence the lcd in the first code line above. Although striping the /dev prefix is somewhat handy it at first seemed limiting in QNX where a serial port on another node has a node number or name in front of /dev. ie: //4/dev/ser5 refers to serial port 5 on node 4 and can be opened accross the net just like /dev/ser1 on whatever the local node is. Fortunately, QNX allow one to symbolic link (prefix) a remote node into the local namespace. One could thus prefix //4/dev/ser5 -> /dev/ser4.5 and open ser4.5 using REBOL - so REBOL does not to be QNX net aware to benefit. The crazy thing that REBOL does is make you open the port with a path name serial://port[N] where N is the index? of the port name in system/ports/serial. Thus in serial-path-to above, I find the index? or append the passed name and use the length? to get port[N]. Of course, REBOL then has to change this back into an open( "/dev/serX", ..) so to me it would make sense to use the port name instead of index. To set baud, parity, stop bits one just appends resonable values to the port path so an open could look like: fp: serial://port3/2400/odd/7/2 and REBOL would figure out that you want 2400 baud, 7 data bits, even parity and 2 stop bits. I don't think that REBOL provides a mechanisim to change the option after an open. This does bring up a buglett in QNX4 and QNX RTP - the open parameters are not correctly set. To solve this, I call the stty command after the open so that the baud and so on are correct. At least the port has internal attributes of speed, parity, data-bits and stop-bits which make the stty command trivial to build. I currently execute stty in core by writing the command "stty baud=xxx ..." to a fifo (named pipe) which has a shell script on the other end. This scriptsimply executes whatever command is fed to it. OK, you have a port, now what? Well it behaves pretty much like a socket so you can read, write and wait on it. I have an event loop that looks like this: loop: func [ /loc ok pd ] [ ok: 1 while [ ok ][ pd: eval-rules ; do something on every pass wait [ pd lcd/fp ] ; wait for a timeout or lcd key press ok: not-equal? 'A pick lcd/fp 1 ; get pressed key. ] ] OK, I don't have the keypad doing anything cool yet. If your device returns lines of data, then you'd probably open the port with something like: cbr/fp: open/mode/with serial://port4/9600/none [ direct write read no-wait lines ] "^M" The cbr port device returns strings of data terminated with ^M in response to a command. I have a function which sends a command, waits for a response and returns whatever the device sent back minus some prefix. The read removes the ^M. It's all pretty slick and with any luck would work on a MS OS if I used com[N} type names. read-check: func [ cmd prefix /loc data] [ insert fp cmd ; write command to the serial port wait timeout ; wait for a response data: first fp ; get line of data return find/match data prefix ; return stuff after prefix ]

-- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org]

The defaults depend on the operating systems, and are usually useful. For operating systems which provide an API to query which serial ports exist, that API is used to set the defaults. Otherwise a reasonable OS-specific default is used. Depending on the particular OS version and build (and for Linux, the package) the ports still may not match your setup though.

At the moment REBOL does not directly support any QNX-specific features. It accesses QNX through standard Posix functions, which is why any QNX-specific extensions to the serial mechanism (or other features) probably won't work. This is also why some users have problems setting the baud rate from REBOL in QNX. Apparently some versions of QNX have some bugs in their Posix emulation code. This is not a bug in REBOL. The same code works fine for "regular" Unix flavors.

One of the main goals of /Core is interoperability across platforms. Introducing a standardized naming scheme for serial ports means that scripts do not have to be changed when moving them across platforms. With the current scheme the only part of a script that has to change is the port number, as opposed to changing full port specs.

It does. Just change the parameters in the port structure and call 'update on the port. -- Holger Kruse [holger--rebol--com]