@ptrinc only with debug???

[kermet]

Hi there, i'm making a RS232 interface between a Siemens controller and Diesel generator to allow control and monitoring of the generator.

I had some weird things happening when using "@ptrinc" in my serin command, what was happening was the ascii code being passed onto the siemens controller was missing characters now and then, but i found if i had a debug in the program all problems went away no missing characters at all and it was reliable. I'd really like to get ride of the debug as it's not needed or used.

GENCOM: ' generator comm's loop
serout 7,t4800,("#","p","c","v") ' set siemens controller rady to recieve commands
ptr=0 ' set pointer to zero
serout 6,t4800,(13) ' get gen ready for comm's
serout 6,t4800,("load",13) ' ask gen for load value
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr ' recieve data
gosub SITE ' start command to siemens controller point
serout 7,t4800,("load",13) ' finalise point name
pause 80 ' wait for siemens controller to finish response
debug ' this is the line required to fix missing characters???
gosub VALUE ' set value to siemens controller point
goto GENCOM ' start again and repeat the above steps


SITE: ' siemens controller point site name
serout 7,t4800,("site name") ' site name
return ' return to gen comm's loop

VALUE: ' set value to siemens controller point
ptr=1 ' set pointer to 1 as 0 is disregarded
for b6=1-5 ' loop five time if allowed by exit command
let b7=@ptrinc ' set @ptrinc value into b7 variable for reading
if b7=32 then exit ' read variable b7 and exit if value is "space" (32)
serout 7,t4800,(b7) ' send character to siemens controller
next b6 ' loop back for next character
serout 7,t4800,(13) ' send enter command to siemens controller
return return to gencom loop




here are the updates on the siemens controller when the debug is not used (heaps more)

3/2/2008 00:04:20 -29.299999 -N- OPER
3/2/2008 00:04:21 9.299999 -N- OPER
3/2/2008 00:04:21 -29.299999 -N- OPER
3/2/2008 00:04:28 3.0 -N- OPER
3/2/2008 00:04:29 -29.299999 -N- OPER
3/2/2008 00:04:29 9.299999 -N- OPER
3/2/2008 00:04:30 -29.299999 -N- OPER
3/2/2008 00:04:37 9.299999 -N- OPER
3/2/2008 00:04:37 -29.299999 -N- OPER
3/2/2008 00:04:43 9.299999 -N- OPER
3/2/2008 00:04:46 -29.299999 -N- OPER

if debug used the value sits stable on one value unless gen detects change.

 

[hippy]

serout 7,t4800,("load",13) ' finalise point name
pause 80 ' wait for siemens controller to finish response
debug ' this is the line required to fix missing characters???

My guess is that LOAD takes some time to do its job and you're not giving it long enough to do that and come back ready for the next data. DEBUG adds quite a lot of time and so it works with it added. That PAUSE 80 may be too short.

Also "for b6=1-5" is a syntax error, so it may be a bug as this isn't your working code.

 

[BCJKiwi]

This line
for b6=1-5 ' loop five time if allowed by exit command
looks strange for two reasons;

1. Syntax: (page 43, manual2)
FOR variable = start TO end {STEP {-}increment}
(other program lines)
NEXT {variable}
- Variable will be used as the loop counter
- Start is the initial value of variable
- End is the finish value of variable
- Increment is an optional value which overrides the default counter value of
+1. If Increment is preceded by a ‘-’, it will be assumed that Start is greater
than End, and therefore increment will be subtracted (rather than added) on
each loop.

2. math
for b6 = 1 to -5
will result in negative overflows.

Since it appears you want 5 loops, then;
for b6 = 1 to 5
should do it.

 

[kermet]

Ooops sorry guy's it is
for b7=1 to 5
not what i posted earlier.
Hippy as ussual you were right the siemens controller was still replying ascii menu code.

Now that i've sorted out most of the code i'm finding the some points aren't recieving their commands, i have a sneaking suspition that the gosubs aren't returning to the right place as the commands to the siemens controller points come through randomly not as the code is writen. Has anyone else seen this? After reading about gosub's i'm wondering what they mean by the stack? does this mean that the same gosub can only be requested in one loop 8 times on the 28X1 chip?

here's the completed code.

setfreq m8
let b1 = 64 - 6
poke $90, b1
pause 10000


main:
serout 7,t4800,("#")
serin [500,login],7,t4800,("Point")
serout 7,t4800,("p","c","v")
goto GENCOM

