ShaunR

I'm not sure if it is that easy. I am pretty sure the web page must be hosted as a static document in the web service. Most modern browsers (Firefox, Chrome, and maybe IE) prevent cross-server requests, which have the potential to be dangerous. I would start by making a hello world HTML document then staticly adding it by following these directions http://zone.ni.com/r...tatic_content/.

Then you can use ShaunR's information. If you really want to do an AJAX call simply I would look over jquery library. That is how I learned basic web page development.

I cannot read that document at the moment - NI down again (might have read it in the past though). But from experience, most uses of the NI web server are to make VIs available internally within a company (managers and engineers looking at production etc - Intranet). therefore x-server really isn't an issue. When/if external access is required, usually IT insist that any requests are routed through their main servers anyway, so the browser requests it from a page on the corporate site and the request to the NI web server is sent from the corporate site. So the content seem to come from the same (corporate site) domain as far as the web browser is concerned..

+1 on can't upload.

Couldn't upload a VI (64K) and a snippet. Just said "the upload failed". (Tried in Chrome, IE and firefox-no dice).

To add another layer of complexity, we usually use the registry for product application settings

Making excellent use of LabVIEWs x-platform capabilities then

I have written an app for a client and included a couple web services to pull some data. Works great.

I was wondering how difficult it is to design a simple web page that can take advantage of the web services; Specifically, how hard is it to have the user click a form button, have that call the web service and then pull data out of a specific XML field and update the page? I know this could get pretty involved, but basically I was hoping to write a simple web page with a table and update values in the table from the web service; I was hoping NOT to have to do this down at the labview level- although that might be what I have to do.

-jed

Easier than you might think.

Just attach the updateData to a button Onclick event.

Make JG Dance For You

Windmill and kick is my favourite

An interesting API was recently discussed with me. Apparently you can use the ActiveX/.NET register event node to register standard LabVIEW UI events (through UI refnum). Why might this be interesting you might ask? Well for a long time I have thought that the deviation between queues/event structure was unneeded. This suspicion was reinforced when the topic came up in the CLA summit. The queue and the event structure have a lot of overlap. The question is should the two implementations be merged?

I've talked with some who think that the event structure is more data flow oriented, but I am not entirely convinced.

Just so you can test it, here is some example code I posted to benchmark the callback API (ActiveX/.NET) and the dynamic event mechanism

It depends on what you mean by "merged". I use named queues rather than a named types which means that (amongst other things) I can send a string across the network and dynamically create a queue with that name at the other end.. I can't think of a way (off the top of my head) that I could easily do that with events. But generally. I think queues are easier to use since you just grab a reference by the name from any module without having to run wires or store the ref in a globally accessible storage. But apart from that. Yup. they are pretty similar (maybe because events use a queue?).

