FullDuplexSerial4port Object difficulty SOLVED.-- Bug in dataIO4Port --

R Baggett

I have used this object successfully, a lot..

But this time I can't seem to rx a string.. I have checked the serial stream with a PC and the stream contains the expected message, followed by CR.

I see the serial stream at the RX pin for this port. (On a 'scope)

I just never get past the "com.StrIn(omr, @OmrInSerBuf)" on line 207 of the attached file.
com.StrIn(omr, @OmrInSerBuf) 'Wait for message from Omron com.str(dbg, string("String RX"))

As in, I never see the message on the dbg port. (Which is working everywhere else in the project.)

Can anyone see what stupid thing I am doing? I can't see it...

DigitalBob

I'd like to try out your program, but I don't have fullduplexserial4port or dataIO4port, just wondering what type of Omron thingy are you talking to.

R Baggett

DigitalBob,

They are in the OBEX, but I will save you LOTS of time and just archive it and attach to this message.

The Omron is an Omron CJ1M CPU23 PLC that controls the test fixture that this is part of.
I have verified that the PLC is sending the correct message followed by CR, which should be picked up by the StrIn function.

Tracy Allen includes dataIO4port with FullDuplexSerial4port, and it's purpose is to provide PST-like functionality for strings and numbers and such. I am using it in this instance.

Messages that may be sent by the PLC are :

This message id the one beginning at D190. All locations in this memory area are words. Strings are two characters per word, zero terminated and the dots are all zeros, except the one directly following the last character, which is $0D (Return)

I am also including a schematic of the propeller portion of the project.

R Baggett

In the photo of the PLC memory above, The "W" at the end of ':POW' doesn't show up because the columns of the words too narrow to show it. (Didn't that cost me some time the first time I used this software!)

R Baggett

I found it!
The dataIO4port had the call (Line 167) to the 4 port serial object hard coded to port 0 instead of 'port'. It was then hard coded to use only port 0 (Debug, in my case here)

How can we get this fixed in the OBEX?

Tracy Allen

Ahh, sorry about that. I see that I had corrected that at some point in at least in my own files. The OBEX is no more, out of reach somewhere.

`PUB StrInMax(port, stringptr, maxcount) | char, ticks
{{from PST, modified
Receive a string of characters (either carriage return terminated or maxcount in length) and stores it (zero terminated)
starting at stringptr. Waits until either full string received or maxcount characters received.
Parameters:
stringptr - pointer to memory in which to store received string characters.
Memory reserved must be large enough for all string characters plus a zero terminator (maxcount + 1).
maxcount - maximum length of string to receive, or -1 for unlimited.}}

maxcount <#= MAXSTR_LENGTH
repeat maxcount 'While maxcount not reached
if (byte[stringptr++] := uarts.rx(port)) == NL 'Get chars until NL
quit
byte[stringptr+(byte[stringptr-1] == NL)]~ 'Zero terminate string; overwrite NL or append 0 char
`

R Baggett

Tracy Allen,

The copy I used came from a fairly recent download of the entire GIT Obex named watchamathingie. I know there is a way to get stuff into there. I just don't have time to figure it out right now... Maybe when this project is done...

I can't complain. It's exactly the kind of thing I would have done...

Thanks for a great object. It's well worth a little fix.

DigitalBob, anyone else that may benefit from this.. Beware, the copy in the archive is not corrected

DigitalBob

Ok, glad you found the issue