-
Posts
576 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by orko
-
-
-
By the look of the source you provided, it looks like there is a cookie being stored when you log on successfully (you can see the error javascript source setting this cookie's string to "LOGIN_LEVEL=0; path = / " on failure ).
This might explain why the first attempt succeeds and the second one fails -- if there is a session cookie set up to store some sort of connection/session ID and it doesn't match when sent to the second unit you are testing.
I'm unclear on how LabVIEW (datasocket or VI server) stores cookie related information in it's session cache. But if my instincts are correct in Windows, I would assume it uses the same mechanisms that Internet Explorer uses. That is if LV7.x supported session cookies at all...
To test this, before running the second unit's test try clearing out Internet Explorer's cache and cookie history. In fact it may be a good idea to clear them out first before running the first test so you can see if there is a file being stored in your cookies for the IP you are using. If there isn't a persistent cookie file being stored (and I'm thinking there probably isn't), then this is a session based cookie and you won't be able to just clear it out every time manually (because the only way I could think to clear a session cookie would be to close LabVIEW like you are doing).
Another option is to just re-request the page on this failure? Since the error page is "logging you out" via Javascript by clearing this cookie's content, wouldn't a simple retry work just like the login to the first unit?
And yet another option is to disable cookies altogether in the security settings of your OS and see if there is a failback method that the unit uses for login...
I hate cookies...
-
QUOTE (jaegen @ Apr 4 2008, 10:39 AM)
There's something wonderful about the fact that the link to the "Bug Fixes" page is currently broken. :thumbup:Here's the LV8.5.1 readme.html from the install directory (no...I haven't installed it yet)
-
Thanks for contributing!
Another way of accomplishing this came to mind, IMHO a little easier to read and less logic to follow:
Download File:post-3266-1207328615.vi
Just as a tip, it's generally a good idea to keep all inputs/outputs outside of the structure so you view them at a glance.
-
QUOTE (raptonx @ Apr 3 2008, 06:17 PM)
Search for "System Exec" in the http://zone.ni.com/reference/en-XX/help/371361D-01/glang/system_exec/' target="_blank">LabVIEW Help.
-
-
To add another piece of old documentation to the mix, take a look at this under "SubVI Overhead":
QUOTE
When you call a subVI, there is a certain amount of overhead associated with the call. This overhead is fairly small (onthe order of tens of microseconds), especially in comparison to I/O overhead and display overhead, which can range
from milliseconds to tens of milliseconds.
However, this overhead can add up in some cases. For example, if you call a subVI 10,000 times in a loop, this overhead
might take up a significant amount of time. In this case, you might want to consider whether the loop can be embedded
in the subVI.
Another option is to turn certain subVIs into subroutines (using the VI Setup Priority item). When a VI is marked as
a subroutine, the execution system minimizes the overhead to call a subVI. There are a few trade-offs, however.
Subroutines cannot display front panel data (LabVIEW does not copy data from or to the front panel controls of
subroutines), they cannot contain timing or dialog box functions, and they do not multitask with other VIs. Subroutines
are short, frequently executed tasks and are generally most appropriate when used with VIs that do not require user
interaction.
-
QUOTE (TiT @ Apr 2 2008, 06:26 AM)
Looking at this and this, I found:
QUOTE (TiT @ Apr 2 2008, 06:26 AM)
- Anyone ever tunerd it on ?I've tried to turn the "anxiousMemoryDeallocation" option on several times, but I would always get all sweaty and shaky...then I'd forget to save the changes, so no. :laugh:
-
-
I know exactly how
feels. -
The way it started was rather Pythonic, I kept waiting for the Giant Foot to come down and crush it...
When the guy kicked it was my favorite part. Almost too realistic movements...
-
I played around with this and was partially successful, but wasn't able to get it to work quite right as you can see by the end of the thread.
-
-
-
-
So I have to ask... if it isn't needed after activation, then why is it running as a service? Is there any stuff that we should be aware of that it does in the "background" before I turn it off on all my dev boxes (I can't stand processes that hang around for no reason...)?
-
QUOTE (Yen @ Mar 29 2008, 12:14 PM)
That's interesting, since Google claims that black is the same as white when it comes to power consumption on modern day monitors. They just "turned the lights out" so people would take notice of the "Earth Hour" tonight.
-
QUOTE (pallen @ Mar 28 2008, 07:45 AM)
http://www.piclens.com' rel='nofollow' target="_blank">PicLens: PicLens instantly transforms your browser into a full-screen, 3D experience for viewing images on the web.I really like this one. I was amazed at how well they integrated it into the image search sites, and how fast/smooth it is.
-
Bruce,
I had problems with a project that I upgraded from 8.2 to 8.5. Initially it worked great, but then I opened up a typedef cluster to edit it and LabVIEW crashed. Subsequent tries to open the VI that contained the typedef hung LabVIEW. I cannot remember if I had problems opening up the project itself, but I feel your pain.
In my case, the problem turned out to not be in the control I was editing at all. It turned out that there was an element of that cluster that linked to another cluster that had a typedefed reference to a graph that was causing the issue. (yeah...)
The way I solved this was to create a folder outside of the search path, and do a kind of binary search. I took half of my folders in the project directory and moved them away, then tried to open the VI. If it crashed immediately, I restored the folders and took the other half away. I did this until I was down to a few Typedefs, and eventually found the one that was choking LabVIEW. Recreating this control and re-linking my VI's solved the crashes.
With this and another example that one of my colleagues showed me, I am almost 100% convinced that older 8.x versions sometimes let linking errors slip by, and LV8.5 is better at preventing this...if you start with 8.5. Converting over to 8.5 can be painful if you have linking errors already existing in an older version of 8.x.
This may or may not help, it's just based on my observations so far. Good luck!
-
-
QUOTE (JFM @ Mar 27 2008, 07:13 AM)
1. Turn cluster array into a boolean cluster array by checking equality2. Filter the active element by performing an AND operation
3. Search for the desired boolean cluster pattern
That is genius. Thanks! I was trying to work out some sort of masking algorithm, but wasn't successful without some serious hack. Your way is slick!
-
QUOTE (Jim Kring @ Mar 26 2008, 08:12 AM)
Hankey SanYeah, his "Weeeeee!" cry in the video is burned into my brain somehow... that and the "What time is it when..." questions.
This morning I heard "My MAX config is messed up" from across the room. Sure enough, immediately in my head...."What time is it when your MAX is messed up...?"
Ma, Ma, MAX man!
Please, someone post something catchy so I can dump this. Oh man...even that sounded wrong. :headbang:
-
-
This clip wouldn't have made me laugh so hard if I hadn't been through the "hooray for poo-poo" phase with my daughter myself.
LOL...and scared that I am
PCIe via Call Library Function Node
in Linux
Posted
QUOTE (TobyD @ Apr 4 2008, 12:34 PM)
My suspicion was it was some equivelant to "bump", since there wasn't a response yet. Either that or More Draft -- Edelweiss!