Lookout

cancel
Showing results for 
Search instead for 
Did you mean: 

lookout report graphic

problem:

Each time a "process" is completed I have lookout generate a report. The report is named with a unique part number each time so after each "process" is completed a new report is generated (the file is NOT over-written).

Each report simply contains a "snap shot" of a certain control panel using a "display" parameter of the "report" object. The problem is that even though lookout generates a new html file for each report, it over-writes the graphic snap shot of the control panel with the same file name. Is there anyway to get around this?
0 Kudos
Message 1 of 9
(3,951 Views)


Hi,

Since we have no control over the names of the snap shot images (graph1, etc.), the only solution is to create each report in a separate folder.

In the Report object you can specify the unique part number for the Output directory. This way you are ensured that each report is created in its own folder and the graphics are unique to that report.

HOWEVER, there's a problem as you might have discovered. The Output directory data member of the Report object expects a pre-existing folder -- it will not create a folder if it's not already there.

So, the problem boils down to how to create new folders from within Lookout. Windows scripting is a relatively easy option. We will have to run the script using the Run object.

I am attaching a Windows Host Script which takes an argument (folder path) and creates the folder. In the example I input this folder path in a TextEntry object (you can replace this with whatever is the source of your part numbers).

Executing this script with the Run object is tricky because we first need to launch the WScript.exe, then pass the script file, and finally the folder. This means a whole bunch of double qoutes and &s!

The command line of my Run object looks like this:

"""WScript.exe"" ""c:\temp\cfolder.wsf """&" "&TextEntry1.value



Please detach the cfolder.wsf script file to your c:\temp folder, or change the path in the above command line. You can test this with the attached Lookout process file: createfolder.lks (change file types to LKS when opening this in Lookout).

Here's more info' on Windows Host Scripting

And here's a KB article on using the Run object with arguments.

The other option is to move the report as soon as it is created to a different folder so that the next report doesn't overwrite the graphics. This too can be accomplished using the move methods available in Windows scripting.

Hope this helps.

Regards,

Khalid


Download All
Message 2 of 9
(3,951 Views)
Thank you very much Khalid... Your solution works great. If this option wasn't available I would have had to create a massive table within the report parameters for eight separate screen shots (there is over 200 objects on each screen that need to be recorded at the end of a process before the next process begins). It would have taken me two weeks... Thank you again

Pete
0 Kudos
Message 3 of 9
(3,951 Views)
Hi Khalid, I need your help for one more thing.

I would like to be able to delete a folder created with the "run object" and script through lookout. I've been trying to copy the procedure we did to create the folder only changing the script. But I don't have enough experience with scripting.

This is what I have for a script:







What am a doing wrong?

Thanks for all your help

Pete
0 Kudos
Message 4 of 9
(3,951 Views)


Hi Pete,

You don't need the function and the subs above. The following script worked for me. You can test the script first by replacing the WScript.Arguments(0) below with a real path to a test folder (e.g., "c:\test\temp" including the qoutes):







Hope this helps.
Regards,

Khalid

___________________
0 Kudos
Message 5 of 9
(3,951 Views)
Thanks again Khalid.... The script works great.

Now my Lookout process can automatically create folders to save "process data" in, and automatically delete the data after a user selectable amount of time (i.e. 1,2,3,4... weeks) The user can also call up any data file by entering the "load" number into a TextEntry then pressing an "Enter" push button on the screen.

What would be nice is if I could open a windows "open folder menu" where the operator could browse for the file if he didn't know the exact name.

Would this be a simple script operation like the last two, or is it more complicated than that?

Have a great weekend

Pete
0 Kudos
Message 6 of 9
(3,951 Views)


Hi Pete,

I am afraid a sript for browsing and selecting a file is much more involved. We can easily "browse" folders and files, but I do not know how to pass the selected file back to Lookout. This does not seem to be trivial.

The following script will launch the standard Windows Explorer; you can customize as to what folder it starts-up with ("c:\temp" in the example):

dim oShell
set oShell = CreateObject("Shell.Application")
oShell.Explore "c:\temp"

And this one opens a "folder browser" and echos the selected folder:

dim oShell
dim oFolder
dim oFolderItem
set oShell = CreateObject("Shell.Application")
set oFolder = oShell.BrowseForFolder(0, "Choose a Folder", 0)
set oFolderItem = oFolder.Items.Item
WScript.Echo "Selected path: " & oFolderItem.Path

Again, you can specify a starting folder by replacing line 5 with something like this:

set oFolder = oShell.BrowseForFolder(0, "Choose a folder", 0, "c:\temp")

Note that the latter browses only the folders and not files inside them.

Just browsing the folders or even files with the former script may not be of much use.. except the user now can make a note of the file and go back to Lookout and enter it there OR can double-click the file in Explorer to launch it from there -- not a clean solution.

An alternate and better solution I think would be to use the DataTable object. As you know, it's basically a table inside Lookout where you can store data and look it up. The good thing in this case is, DataTable has a drop down list box in which it displays by default the values from the first column of the table -- sort of a browser!

So, if you make entries to the first column of the DataTable with the filenames (or paths, as appropriate) when you are in the process of creating your reports, the user can then just click on the menu button (dropped when you first create the DataTable object) and browse and select the file.

You can test this by creating a test DataTabale object, connect some strings to the first column, e.g.:

Table1.A1.txt = "one"
Table1.A2.txt = "two"
Table1.A3.txt = "three"

Then insert an Expression on Table1.A.txt.1

Using the "menu button" you can now select a value and that's what gets set for Table1.A.txt.1 which you can use in launching your report.

Hope this helps.

Regards,

Khalid 🙂


0 Kudos
Message 7 of 9
(3,951 Views)
Thanks Khalid...

I've just integrated your first option of just opening Explore. It was quick, easy, and works great. If I had more time I'd give the datatable idea a shot but my boss wants this project finished yesterday... Thinking about it for just a few short minutes I'm not even sure if it could even be done because the table would have to "grow" dynamically with each part number that is processed during the day. I don't think it is possible to automatically add rows to the matrix and then assign a cell a particular part number. But anyway the datatable was a great thought - I hope I get a chance to play with it more in a future endeavor. Thanks again,

Pete

P.S. Just one question, if you don�t mind answeri
ng � do you work for NI or are you just an extremely knowledgeable and helpful HMI integrator 🙂
0 Kudos
Message 8 of 9
(3,951 Views)


Glad to hear that you were able to complete your project.

Just for future reference: DataTable does grow dynamically. You don't need to forward-declare the size of the table. There are also what are called "cursors" which can track where you have been writing to and then append to it, etc. I find it to be one of the most powerful objects in Lookout.

I am not on NI's Lookout Support team.. I am just as they say, a Lookout enthusiast!

Regards,

Khalid 🙂


0 Kudos
Message 9 of 9
(3,951 Views)