06-11-2009 01:22 PM
Even if I just have a single vi open that only has one Scaling and Mapping express vi in it, it can take 30 seconds to close the dialog box. In my real application that is huge I've never had the patience to wait for it, many minutes. I've used these extensively in this project that was started in 7.1. Problem persists after running the f1 patch.
The more data points in the file the worse it is.
06-12-2009 02:49 AM
Hi groundhog,
Good Morning and I hope your well today.
Thanks for the post.
Could you please provide some example code that would allow me to benchmark this? I will try it in a newest version of LabVIEW as well.
From what I have researched there doesnt appear to be any known issues with this or comments on its performance.
How have you configured it?
Thanks,
06-17-2009 10:49 AM
Hi Thanks for the reply, this is the first chance I've had to respond. Usually I load an .lvm file like the one attached to configure. I have changed the extension to .txt to get it past filter this board imposes
06-18-2009 04:02 AM
Hi groundhog,
Thanks for the reply. I tested this and it worked within a second in LabVIEW 8.6 and didn't seem any slower in other LabVIEW Versions.
Can I ask you to zip your LabVIEW code which is reading from an lvm file, incase its something in your wider application that is affect the issue. Are you writing and reading from this file at the same time?
06-18-2009 01:24 PM
Can I ask you to zip your LabVIEW code which is reading from an lvm file, incase its something in your wider application that is affect the issue. Are you writing and reading from this file at the same time?
Maybe I'm not being very clear. I'm not using code to read the .lvm...I'm just browsing to the file in the "Define Signal" dialog by clicking on "Load Data..."
.
It then loads the data quickly, but when back at the "Define Signal" box, clicking "OK" or "Cancel" takes a very long time. I don't think the Scaling and Mapping vi ever goes to look at that file again once it's loaded.
I clicked "Cancel" on the PC, before I started typing my response and it still hasn't returned, the "Cancel" button is still depressed, in fact I can click on all the buttons and they all stay depressed. I can type numbers into fields. The scroll bar on Data Points still works.The computer is not hung I can go to other non-LV windows. Clicking on a LV window gives me a beep. CPU is at 100%
Windows task manager says LabView is staus "Running"
After using End Task in Task Manager I still see a NI application running-"niasstnt" but trying to switch to it doesn't show a window.
It's still not responding, I'll have to kill LV to continue.
OK, fresh reboot. Start LV. Recovery manager...don't need to recover anything. New vi. CPU usage =1%
Right click on block diagram--Express--Arithmatic & Comparison---Scale and Map---drop on diagram
Configure scaling and mapping dialog box opens...cpu still at 1%
Choose "Interpolated" radio button....cpu still at 1%
Click "Define Table"....cpu still at 1%
Click "Load Data""....cpu still at 1%
Browse to Definedsignal.lvm, then click OK
Data loads immed, graph displays immed...cpu at 100% for a moment or two, then down to 1% and then back up to 100%.
Open Paint take some screen shots for you.
click OK in Define Signal dialog box at 2:09 pm. OK button stays down. CPU=100%
Move screen shots to jump drive to attach to this post from my laptop
It's 2:12. OK button still in depressed position CPU still at 100%
Made attached Word documnet with compressed screenshot and attached to post
2:19 and no change, OK button still stuck down, CPU at 100%
Well, I'm going to go ahead and send this to you, see if you can recreate. No sense in my sending you my whole app I don't think, but if you still feel that's important I will. But it's not in memory and the problem still appears.
2:21 no change
Thanks James,
Paul
06-18-2009 02:14 PM
06-19-2009 08:07 AM
Hi Groundhog,
Good afternoon and I hope your well today.
I now understand your issue and have seen it in LabVIEW 8.6.1. This only seems to be an issue if a file has already been loaded, and you try to load one again. It seems the Express VI is doing a lot of processing. However, there seems to be a fair other things the VI doesn't respond to well.
I feel, to improve the situation may be best to develop our own VI. I don't mind helping you with.. so if you are interested what are you trying to do? Thanks,