LOGIN:
serout 7,t4800,("#")
pause 50
serout 7,t4800,("h")
pause 50
serout 7,t4800,("n","s","l",13)
pause 50
serout 7,t4800,("n","s","l",13)
serin [500,login],7,t4800,("Point")
pause 50
' serout 7,t4800,("p","c","v")
goto GENCOM


GENCOM:
ptr=0
serout 6,t4800,(13,"LOAD",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("load")
gosub value
ptr=0

Serout 6,t4800,(13,"IMAT",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("imat")
gosub value
ptr=0

serout 6,t4800,(13,"IMAP",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("imap")
gosub value
ptr=0

serout 6,t4800,(13,"RPM",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("rpm")
gosub value
ptr=0

serout 6,t4800,(13,"COOLT",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("coolt")
gosub value
ptr=0

serout 6,t4800,(13,"T.POS",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("tpos")
gosub value
ptr=0

serout 6,t4800,(13,"D.POS",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("dpos")
gosub value
ptr=0

Serout 6,t4800,(13,"G.POS",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("gpos")
gosub value
ptr=0

serout 6,t4800,(13,"OXYGEN",13)
serin [500,GENTO],6,t4800,@PTRINC,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
Serout 7,t4800,("oxygen")
gosub value
ptr=0

SErout 6,t4800,(13,"K.AVE",13)
serin [500,GENTO],6,t4800,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
gosub site
serout 7,t4800,("kave")
gosub value
goto GENCOM


SITE:
SEROUT 7,T4800,("#","P","C","V")
pause 1000
serout 7,t4800,("POYNTZS,GEN.INT.")
return

VALUE:
SEROUT 7,T4800,(13)
SERIN [1000,MECTO],7,T4800,("New:")
PAUSE 1000
ptr=1
for b6=1 to 5
let b7=@ptrinc
if b7=32 Then EXIT
serout 7,t4800,(b7)
next b6

serout 7,t4800,(13)
PAUSE 2000
return


GENTO:
serout 7,t4800,("#","p","c","v")
let w13=w13+1
pause 500
serout 7,t4800,("POYNTZS,GEN.INT.GENTO",13)
pause 500
serout 7,t4800,(#w13,13)
pause 1000
goto GENCOM

MECTO:
serout 7,t4800,("#","p","c","v")
let w12=w12+1
pause 500
serout 7,t4800,("POYNTZS,GEN.INT.MECTO",13)
pause 500
serout 7,t4800,(#w12,13)
pause 1000
goto GENCOM

 

[hippy]

The 'GOSUB depth' limitation applies to having a GOSUB within a GOSUB routine. For example, in your SITE: routine you could call another routine which in turn calls a routine of its own and so on. There doesn't seem to be anything like that in your code, not to a depth which would cause problems.

- setfreq m8
- let b1 = 64 - 6
- poke $90, b1

That's a tweak to operating frequency to make serial baud rates correct, right ?

The internal oscillator has +/-2% tolerance so such tweaking shouldn't be necessary, but there have been baud related issues reported elsewhere. The problem here is that if there's a fundamental baud rate problem you're on a hiding to nowhere looking at your own code. The POKE $90 adjustment may not be perfect, works in most cases but not all. Could be worth adjusting that.

A brute force approach to fixing things could be to put a PAUSE before every SEROUT and after every completed SERIN in case there are any other places where the PLC is still doing something and misses what is sent. Those pauses can be removed or reduced later.

The timeouts on SERIN may also be having an adverse effect and make it hard to guess where the code may be going. While a good defensive measure, it may be better to have the code ( for now ) hang rather than try and recover which may point to where things go wrong. Adding SERTXD before SEROUT and after SERIN may allow you to trace progress and determine where it's going and, more importantly, stopping.

Another possibility is to monitor what is being sent and received. The TX to the PLC and the RX back could be mixed then you can see exactly what is being sent and received on a single PC serial port. For an Nxxxx baud rate this would be simple diode mixing. Here, they need inverting then mixing, a NAND gate would be one solution. Alternatively a program which can read two serial ports and merge the data on display showing sent and received. Running two terminal emulators and some Windows port monitoring software may save having to write any code yourself. The signals will still need inverting for the PC.

As an alternative to what you currently have, you could consider moving from SEROUT/SERIN to HSEROUT/HSERIN.

 

[MPep]

I had a similar problem when I first started using a satellite modem on a PICAXE. It turned out that instead of waiting for 'pause period' to finish, it was better (technically) to wait for a response from the modem. "OK" was sent, which I waited for in my program, and then continued.

I wonder if the GenComms Controller acknowledges the last sent command?