LabPython error message

[Gerod]

I'm trouble with a simple python+mysql+reportalab script called by LV. The problem is that the 1st time i run the vi there is no proble, but the 2nd,3rd,.. time doesnt work with a error PYTHON Execute Script__ogtk.vi->python_report.vi:<type 'exceptions.TypeError'>,

The LabVIEW vi does the following steps:

0) create a new python session

1) read the script from file

2) set the 3 string variables select_obj, table, where

3) runs the script

4) close the python session

the python script is the following

import MySQLdbfrom reportlab.pdfgen import canvasdb=MySQLdb.connect(host="localhost",user="root", passwd="password",db="test")
cursor = db.cursor()
cursor.execute("SELECT %s FROM %s WHERE %s" % (select_obj, table, where) )
c = canvas.Canvas("prova.pdf")
y=700;
while 1:
row = cursor.fetchone()
if row == None: break
c.drawString(100, y, "Description: %s || Allarm? %s" % row)
y = y - 100

c.drawString(100, y, "Number of rows returned: %d" % cursor.rowcount)

cursor.close()
db.close()
c.showPage()
c.save()

someone else encountered a similar behaviour?

[Rolf Kalbermatter]

QUOTE (Gerod @ Aug 1 2008, 02:43 AM)

I'm trouble with a simple python+mysql+reportalab script called by LV. The problem is that the 1st time i run the vi there is no proble, but the 2nd,3rd,.. time doesnt work with a error PYTHON Execute Script__ogtk.vi->python_report.vi:<type 'exceptions.TypeError'>,

The LabVIEW vi does the following steps:

0) create a new python session

1) read the script from file

2) set the 3 string variables select_obj, table, where

3) runs the script

4) close the python session

the python script is the following

import MySQLdbfrom reportlab.pdfgen import canvasdb=MySQLdb.connect(host="localhost",user="root", passwd="password",db="test")cursor = db.cursor()cursor.execute("SELECT %s FROM %s WHERE %s" % (select_obj, table, where) )c = canvas.Canvas("prova.pdf")y=700;while 1:row = cursor.fetchone()if row == None: breakc.drawString(100, y, "Description: %s || Allarm? %s" % row)y = y - 100c.drawString(100, y, "Number of rows returned: %d" % cursor.rowcount)cursor.close()db.close()c.showPage()c.save()

someone else encountered a similar behaviour?

To your question: not really!But you have quite a few things in that script that access external components to Python. I'm not going to setup an SQL server and a PDF formating solution to test something like that. Can you reproduce that with a simple Python script too?

The problem could be in the type conversion inside LabPython between LabVIEW and Python but it could be just as much be something in one of the other components involved or a bad interference between one of these components and the fact that Python runs embedded inside LabVIEW. It could be even that Python or one of these components does not like something LabVIEW does for its executable environment and the way LabPython is done it will run and execute Python and everything in there inside the LabVIEW process. In that case it could be a possibility that it is even LabVIEW version dependant.

Rolf Kalbermatter

[Scott Carlson]

QUOTE (rolfk @ Aug 1 2008, 05:05 AM)

To your question: not really!

But you have quite a few things in that script that access external components to Python. I'm not going to setup an SQL server and a PDF formating solution to test something like that. Can you reproduce that with a simple Python script too?

The problem could be in the type conversion inside LabPython between LabVIEW and Python but it could be just as much be something in one of the other components involved or a bad interference between one of these components and the fact that Python runs embedded inside LabVIEW. It could be even that Python or one of these components does not like something LabVIEW does for its executable environment and the way LabPython is done it will run and execute Python and everything in there inside the LabVIEW process. In that case it could be a possibility that it is even LabVIEW version dependant.

Rolf Kalbermatter

