Error while runing diadem asynchronous script from labview on dual core processor

Question

Urgent need of some help / advice here!
Single core runs fine... dual core produces error: Error in <XYaxis.vbs> (line: 17, column: 1): Error while opening object. The object currently open has no subobjects. Forgotten ObjClose?
The main software built in labview used for daq and analysis generates a PDF report on completion of a test, utilising diadem. For this I use the diadem express vi in labview to generate a multi page report, whereby I use for loop to iterate an array of channels for each page. This for loop has a shift register too. After each page I run a script to adjust a few parameters like linear/log, begin/end and line thickness using the diadem connectivity tookit. See script below:
Call GraphObjOpen("2D-Axis1")
Call GraphObjOpen("2DXAxis8_1")
D2AxisXDivMode = "linear"
D2AxisXScaleType = "begin/end manual"
D2AxisXBegin = 20
D2AxisXEnd = 20000
Call GraphObjClose("2DXAxis8_1")
Call GraphObjOpen("2DYAxis8_1")
D2AxisYDivMode = "linear"
D2AxisYScaleType = "complete automatic"
D2AxisYBegin = 0
D2AxisYEnd = 0
Call GraphObjClose("2DYAxis8_1")
FOR c = 1 TO CurveNoMax
If D2CurveObj(c) = "" Then Exit For ' c
Call GraphObjOpen(D2CurveObj(c))
D2CurveLineWidth = 0.75
Call GraphObjClose(D2CurveObj(c))
NEXT ' c
Call GraphObjClose("2D-Axis1")
There is also a screenshot of the vi: (script file is generated by the Dscript vi and saved to disk. then path is passed to the diadem script vi.)
What I find is, after the first report page is complete in diadem the second page ALWAYS shows the error as shown at the top. However, on my P4 laptop with single core (no hyperthreading) its runs FINE EVERY TIME with any given number of channels/pages in the report.
My current chain of thought is that the superfast dual core is doing something in parallel therefore not waiting for the previous page to complete or finish closing its object!? however, in my for loop I use a shift register as named before, surely this kind of loop cannot be divided over more cores/parallel threads? as it has to wait for the response of the previous.!?!? Im running LV 8.6 on WinXP for this project and I didnt even think multicore processing for for loops is included in this version.
The other thing is... this script used to run fine on the dual core until I added the last part that uses a for loop to get every line of the graph to be the thinkness I need. Is this for loop the culprit? Can I stop it from executing over multiple cores/threads? I read a post saying that from diadem 8 there was multi core support. this triggered my doubt
As always any comments are most appreciated
AL
:. LV2010 SP1 ... W7 .:
Solved!
Go to Solution.

Answer 1

Hi Al,
I have a theory, but only you can test it.  In your VI screenshot, you have the boolean input for the DIAdem Execute Script.vi set to asynchronous=TRUE.  My theory says that if you change that boolean (and all others like it) to asynchrous=FALSE that the error will not occur on the multicore computer.  The other thing you could try would be to consolidate all REPORT commands that pertain to one REPORT page into a single ActiveX call to DIAdem.  In the screenshot below you have at least 2 separate VIs calling DIAdem, so that's at least 2 separate ActiveX calls for one REPORT sheet.
Here's what I think is going on.  On a multicore computer there is the potential for different ActiveX commands from LV to DIAdem to execute on different cores, which may result in a timing problem on the DIAdem side.  DIAdem 11.x and earlier runs exclusively on 1 CPU, so the incoming ActiveX commands should be sequenced correctly by DIAdem's ActiveX to-do list.  Theoretically DIAdem should serialize all the incoming ActiveX commands (regardless of which CPU processed them) in the order that they arrived at the DIAdem ActiveX server(s).  On the sending side, LabVIEW's dataflow execution should theoretically guarantee that all the ActiveX requests are being sent in the correct order.  But it is theoretically possible that the operating system's ActiveX processing queue might not send all the ActiveX commands to DIAdem in the order that it receives them from LabVIEW-- IF YOU'VE SELECTED ASYNCHRONOUS PROCESSING.
See if these clues help,
Brad Turpin
DIAdem Product Support Engineer
National Instruments