Community Nugget 1/29/2007

[tst]

---

@Jim Kring wrote:
I'm pretty sure that that MgErr Occur(Occurrence occ) function is equvalent to the Set Occurrence primitive. 

---

That would make sense. Maybe I should have checked the palette first to see what the available primitives are, but I wasn't really thinking.

[Chris_Co]

Holy BEEP batman that just BEEP BEEP BEEP!

I think I felt my brain explode when this boulder rolled over me.   I think I might quit programming. You's talk of such high level subject matter like most normal people talk about the type of coffee they like.

Now if you'll excuse me I'm going to drink till I puke.

Ben, I have earmarked this "boulder" so when I grow up I can understand it!  But I think it's going to be great.  Great work!

[Ben]

LOL Chris!

I was hoping to achieve that effect and hopfully get a "kick in the head" myself (as was provided by everyone's replies, Thanks Jim!).

Scott,

We are not ignoring you. As usual you are out there on the borders of LV-Land exploring and feeding back to the more timid.

I have not had that much experience using User Events beyond some toying and in a DSC application where I needed to detect changes in PLC registers. In that application our initial implementation, we had a seperate VI for each PLC. Testing showed rather sluggish response, so we merged all of the DSC events into a single VI and used queues to distribute the updates. After that change we still had sluggish response and eventually chased it down to an OPC setting. We never went back to the original scheme, so I can't comment on that from experience.

Beyond that....

In the special case we are talkinag about "single source of trigger - single reciever", I too am curious about the advisabilty of one method over the other.

Speculation:

Do the User Events run in the UI thread?

I have a feeling that the Occurrence mechanism may be involved in all of the other sync functions.

Occurrence can have multiple recievers. On the other hand multiple events structures looking for the same event are supposed to be bad mojo.

These are just my thought.

Can anyone "pull the curtain back" a little more?

Ben

[Ray.R]

this boulder is growing bigger by the minute..

this is a hard act to follow!!!

[Ben]

Ray wrote;

"

this boulder is growing bigger by the minute..

this is a hard act to follow!!!

"

Maybe I should have called it a LabVIEW Snow-ball instead of a Nugget.

It should not be that hard to follow. Judging by Chris' comment (which I loved) a smaller Nugget may be called for next time just to reset the brain. Besides, tst has hinted at doing the next Nugget and I am sure he is capable of following any act (that does not involve animals*   ).

Ben

* I believe it was George Burns who said he could follow any act provided animals were not involved.

[tst]

---

@Ben wrote:

Do the User Events run in the UI thread?

Occurrence can have multiple recievers. On the other hand multiple events structures looking for the same event are supposed to be bad mojo.

...

Can anyone "pull the curtain back" a little more?

---

An event structure will respond to all the events it registered to, regardless of whether they happened before it started running or what other event structures are doing with them. The attached should demonstrate this (just change the boolean and see how the i terminal is incemented even if the boolean was changed before the loop started running) and I believe this should be the same with user events. 
The main problems in using multiple event structure are debugging difficulties and potential lockouts due to the Lock Front Panel option or due to nested event structures.

As for running in the UI, I'm fairly sure that only the event detection runs in the UI thread and that the actual event code runs in the normal thread and if I remember correctly there was a fairly lengthy thread about this (maybe the one where there was a problem with the latching action?). I don't know how user events do this, but it might be the same mechanism.

As for other synchronizing functions using the occurence functions, my guess would be no more than yours.

P.S. Yes, I believe that my nugget will not generate 4 pages of replies (although it has in it the potential for another nugget which will).

[tst]

Forgot the attachemnt, of course.

[Ben]

THis mod of your example pushes the events by using somewhere around a 150 to recieve the events with four of the events firing the event when they get the event.

While the recievers are running the transmitters are running a 1/4 the rate of the recievers.

Once threcievers stop the trnamitter loop rate jumps up.

This implies to me that every thing is standing in line for a single resource. UI thread, I don't know.

Ben

Excuse the code. It was expedient.

WARNING: THe attached is huge 1.6M

Message Edited by Ben on 02-04-2007 11:09 AM

[tst]

This actually shows you that the event code does NOT run in the UI thread. The four on the left have their code running in the UI thread because you're using the signaling property, which forces a switch, but all the loops on the right are running perfectly normal.

P.S. Your case is a definite example of the problematic nature of using multiple event structures. Your signaling event is recieved by all event structures (including the ones generating it) and I'm surprised that they don't reinforce each other into hell and make LV go mad.

[rolfk]

---

@Tomi M wrote:

This is very good point, I didn't think of either. I took a look. lvrt.dll has also these functions. I created an executable application with LabVIEW 8.20 and it still worked ok when I renamed the LabVIEW.exe to LabVIEW.bak. So the application didn't rely on the LabVIEW.exe, at least not the LV 8.20 version of it. It seems that lvrt.dll provides the same C API that LabVIEW.exe, at least under Windows XP and LV 8.20.

Tomi

---

Well, I'm just coming back from a major surgery and am still revalidating when I saw this nice discussion that I seemed to have missed completely 😉

Yes the executable (LabVIEW runtime engine DLL) under Windows provides this C API too. However it does not export all functions the Development System does since some of it simply doesn't exist in the runtime environment.

And before someone wants to know about how I came to know all these things. Mostly it is about lots and lots of trial and error and a few friendly tips of some NI guys. The particular prototypes for the Occurrence API I actually found in the original extcode.h file that was distributed with LabVIEW 2.5. This was a several 100k header file that showed (documented would be a bit of an overstatement) the prototypes of all exported LabVIEW manager functions at that time. Most of them seem still available in LabVIEW and probably haven't changed to much but no guarantee for this of course. With LabVIEW 3.0 NI decided to document the manager API partially in the External Code Reference Manual and remove all references to functions not in that manual from extcode.h.

This first extcode.h file also shows some signs of an interface that allowed creation of C style custom controls and the device driver interface that serpdrv was using in a similar way to CINs. This C style custom control interface seemed to have been removed in LabVIEW 4 without any replacement probably since the static method table of those objects gave to much trouble to be kept compatible among different LabVIEW versions.

Rolf Kalbermatter