pySerial and Robot Framework?
Josephine
pySerial. It spawns a reader process, and works just fine -- I send a
message over the port, and get one back.
I have tried integrating this into Robot Framework. In my setup
(suite setup) I initialize this thread and start it running. There
are no errors. My next Robot Framework keyword then successfully
sends the message. However, my reader thread never gets the message.
Investigating, the reader thread never actually runs -- I changed it
to set a global variable to True as its first statement, and the
variable is never set to True.
While I could be having code issues somewhere, I know the threading
stuff is funky in Python -- could this read thread be perma-starved
because of the way Robot Framework handles executing keyword-driven
Python code?
Pseudo code would look like this:
1. Suite Setup keyword in RF starts read thread, no errors (forced
fail to verify fail failed.)
2. Test case activates send-message keyword. Again, no errors.
3. keyword sleep 1s <-- To let HW on other end of serial port have
time to respond. This is normally very fast. Have bumped up to 10s
sleep, no change.
4. Log variables that the reader thread should have set. All are
still set to None
5. Log variable that the reader thread should have set on start.
Still False. <-- Indicates reader thread is starved (???) and never
got to 1st Python line?
Any ideas?
Also, is there any way to log ALL Python "print" output, regardless of
source? I note that only prints from the function directly called are
logged -- NOT the prints from any sub-functions called (to say nothing
of another thread's prints.)
Any way to capture all this? That would help a whole lot in debugging
this.
Josephine
get the responses. This throws a monkey wrench into using Robot
Framework as I may have to wait a finite number of seconds (rather
than ms) for responses, until Python/RF get around to giving time to
the serial port read thread.
Is there a rule for this? I've seen some general Python rules, but
don't know how RF may alter or overload that.
Waiting for a multi-second timeout will also greatly slow the
automated aspect of Robot Framework.
Any ideas still?
cdekter
from 2.1.3 which sound similar to what you are experiencing. What I'm
seeing is that any time I execute tasks in a thread other than the
main thread, it takes a long time. My theory is that RF is somehow
tying up the GIL, but I have no idea how or why. This is a serious
performance issue however and should be looked into urgently... I will
report back if I found out anything more.
Janne Härkönen
> Are you using RF2.5? I'm getting some weird symptoms after upgrading
> from 2.1.3 which sound similar to what you are experiencing. What I'm
> seeing is that any time I execute tasks in a thread other than the
> main thread, it takes a long time. My theory is that RF is somehow
> tying up the GIL, but I have no idea how or why. This is a serious
> performance issue however and should be looked into urgently... I will
> report back if I found out anything more.
>
Hello,
Currently all Robot Framework code runs in a single thread (and does
not try to monitor any other threads). This of course doesn't mean
that the symptoms you see wouldn't be caused by RF.
A simple example of this behavior would of course be really sweet,
because otherwise I have no idea how to proceed in debugging.
thanks,
__j
Pekka Klärck
> On Mon, Jun 28, 2010 at 6:11 AM, cdekter <cde...@gmail.com> wrote:
>> Are you using RF2.5? I'm getting some weird symptoms after upgrading
>> from 2.1.3 which sound similar to what you are experiencing. What I'm
>> seeing is that any time I execute tasks in a thread other than the
>> main thread, it takes a long time. My theory is that RF is somehow
>> tying up the GIL, but I have no idea how or why. This is a serious
>> performance issue however and should be looked into urgently... I will
>> report back if I found out anything more.
>
> not try to monitor any other threads). This of course doesn't mean
> that the symptoms you see wouldn't be caused by RF.
There is one exception to this rule: timeouts. As Bulkan investigated
some time ago, they may cause performance problems in some cases due
to the GIL:
http://code.google.com/p/robotframework/issues/detail?id=497
> A simple example of this behavior would of course be really sweet,
> because otherwise I have no idea how to proceed in debugging.
Exactly.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
Pekka Klärck
> I have a utility I've written to communicate to a serial device using
> pySerial. It spawns a reader process, and works just fine -- I send a
> message over the port, and get one back.
>
> I have tried integrating this into Robot Framework. In my setup
> (suite setup) I initialize this thread and start it running. There
> are no errors. My next Robot Framework keyword then successfully
> sends the message. However, my reader thread never gets the message.
>
> Investigating, the reader thread never actually runs -- I changed it
> to set a global variable to True as its first statement, and the
> variable is never set to True.
Have you set the test library scope? Be default a new instance of the
test library is created for every test case, and thus changes you do
the library state in a suite setup aren't visible for test cases. As
explained in the User Guide, you can easily change the scope by
setting `ROBOT_LIBRARY_SCOPE` attribute:
http://robotframework.googlecode.com/svn/tags/robotframework-2.5/doc/userguide/RobotFrameworkUserGuide.html#test-library-scope
> Also, is there any way to log ALL Python "print" output, regardless of
> source? I note that only prints from the function directly called are
> logged -- NOT the prints from any sub-functions called (to say nothing
> of another thread's prints.)
There should be no difference is output printed by your keyword
directly or by a sub function it uses. If you use threads that stay
alive between keyword calls thinks are different, though, because the
framework intercepts the standard output and error streams before
running a keyword and releases them afterwards. In these cases you
can, for example, write the outputs to an external text file.
Christiaan Dekter
On an unrelated note, I'm curious how you guys handled the problem with signals in Python (for cleanly stopping test execution). AFAIK as soon as you start using multiple threads in Python, you can't use signal handlers at all. This means that as soon as I added a timeout to a test, the signaling would cease to work.
Pekka Klärck
> My problem was unrelated, so false alarm I'm afraid.
I'm happy to hear it was a false alarm. =)
> On an unrelated note, I'm curious how you guys handled the problem with
> signals in Python (for cleanly stopping test execution). AFAIK as soon as
> you start using multiple threads in Python, you can't use signal handlers at
> all. This means that as soon as I added a timeout to a test, the signaling
> would cease to work.
The signal handler code is visible at [1] and you can search in the
code base for those few places where this handler is called. As you
can read from [2], signals and threads work well in Python as long as
you do the main signal operations (such as setting signal handlers) in
the main thread.
[1] http://code.google.com/p/robotframework/source/browse/trunk/src/robot/running/signalhandler.py
[2] http://docs.python.org/library/signal.html
Josephine
Python: 2.6.5
RF: 2.1.3
Others
Idle: 2.6.5
Tk (?): 8.5
RIDE: 0.23
Josephine
On Jun 28, 3:34 am, Pekka Klärck <p...@iki.fi> wrote:
> 2010/6/25 Josephine <josephineo...@gmail.com>:
> > I have a utility I've written to communicate to a serial device using
> > pySerial. It spawns a reader process, and works just fine -- I send a
> > message over the port, and get one back.
>
> > I have tried integrating this into Robot Framework. In my setup
> > (suite setup) I initialize this thread and start it running. There
> > are no errors. My next Robot Framework keyword then successfully
> > sends the message. However, my reader thread never gets the message.
>
> > Investigating, the reader thread never actually runs -- I changed it
> > to set a global variable to True as its first statement, and the
> > variable is never set to True.
>
> Have you set the test library scope? Be default a new instance of the
> test library is created for every test case, and thus changes you do
> the library state in a suite setup aren't visible for test cases. As
> explained in the User Guide, you can easily change the scope by
1. Oops, get a syntax error trying this: Static is highlighted:
**** There's a syntax error in your program: Invalid syntax ("static"
is highlighted)
class MyHWDeviceWrapperClass():
"""Wrapper class for the HW device (v. 1.0) that we talk to over
serial port COM1.
"""
public static final String ROBOT_LIBRARY_SCOPE = "GLOBAL"; #
Tell Robot Framework we want one and only one instance of this
library, to be shared by all suites and test cases.
(I note a semicolon after the example on that web page, but removing
it doesn't solve the problem.)
2. Without that set (haven't succeeded in doing it, yet) the thread is
running fine. Then the next TC runs and, interrogating the thread
object, I see its state is "stopped". But I have no message from the
thread that the thread is exiting.
I suspect, since it is in the Suite Setup, that the Suite Setup ends,
and RF/Python then kills that little world, including stopping any
started threads???
Josephine
(in your class)
public ROBOT_LIBRARY_SCOPE = "GLOBAL"
And none of that other stuff???
Janne Härkönen
> Apparently this is the way it should be??
>
> (in your class)
> public ROBOT_LIBRARY_SCOPE = "GLOBAL"
just
ROBOT_LIBRARY_SCOPE = "GLOBAL"
is enough with Python classes. "public static final" is for Java.
hth,
__j
Josephine
Hopefully it was a false alarm. I'll keep my eye out.
Thanks for the library scope info, too!
Rohan Majumdar
Hope this message finds you well.
I find myself dealing with the same kind of asignment related to the testig of an embedded devide through a serial port.
Can you please be kind enough to give me some piece of your code as a starting point.
Your help is appreciated.
Thanks and regards
Rohan