Interesting to note that there is about 20% a difference in performance though (although I haven't looked closely at the test method)..

Are using the "Base Package"?

I tried the conditional disable structure and I'm not getting the behavior I was expecting. I'm running LabVIEW 2010 SP1 (32bit) on my laptop which has Window7 Pro 64bit installed on it. I setup the conditional disable as suggested in a test VI. If I execute the VI, it is always selecting the 32 bit code in the structure. Is there something obvious I'm doing wrong or missing?

IC.

The conditional disable will give you the bitness of Labview you are using.

For the OS you can use the OS.Name property node.

I'm trying to determine if my application is running on a 32 or 64bit version of Windows. The application is going to be calling some external code (.exe) which has two separate versions depending on which OS they're running on. There is a very nice .NET method available which would work perfectly:

http://msdn.microsof...8VS.100%29.aspx

but it's only supported in .NET 4.0 which as of LabVIEW 2010 SP1 we don't have access to. I could try to write an external dll to do the check for me, but I wanted to see if anyone out there had an idea of how to do this from within LabVIEW.

Thanks,

Keith

The "Conditional disable" has pre-defined conditions for different OSs (bitness is one of them).

Hi, I supposed to say that the given logic wold not work. I did not check with the device though i would like to send always addresses from 0 to 127. After the logic shift this value is chnaging to some other value and i guess this make some difference.

You can see in the below attchment for packet structure. LSB isalwyas for indicating Read/write operation. Why really logic shift is there in the given example. I did not undestand. weather it acts like what i ecpected..

When you manipulate an integer it is always based from bit 0 i.e integer 1 = 00000001 (2^8 = 256 possible addresses). But that bit (LSB , bit 0)is used as a read/write flag. So Address 1 = 00000010 (integer 2 for a read) or 00000011 (Integer 3 for a write). Therefore the address is shifted by 1 bit and you are only using the top 7 bits (2^7 = 128 possible addresses) You can then OR your read/write flag into bit 0.

If you were to send a U8 with the value of 1, you would in fact saying "write to Address 0". Sending. Integer 2 would be "read from address 1". and Integer 3 would be "write to address 1 etc.

U8 (0) = 0000000 0 = read from address 0

U8 (1) = 0000000 1 = write to address 0

U8 (2) = 0000001 0 = read from address 1

U9 (3) = 0000001 1 = write to address 1

I think warnings are a double edged sword. For example. How many people turn off warnings on the LabVIEW error dialogue unless you are optimising? I prefer prioritised errors since the default Labview handling for errors will pop-up dialogues which then forces you to consider the seriousness of the error. It also enables you to do things like graceful degradation. Warnings, however, don't really give you much apart from the headache of documentation explaining what it means..

Hello Shaun,

That sounds like the nugget of information I need. Is windows indexing something I can turn off from within LabView? Please can you expand, I'm afraid I don't know what it is.

Thank you,

Martin

I wish I could find stuff on LAVA. I've commented many time before..but here we go again.

Windows indexing is the windows search service (so no, you can't turn it off in LabVIEW AFAIK). It periodically runs through the system acquiring locks on files, reading its contents (so you can search contents), and building up it's quick search database. I've been bitten many times in the past by getting file errors at seemingly random intervals and it's a killer on logging apps. I now routinely disable it and have not been bitten by random file errors since (only my own faux pas - but I can debug those )

How to turn it off

Try turning it off and see if your problem goes away.

Hello everyone,

<snip>

Martin

If you are running under windows, turn off windows ndexing.

I've done splash screens before, but they've not really served a purpose other than branding so their implementation really didn't matter from a performance perspective.

Now I have an application which seems to take quite a bit of long time to load up, to the point where users regularly wonder, "Hmm, did I actually double click that? Better try again." More than once I've been right next to the person and told them, "No just be patient, it will show up." only to watch them try again and again to click that darned icon. Well at least I haven't set allowmultipleinstances=true in the ini file. Yet.

I know there will be a constant time as the LabVIEW RTE spins up which is independent of the actual executable I create in LabVIEW. But does the size of my executable also affect load times? I'm under the impression that the whole thing must load, so if it's larger a splash screen can't be shown either way until the entire application has been loaded into memory. I might be wrong here. My current application is at 44 MB, this doesn't seem too large to me...

Has anyone played around with dynamically loading their core application logic from outside of the executable to see if that reduced time to display a splash screen? I figure the best way to do this is have the bulk of my code in a LabVIEW built DLL, then have a shell of a LabVIEW exe display the splash screen and proceed to take its time loading the DLL, after which the splash screen hides itself? The DLL will not be statically linked, a path will be built to it at run time. Or is this road fraught with peril? I've never actually built a DLL in LabVIEW, this might be interesting.

From my experience it's not so much the size of the file. It's the size of the hierarchy. If you have 1 VI that is 44MB it will load a lot faster than 10,000 VIs @44MB. Although I would want to debug the former . A splash screen means that you only have a very small hierarchy to load before you can display something. It also gives you the opportunity to "incrementally" load you application For example, you may have a "hardware check". In running that, you have loaded quite a few VIs that you probably use in the main app (and done something useful) without having to wait for the whole app to load.

Please, repost the last example VI in 8.5 version. So that i can see the given example..

Well. It's the same as the image ....but

If it's your dialogue. Why not just bypass it completely or put a switch in to disable dialogues (maybe log it to a file instead).

If it's not your dialogue (i.e in another application) then there are some suggestions here.

No, its difficult for me make it in expexted way. You can see in my code, first event case, I am writing all the addresses to serial device from 0 to 127 because it represents 7 bit address and the LSB bit should be read bit or write bit whicjh i did not sending now.

Like this?

I would think twice before generalizing like that. User events are at the top of my list and many others I've talked to, when it comes to inter-process communication.

Probably is if you are talking to architects and experienced clds. But "most" labview programmers aren't and the limit of IPC conversations tends to go as far as a producer consumer loop with queues and that's about it.. I've yet to see a student, electrical or electronics engineer (LabVIEW is still seen as a secondary skill in many companies eyes) talk about IPC and messaging systems. And I've worked, and interviewed many.

Also, using the timeout frame is a common use-case for reading other data that needs polling or other updates between events.

And those are exactly the apps that can fall fowl of this "feature".

In fact, at the CLA summit, there were many requests by other CLAs to extend the capabilities of the Event Structure even further, since handling user events is simply not enough.

I've commented many times about how I feel that events have been neglected. So you are preaching to he the converted here.

Even though, at the end of the day, I'd really like NI to find a solution to this problem which allows me to register for events all willy nilly-like and only selectively create cases to handle them - my gut tells me that, If I I don't need to react on an event then I shouldn't really be registering for it in the first place, should I. For now, I would chalk it up to: "Hey, I just learned something cool and I really should spread the word about this 'best practice' to my colleagues and warn them about it." Education is important.

Well. Actually, in the strictest sense, Events shouldn't have a timeout at all. An event is either signalled or is not not. No other language I know of has event time-outs and if a programmer wants to time-out if no event is received within a time-frame, then he has to create a timer that gets reset when an event fires. This is probably why the event case is as it is. The windows forms message callback (Wndproc) just has a timer that gets kicked on entry.

As for not registering unless you need to react. that is only applicable at design time. What if you have configurable alarms? You will still need all the cases on the off-chance that a user will want to register it and receive feedback. thats one of the more useful (but rarely seen in LabVIEW) uses for events.

Unfortunately, I don't think it is "cool". At best it's unexpected behaviour and explains (IMO) a lot about problems people have seen with xControls.

Oh, I'm not saying that it's counterintuative - it totally is, until you stop and thinking about what's going on. That can be said for several things in LabVIEW (remember the first time you branched a by-reference wire and couldn't fathom why the data "on" the other wire was changing?)

Maybe there should be an option to unset this should be available (like an "allow unhandled events to be registered" checkbox in the event dialog if the dynamic event handles are shown). That said, I'm sure AQ will agree that it's a little more complicated than just adding a chekcbox

I would actually categorise it as "unexpected behaviour". If it is a bug or not then depends on whether it was specifically designed to not timeout under certain circumstances. My guess is it wasn't considered and "most" developers would want a time-out to, well, time-out

I guess the good news from this is (for me) - if its taken this long for this issue to be identified (LabVIEW 6.1 to present) then it must not have cropped up much (if not at all) before (granted, we could be using the event structure differently now).

I think it's probably because most people only use the event case for the UI (and generally wire -1 to it). And only a few are brave enough to base a whole inter-process messaging system purely on events.So if anyone is going to find it....it's you

I'm in on the Justin and JG bandwagon. (not very crowded yet )

Doesn't anyone else think that a "timeout" that can never time out is in the least bit strange in concept?

Sure you can find a use case for it. But I bet there is far more instances of head-scratching and cries of WTF. On the shoot yourself in the foot scale of 1-10. It's a bit of an 11. It's also one of those "issues" that you come across from time to time where the whole app just doesn't work, but when you try to debug. Everything works fine in isolation (or if you slow it down).

Well, the DLL has to be the correct one for the actual LabVIEW platform of course. But since OpenG ZLIB is distributed as OpenG package, the package installer can make sure that the correct DLL is installed depending on the current LabVIEW version and platform. But what I want to avoid is any platform specific settings in the VI interfaces to the DLL. That would make distribution and maintenance of the library rather more complicated. I don't have a seperate wrapper DLL but have combined all the code (zlib, minizip, and wrapper code) into one library. This library is compiled into whatever platform shared library format is required including Win32, (Win64 hopefully soon), Mac OSX, Linux, and VxWorks 6.1 and 6.3. All of them are included in the ogp, with the MacOS X shared library being zipped up first to avoid loosing the resource fork of the files, and then the OGPM or the VIPM takes care to install the one that is required for the current LabVIEW version the package is installed into (and unzips the library through a custom post install step in the package for the MacOS X plaform). All the VIs and other help files are supposed to be platform independent and stay that way if possible at all. And the wrapper code is where I have spend some time in to make that independence happen.

And the delivery takes a little longer since I went for a Dell Latitude machine. Also there are company internal delivery paths that add some time to this too .

IC.

I thought I was missing a trick That's a lot of work - Kudos for even considering it.

I took the decision a while ago to cater for cross platform in Labview rather than support my own wrappers or modifying pre-tested API source. I figured that platforms change rarely, but dlls change often. If I just interface directly to the DLL from LabVIEW I could also take advantage of tested, pre-compiled binaries from the developers and just download and overwrite. But I am not as comfortable in C as you are. I also don't have to contend with backward compatibility to LabVIEW versions from 10 aeons ago (when there were no things like "pointer-sized" int). But presumably that could be worked around with the package builder too.

I think there are a lot of people lurking on this thread waiting to pounce once you announce a 64 bit version.

Thanks Shaun. This was also stated in entry #2.

You don't expect me to read threads do you?

Apologies. He's all yours

Also......

you need to put the boolean control terminals inside of the case for that control otherwise when you press them they will not pop back to thier FALSE state.

e.g

The zlib library is most likely not a problem. I have used the latest source code too. It's either an oversight in the Call Library Node configuration since I attempted to make the wrapper functions so that they will work in 32 bit and 64 bit without modifications to the VIs or something in the wrapper code that goes wrong. I'll take a look at it when I have installed the new machine.

As far as I'm aware, lv can only load a dll of the correct bitness so I envisaged at least 2 zwrapper dlls (one x32 & one x64 if you stayed with an intermediary) even if you managed to thunk down to a single 32 bit zlib (expecting 4 dlls in total though). There's obviously a trick I'm missing and can't wait to see the solution. PC on next day delivery?

Well I'm soon going to get a new machine and it will most likely come with Windows 7 installed (not really happy about this but I probably have to bite the bullet at some point). One advantage will be that it is going to be 64bit and therefore I can do some debugging of my own. My first dry exercise with just compiling a 64 bit DLL, did crash on Jim's computer, so there must be something still wrong with the DLL.

Is it the wrapper dll or the zlib dll thats crashing?.

I've have a zlib dll that I'm using successfully in LVx64 if that's what is causing you problems. I'm not using it for zip files as I'm currently using the LV shipped ones (although it is compiled with the minizip 64 bit functons - not sure if you use them or not ). It passes all the zlib and minizip tests and labview isn't complaining (or dying) when compressing buffers.

Anyhoo. I'm attaching it in the hope it might save you a bit of time.