PC to Picaxe confusion

#1
Hi All,

I have built a system to control some point motors for a model railway using a series of picaxe chips to control a transistor to allow the points to change.
To control these I have written a program in python that communicates over the standard serial communications setup (I disconnect the chip to use the download wiring for communications).

I am having a confusing issue however. When the Chip receives ">RSET" from the PC that means I want all the chips to reset (and turn all outputs off). When i send this command using Termite all works perfectly fine I get the acknowledgement back from the picaxe chips and then their boot up confirmation, so all good.
When i send the same through python I get the initial acknowledgement that the picaxe chips have received the command and are resetting. But once they reset everything goes wrong. The python program ends up freezing. I have found out that this is due to the picaxe chips sending a constant stream of jibberish back to the pc.
I checked this by triggering the reset from my python program, disconnecting and then using Termite to view what was being read in on the serial port.

I have absolutely no idea why on Termite it works but through python it doesn't. here are my codes;

Picaxe code;
Code:
do
   serrxd (b6),b1,b2,b3,b4
loop while b1=0 and b2=0 and b3=0
if b1="R" and b2="S" and b3="E" and b4="T" then
		sertxd(b6,b1,b2,b3,b4,13,10)
		b1=0
		serrxd[500],(b7),b1,b2,b3,b4
		if b1<>0 then
			sertxd(b7,b1,b2,b3,b4,13,10)
		end if
		sertxd(b7,"ACRS",13,10)
		Reset
end if
so basically the picaxe chips are daisy chained together so that the PC sends the command to the first chip, which then repeats the message out to the next one in the line.

and the python side;
Code:
globals.s = serial.Serial(globals.comm_port, 9600, timeout=0.5)
globals.s.open()
globals.s.reset_input_buffer()
globals.s.reset_output_buffer()
globals.s.write(b">BSET")
returned = ">"
while not returned[:1] == "<":
            returned = globals.s.readline()
globals.s.close()
globals.s = ""
print returned
termite settings are;
Baud 9600,
8 data bits
1 stop bit
no parity
no flow control
no forward
append LF (in the transmitted text section)

Im not sure why it works for terminte but not python when they are both sending the exact same command

Any help would be greatly appreciated
 

hippy

Technical Support
Staff member
#2
Welcome to the PICAXE forum.

In your Python code you send ">BSET" rather than ">RSET" but it is difficult to assess what the issue is.

I would guess it might come down to timing, the Python perhaps sending before the PICAXE has fully reset leaving it thinking there has been a download initiation. Or maybe the code just hangs and doesn't recover. It may not be the Python which has provoked the PICAXE output you are seeing; it could be closing the Python and starting Termite.

You mention PICAXE chips in the plural but haven't explained how they are all connected, how multiple chips are talked to from the PC or communicate back to the PC.

To get to the bottom of things is perhaps going to be a long haul and will need full circuit diagrams and full program listings. It would probably be best to start with the simplest system possible before making it more complicated.
 
#3
Hi the bset bit was just changed so I could test other parts of my program without it killing the chips.
There are currently 3 picaxe chips in the network wired up so that the pc talks with chip a, chip a's output is linked to pc input and chip b input, chip b output is linked to chip a input and chip c input and so on so they make a daisy chain.
All communications use a start bit of ">" if it's coming from the pc or going down the chain and "<" if it is running back up the chain to the pc.
Each chip has a single character is stored in its memory so commands can be sent to a single chip.
I can't post the full picaxe code as it's on my work laptop which I forgot to bring home.
When the chips start up they output a simple "this chip is chip x" using neither of the start bits.
The python program hangs after a reset when it tries to send a new command to the chips because it is waiting for a reply, which it never gets due to the chips spewing back a stream of nonsense, which doesn't happen through termite
 
#4
Oh I forgot to say i have put diodes in on the communication chain to help prevent incorrect flow (block signals going back to the output pins)
 

hippy

Technical Support
Staff member
#5
The diodes could be part of the problem if you have one from the last in the chain back to the PC and no pull-down resistor. The reset may cause that output pin to momentarily tri-state, cause the PC to see a corrupt character, ignore the message because it doesn't start with "<" but the corrupt character, then wait forever for the next "<" message which will never arrive. Termite might not show that glitch but the Python code might see it.

The 'stream of nonsense coming back' suggests the last PICAXE is either seeing what it thinks are download initiations and responding to those or it may be something getting out of sync. That might also be diode related depending what your circuitry actually is.

It might be better to start with SERIN and SEROUT commands on pins other than the download serial pins. Or not actually invoke a RESET command, but just restart the program.

What you are trying to do should be possible to get working but it could prove a nightmare to figure out why it isn't actually working.

Key to everything will be a robust protocol, Python code which can handle glitches and the like. I am never confident of using ser.readline() when there aren't any line terminators being sent back and using a timeout to try and determine when data has been received.

But it's not clear if you are sending line terminators. It looks like you may be but other PICAXE's down the line don't look to be expecting those, so maybe that's what's pushing the last one into outputting nonsense ?
 
#6
In basics I'm using the picaxe reset command to simply force all the output of the chip to be off sending it back to the default start up state. The only other way I could think to do the same was to literally use set a.1 low, set a.2 low... And so on but that wo ukd eat up a lot of the memory on the chip and I'm not sure if I have enough left to do that.
Is there an easier way to set all outputs off.

The way the setup works is that every output pin (bar the one used in the download circuit) can be used to control a point motor giving the maximum number of connections per board.
If there is a simple command like all outputs low then that would clear my problem I think, as I don't actually need to restart the picaxe chips just was the only way I could think to do it easily?
 

hippy

Technical Support
Staff member
#7
To reset all output pins to LOW, adjusted to whatever PICAXE chip you are using. ...

Code:
pinsA = 0
pinsB = 0
pinsC = 0
pinsD = 0
Thinking about the topology you have it may be a timing or lockup issue with each chip connected back to the earlier. It's not exactly clear what happens and the timing when the RSET command is received by the first. It looks like there could be a cascade of messages which could be jamming things up, comms from two or more PICAXE colliding and causing what's actually output to become nonsense.
 
#8
Thanks.
I will try using that instead of actually restarting the chips. Which should resolve the problems I am having. Everything else on the topology seems to work fine (sending commands down to turn pins on/off) just not the chip resets.
Thanks again
 
Top