I agree with Rolf -- (and there is no way I'm installing mysql just for fun . Separate the problem, test your code in a pure python interpreter first, and deduce whether its your code, some component your code uses, or the environment you are executing your code in.

-Scott

[Gerod]

This is a second clear version to reproduce the problem without MySQL.

This script can run n-times from commandline but only 1 calling it from LV

[/b]from reportlab.pdfgen import canvasd = canvas.Canvas("scriptino.pdf")a=1b=1c=a+bd.drawString(100, 100, "a+b= %d" % c)d.showPage()d.save()[b][/b][b]

This script can run n-times both from commandline and from LV

[/b]
from reportlab.pdfgen import canvas
a=1
b=1
c=a+b
  [b]

?!? :headbang:

[Scott Carlson]

QUOTE (Gerod @ Aug 1 2008, 10:41 AM)

This is a second clear version to reproduce the problem without MySQL.

This script can run n-times from commandline but only 1 calling it from LV

[/b]from reportlab.pdfgen import canvasd = canvas.Canvas("scriptino.pdf")a=1  b=1c=a+bd.drawString(100, 100, "a+b= %d" % c)d.showPage()d.save()[b][/b][b]

This script can run n-times both from commandline and from LV

  [/b]from reportlab.pdfgen import canvas  a=1b=1  c=a+b  [b]

?!? :headbang:

Gerod -- The fact that you can run the code several times from a command-line and only once in LV, tells me that there may be some sort of "house cleaning" required. In the command-line environment maybe things are being destroyed (canvas object 'd') after it is ran, in LV maybe this is not happening. You are instantiating a canvas object. Is there a method for destroying it when finished? I see that when you do not include the canvas calls in your code, ir runs just fine.Are you running this code in a loop? How are you executing this. Do you hit the play button, run once, hit the play button, run twice etc? I only ask this because, you should only need to instantiate the canvas object once. If its the case where you are not instantiating repeatedly, refer back to the first paragraph..

I hope this helps.

-src

[Gerod]

This is the vi i run (once) to call the script.

No loop, no run continuously, only click twice the arrow.

I forgot. I tried also to add p=None at the end of the script but without success.

The only way to run twice is to close LabVIEW completely and load again the vi, these suggests me that there is some resource reserved by LV.

[Scott Carlson]

QUOTE (Gerod @ Aug 1 2008, 11:46 AM)

This is the vi i run (once) to call the script.

No loop, no run continuously, only click twice the arrow.

I forgot. I tried also to add p=None at the end of the script but without success.

The only way to run twice is to close LabVIEW completely and load again the vi, these suggests me that there is some resource reserved by LV.

Gerod -- This may be way off base but, have you tried calling the decontructor method for your object at the end of your program? i.e. d.del() ? Try that? It appears that the guy who wrote the LabPython may not be properly cleaning up after execution and exit, I don't think its a Labview issue per say, as much as it is a LabPython issue.

Also, try to comment out the instantiation line before you execute a second time (comment the d = canvas.Canvas line) and see if that works.. The object may already be there? If these suggestions don't work, I'll install LabPython tonight after work, and give it a shot locally.

-src

QUOTE (Gerod @ Aug 1 2008, 11:46 AM)

This is the vi i run (once) to call the script.

No loop, no run continuously, only click twice the arrow.

I forgot. I tried also to add

p=None

at the end of the script but without success.

The only way to run twice is to close LabVIEW completely and load again the vi, these suggests me that there is some resource reserved by

LV

.

Gerod -- This may be way off base but, have you tried calling the decontructor method for your object at the end of your program? i.e. d.del() ? Try that? It appears that the guy who wrote the LabPython may not be properly cleaning up after execution and exit, I don't think its a Labview issue per say, as much as it is a LabPython issue.

Also, try to comment out the instantiation line before you execute a second time (comment the d = canvas.Canvas line) and see if that works.. The object may already be there? If these suggestions don't work, I'll install LabPython tonight after work, and give it a shot locally.

-src

[Gerod]

QUOTE(Scott Carlson @ Aug 1 2008, 06:55 PM)

Gerod -- This may be way off base but, have you tried calling the decontructor method for your object at the end of your program? i.e. d.del() ? Try that? It appears that the guy who wrote the LabPython may not be properly cleaning up after execution and exit, I don't think its a Labview issue per say, as much as it is a LabPython issue.

I tried d.del() also from commandline but...

>>> c=1

>>> d.drawString(100, 100, "a+b=: %d" % c)

>>> d.showPage()

>>> d.save()

>>> d.del()

File "<stdin>", line 1

d.del()

^

SyntaxError: invalid syntax

>>>

QUOTE(Scott Carlson @ Aug 1 2008, 06:55 PM)

Also, try to comment out the instantiation line before you execute a second time (comment the d = canvas.Canvas line) and see if that works.. The object may already be there? If these suggestions don't work,

I'll install LabPython tonight after work, and give it a shot locally.

PYTHON Execute Script__ogtk.vi->scriptino.vi:<type 'exceptions.NameError'>, name 'd' is not defined

[Rolf Kalbermatter]

QUOTE (Scott Carlson @ Aug 1 2008, 12:55 PM)

Gerod -- This may be way off base but, have you tried calling the decontructor method for your object at the end of your program? i.e. d.del() ? Try that? It appears that the guy who wrote the LabPython may not be properly cleaning up after execution and exit, I don't think its a Labview issue per say, as much as it is a LabPython issue.

The guy responsible for LabPython is in fact yours truely

I think you are up to something when feeling that not deallocating the canvas object after execution is the culprit. And I'm not sure that assigning NULL to an object variable will actually properly clear that object although I must add that my knowledge about Python itself is limited.

As to automatically cleaning up after a script: No there is no specific garbage collection done when de script finishes execution. I'm not even sure how to do that completely safe with Python hooks as it would be hard to track down all resources that a script might have allocated itself and there are certainly cases possible where this is not even desired.

I do cleanup the Python state when the script node is disposed, respectively when using the VI interface to LabPython contrary to the script node, when the Python session is closed. This should in my opinion cleanup all Python related resources that might have been allocated during that session.

If you want to reuse a Python resource between script executions you should probably pass this resource as a uInt32 out of the script and feed it back in on consequent execution. On the other hand all script variables are stored inside the Python state by name so as long as the state is not modified in that respect the object may be still allocated and valid on a consequent execution.

While it may seem desirable to deallocate all resources at the end of each script execution automatically it was not my intention to actually emulate a Python command shell one by one. So state information will persist between script executions as long as the scribt is not unloaded which as it is implemented now will only happen when the VI containing the script node will leave memory or in the VI interface to LabPython when the session is closed.

Rolf Kalbermatter

[Scott Carlson]

QUOTE (rolfk @ Aug 1 2008, 03:59 PM)

The guy responsible for LabPython is in fact yours truely

I think you are up to something when feeling that not deallocating the canvas object after execution is the culprit. And I'm not sure that assigning NULL to an object variable will actually properly clear that object although I must add that my knowledge about Python itself is limited.

As to automatically cleaning up after a script: No there is no specific garbage collection done when de script finishes execution. I'm not even sure how to do that completely safe with Python hooks as it would be hard to track down all resources that a script might have allocated itself and there are certainly cases possible where this is not even desired.

I do cleanup the Python state when the script node is disposed, respectively when using the VI interface to LabPython contrary to the script node, when the Python session is closed. This should in my opinion cleanup all Python related resources that might have been allocated during that session.

If you want to reuse a Python resource between script executions you should probably pass this resource as a uInt32 out of the script and feed it back in on consequent execution. On the other hand all script variables are stored inside the Python state by name so as long as the state is not modified in that respect the object may be still allocated and valid on a consequent execution.

While it may seem desirable to deallocate all resources at the end of each script execution automatically it was not my intention to actually emulate a Python command shell one by one. So state information will persist between script executions as long as the scribt is not unloaded which as it is implemented now will only happen when the VI containing the script node will leave memory or in the VI interface to LabPython when the session is closed.

Rolf Kalbermatter

Rolf -- I hope you didn't take my above statement personally! I had no idea that LabPython even existed until this morning! Very cool.

-Scott

[Rolf Kalbermatter]

QUOTE (Scott Carlson @ Aug 1 2008, 05:30 PM)

Rolf -- I hope you didn't take my above statement personally! I had no idea that LabPython even existed until this morning! Very cool.

-Scott

Well I didn't take it bad in any way! I actually welcome your comments to this.

The two big reasons why I haven't done much with LabPython anymore is that I don't really use it for quite some time and there is little feedback other than sometimes a single statement like it doesn't work please help and when asked back what doesn't work and to please provide some simple example that can be used to reproduce it there is usually little reaction.

That and of course the fact that there is lots and lots of other work to do and some of that is either paid or for one or the other reason closer to my heart than LabPython.

Rolf Kalbermatter

[Gerod]

Hi to all!

Finaly I found a way to fix the problem. Really I dint solved the problem, I only avoid it.

The trick is to run 2..n times the script without closing the Python session.

Ciao