Windows OS dependent behavior for ROOT DLL in Labview

ROOT
1

Hey there,

I have a LabView VI which controls a machine that obtains data and would like to analyze the data using a ROOT macro, create some plots, and write the plots to disk so that I can pull them up in Labview for the user to review. I have created a DLL for a ROOT macro that I am calling in LabView using the Call Library Function Node. The DLL is created in Microsoft Visual Studio 2013.

I can run this whole operation perfectly fine on my laptop running Windows 10. The canvas is never shown on screen, but it is saved to disk, which is all I need to do. However, when I try to run the same thing on the lab computer running Windows 7, Labview will crash with error code 1097 when I attempt to call TCanvas::Print() or TGraph::Write() when writing to a root file. The ROOT and Labview installations are exactly the same on both machines. I’ve tried to use gROOT->SetBatch() to quell any potential errors involving ROOT’s interaction with the screen, but this doesn’t prevent the crash. I have no issues reading or writing text files to disk using the DLL, so it’s not a permissions issue.

Attached are ITkModuleAnalysis.cpp (2.3 KB)
the ROOT macro anddata.txt (33.8 KB)
data file for testing. I run Labview 2015 and ROOT v5.34.34. Can anyone offer help/advice/ideas on how to fix or further investigate this odd behavior?

Thanks!

2

Hi,

Can you attach the debugger on it when it crashes? Are you sure it is the same architecture? The error code 1097 is coming from LabView, did you check the possible ways of debugging this?

Cheers, Bertrand.

3

Hi,

The error output only indicates that there is an issue with the DLL, but I’ve attached the error indicator. Both machines are running 64 bit OS with 32 bit labview. The DLL has 32 bit target build. There doesn’t seem to be any way (that I’m aware of) to get more information out of LabView about why it’s crashing.

The code only crashes when certain commands are run, e.g. TCanvas::Print(). I’m wondering what’s going on under the hood when this function is called; perhaps understanding this better would lead to a better understanding of what the underlying issue is with the DLL. I don’t believe the issue has to do with memory allocation because there would be an issue when other functions are called on a new TCanvas object.

Best,
Brendon

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.