User manual

SNAPpy Scripng Hints
The following are some helpful hints (somemes learned from painful lessons) for developing custom SNAPpy
scripts for your nodes. These are not in any parcular order.
Beware of Case SensitiViTy
Like “desktop” Python, SNAPpy scripts are case sensive – “foo” is not the same as “Foo”.
Also, because SNAPpy is a dynamically typed language, it is perfectly legal to invent a new variable on-the-fly,
and assign a value to it. So, the following SNAPpy code snippet:
foo = 2
Foo = "The Larch"
…results in two variables being created, and “foo” sll has the original value of 2.
Case sensivity applies to funcon names as well as variable names.
linkQuality = getlq()
…is a script error unless you have defined a funcon getlq(). The built-in funcon is not named “getlq”.
linkQuality = getLq()
…is probably what you want.
Beware of Accidental Local Variables
All SNAPpy funcons can read global variables, but (as with Python) you need to use the “global” keyword in
your funcons if you want to write to them.
count = 4
def bumpCount():
count = count + 1
…is not going to do what you want (the global count will sll equal 4). Instead, write something like:
count = 4
def bumpCount():
global count
count = count + 1
Don’t Cut Yourself Off (Packet Serial)
Portal talks to its “bridge” (directly connected) node using a packet serial protocol.
SNAPpy scripts can change both the UART and Packet Serial sengs.
This means you can be talking to a node from Portal, and then upload a script into that node that starts using
that same serial port – or even just the same SNAP Engine pins – for some other funcon (for example, for
prinng script text output, or as an externally triggered sleep interrupt). Portal will no longer be able to
communicate with that node serially.
SNAP® Network Operang System 45