PeterB

@Ravi Beniwal, I have the same problem, VIPM reports that missing dependency for me too. If it isn't required could it be removed ? If it is required could it be included ? I suspect it is included in version 1.7.028 which does not report the error. I spent(wasted !) time looking for the dependency and downloading it, only to realise it might not be needed as it launches OK from the LV IDE menu Tools\LabVIEW Task Maanger.... Peter

Thanks. meaning changes in the file permission (chmod/file mode) could get flagged as changes by Git unless you configure Git as per your advice.

Ah, thank you very much ! I am glad to know this reason. It means it is unlikely to be something fundamentally wrong with the way I am using the tools, but instead that during development, code is being flagged as changed by LabVIEW (asterisk next to filename I presume), even though the programmer has not done any obvious change. One thing I can think of might be the conversion from a different LabVIEW version. That is one request I could add to the Ideas Exchange, for LabVIEW to either ignore differences that results in "0 differences" being reported, or to actually report it in a sensible way like "vi converted from different version of LabVIEW". I agree now that it isn't a falsely reported difference (which I'd call a bug in IDE), just that LabVIEW doesn't want to tell you what the difference is !!

Perhaps I'll ask a higher level question. For those of you who use source code control and perform comparisons between different commits, how often would LabVIEW falsely report differences exist ? Here is what it looks like when I double click on vi having a claimed difference:

Hi folks, I have been using TortoiseGit + Bitbucket for SCC for the past year and I have become rather frustrated with a recurring problem that I simply cannot find evidence of others experiencing. For that reason I am convinced I am doing something wrong in my workflow but IDK what. TortoiseGit flags changes to some files but when I use LabVIEW to do the diff/compare it finds no changes at all. The file sizes of the falsely flagged files are unchanged, but the CRCs are changed. (inspected the binary difference below). Before committing the changes I do a mass compile as NI suggested to me that might be the cause. At one time that seemed to help, but not now. Also I can confirm I have enabled the separation of source and compiled code in each vi and in the project. WHY does this happen ? Here are examples of file names and sizes that are unchanged (but falsely flagged as changed by TortoiseGit): Interpolate Magnitude (3 pts).vi | Bin 14665 -> 14665 bytes Order Magnitude from FFT [dB].vi | Bin 13741 -> 13741 bytes Peak Find 3 pts.vi | Bin 21587 -> 21587 bytes Vector Sum [linear].vi | Bin 12555 -> 12555 bytes and one file changed which was truly flagged as a changed (note filesize diff) Amendments.vi | Bin 54814 -> 54786 bytes In one of the above files, below you can see the binary difference of 5 bytes occurs just prior to the first revision history comment, however no changes at all are found in all the history comments nor in the LabVIEW compare. I spotted a similar kind of change (same location) in a 2nd file I looked at.

I came across this limitation as I am attempting to convert the Type Sensitive Popup to an XControl. The Dynamically registered user event to update the contents of the original cell is delayed until the next event is serviced. I've given kudos to the relevant idea here on IE requesting LV change its behaviour.

OK thanks for clarifying Val. Also, just to be clear, up until now I've not claimed, nor do I want to claim that the ESSM+VSB should NEVER be used, just that it is not a design that should be put forth as a contender for a template upon which many small and large programs will be written at my company. We are only settling on one template for now. In 6 months time we might add another one to the mix. I'd like to think that by the time we get to template number 8,9 or 10 that the ESSM+VSB stands a chance because of the few times it would be useful. rgds

Thanks everyone else for your replies. Before I address each one individually if others have additional reasons they would avoid using this architecture please feel free to chime in. With the supposed performance issue not being demonstratable under typical worst case scenarios I have kind of lost my one big CON to throw against it. so it might just have to be a lot of smaller CONs now which will support my/our bias against the architecture. Tim, it might well come down to declaring this a demonic design and casting it out, but until that point I want to gather as much objective and subjective evidence as possible to counter it so I can be fair to the person pushing really hard to have it accepted. Ned, good point about being unable to manipulate the event queue. that seems to be a common thread/CON with this architecture as I pointed out to Dave. Jason, thanks for your vote for queues rather than event structures to send messages. I think I might set up a LAVA poll. Your replies to date will help me form unbiased questions. Val, being harder to follow the code is definitely a CON as it needs to be easy for beginners to understand and anybody to maintain. I gather that the main reason it is hard to follow if the use of Global Variables which aren't strictly necessary to use for this architecture. regards

Dave, thanks for taking the time to look at this and code up something for me to try out. I just tried programatically firing off 1000 UI events in a for loop, but it didn't upset things at all. Even if it did, such a scenario would be a highly unusual use case. When I mean "moving the window around having an effect ", I am referring to the graphs and LEDs not updating smoothly. I have seen them jitter and stall as I move around the Main FP. This is not just a cosmetic problem, it is also affecting the time it takes to complete each state. Your changes were successful in demonstrating how injecting an arbitrary state affects the order of execution of the other states which is also a problem with QSMs but can be salvaged by flushing a QSM's queue. That is one more CON for this architecture, thanks for pointing that out. (I had only considered the example of wanting to enqueue an error state to the very front then being unable to flush the remaining enqueued states, but you bring up a generic problem - thanks) The other problem you tried to point out unfortunately (for my case) is not really a problem. It is true that the FP is unresponsive to user input after Restart is pressed - but this is caused by the Graph Update state (and possibly the other new states you added) having the "Lock front panel (defer processing of user actions) until this event case completes" checked. That is the default setting and needs to be unchecked for this architecture for it to have at least any hope of being useful. I think you make a great point here. I was surprised that sending so many UI events didn't hammer the UI thread. It only hammers it if one simultaneously displays all the LEDs for each of the states being entered into. In fact a prior version I achieved this by firing off 8 states in the Main top level vi from parallel vi's , and only when those 8 state LEDs were visible did it saturate one of my 4 cores on the CPU.

Here it is Tim. Have a play around with changing the control labelled "State Change Delay [ms]" (which pops up when you run it) and see how it can't keep up for lower delay values. Globals are used generously much to my distaste, but it was primarily what was given to me and I then had to distil it in a short amount of time. Just a reminder to you and others. My goal is to throw situations at this architecture which prove it is poor from an objective standpoint. I want to show how loading up the UI thread with events will prove detrimental under any conceivable situation. (e.g. FP refreshes being less responsive, especially when that FP is moved around) I revise my last claims in that it starts becoming less responsive for total rates of 200Hz (rather than about 1.5kHz), but not noticeably so, only because the metric I've included (time drift [ms]) indicates this. The total event firing rate of the 20 parallel sub vis (which I neither calculated nor displayed programatically) is simply = (20000/State Change Delay [ms]). ESSM+VSB Folder.zip regards

Tim, I'll post it tomorrow from work. I'm pretty sure the ESSM+VSB will never be likened to the humble, red, juicy and appealing tomato. More likethe green kind which is toxic in large amounts. rgds

Possibly, but I think you will find it is also the BIAS of many other seasoned LV programmers too. Is it possible so many are all objectively wrong ?? Have we been told lies by our learned forefathers about staying out of the UI thread unless necessary ? I dare a seasoned LV programmer to step up and support the notion of an ESSM+VSB !! (to the point they would use that as the default template in their next major project.). I would be very surprised if we would get more than 5% of experienced LV programmers seriously supporting it. I'm happy to be proven wrong, but if something has such an opposition to it, I don't want to let it become a template at my work. mross wrote "That is crazy talk what he did with the LED indicators. " here is a list of CONs I came up with. A few are objectively measureable. rgds

Yes, I hoped it would choke at realistic rates of a few hundred Hz because I am trying to show somebody here at work how much of a bad idea it is. I am openly and subjectively biased against the idea of using Value Signalling Booleans to change states in an event structure. (my preference would be to get them to use User Events, but they think those aren't simple enough for a new LV programmer to understand - bah!) Using VSB in this fashion goes against so much of what I have learned about LV (i.e. that it is important to reserve the UI for UI stuff) that I'm sure it must be a bad idea. It is my job to convince another person where I work that it really is a bad idea using objective measures otherwise I have less legs to stand on as I oppose his efforts to use this in a template/design pattern for many of our future projects. Surely I'm not the only seasoned LV programmer for which this template rubs them up the wrong way !! Help me out here guys, I need ammunition to oppose this evil idea..... rgds

Thanks Kugr, I already pointed that out in my post when I wrote "(note that code in an ES state doesn't necessarily run in the UI thread, but the act of changing to a new state (ed. via VSB) causes a switch to the UI thread)". BTW I'd still appreciate any more major cons or coding ideas to throw against this ESSM+VSB proposal. My attempts to run 10 ESSM+VSB in parallel with their states changing every 10ms (for a total of 1kHz) didn't choke the UI thread. It took about 15-20 running in parallel at a total of 1.5kH-2kHz to saturate the UI thread. So, I guess if one assumes a safety buffer of 50% (1kHz*150%=1.5kHz) , then 1kHz is the upper limit for running such an architecture, but I had hoped it would be more down in the hundreds of Hz (i.e. a total of hundreds of state changes per second across the entire application) which is more of a realistic use case for a large application. regards

I'm reviving this thread to ask for ideas on how I can prove that using an Event Structure as State Machine (ESSM) using Value Signalling of Booleans (VSB) to change states is a bad idea using objective evidence. Ideally I'm after ideas that I can code up in LV which show how an ESMM+VSB saturates one core on a CPU (making the FP unresponsive to user interaction). Its performance is then to be compared to an alternative architecture such as a Queued State Machine. All comparative tests to be run at say 1kHz in order to give a worst case scenario. One can easily achieve 1kHz by running 10 loops in parallel at 10ms loop time each, where each loop sets the value signalling property of a different boolean on the FP. I did this test at 1kHz and it surprised me when the UI was still responsive to my mouse presses. I had one idea while I was typing this up. I am going to run say 10 of these ESSM+VSB in parallel sub-vi's to see how problematic it is. Up until now I only had just one ESSM+VSB and was trying to break it at 1kHz. Rather than show you the code right now, can you come up with an idea for me to try along these lines ? My agenda is to discredit the idea of an ESSM+VSB because there are many reasons I don't like it, and I am declaring my bias against it. The reason I'm seeking this evidence is that I am being asked by my colleague to demonstrate using objective evidence why it is an unsuitable architecture to employ before enshrining it into a template/design pattern here at work for any size (small and large) project . Here is my list of Cons: Changing states causes a context switch into the UI thread. ("so ?" comes the reply to my concern, "LV is efficient enough and today's CPUs fast enough to cope with this" !). My counter to this is in the next point. The UI thread(s?) only run on one core, and processor speeds aren't increasing much these days, but the # of cores are. So with many of these ESSMs running in a program (in multiple parallel tasks all in sub-vis) , the UI thread will get hammered and saturated, having no option to offload to the other cores. (note that code in an ES state doesn't necessarily run in the UI thread, but the act of changing to a new state causes a switch to the UI thread) Parallel programming is therefore discouraged as eventually the state changing requests will saturate the UI thread(s?) It looks unprofessional to have your FP/GUI activity (i.e. graphs/leds/text etc) stammer/freeeze/get jerky when one moves ANY window on the desktop. One can't probe states queued into the Event Structure (ES) prior to each state being transitioned to. Upon an error condition, to prevent already queued states from executing one must have a case structure in every event case to bypass code on error because one can't enqueue an Error State at the front of the ES queue and then flush the remaining queued states. rgds

Hi Norm, that is great news. Thanks for following up on this and I look forward to what you can provide in a couple of weeks' time.

Hi Norm, after reading as much as I can here on LAVA and from last year's NI Week presentation on the JKI vs TLB SMs, I appreciate and would like to thank you all the work you have been doing on the TLB and LVx up until now. I work at ResMed where I've been championing LabVIEW now for 8.5 years. I've actually been using and loving LV since '94 to be precise. For my last major project I used ExpressionFlow's QSM. A colleague and I at ResMed are having our own little head to head as we standardise on a State Machine architecture which satisfies many interesting and competing requirements. My colleague has already warmed to the JKI SM to support his own template efforts to date however I am really keen to put forth the TLB + LVx as a worthy contender. If necessary I will teach myself how to use LVx should your examples/documentation not be ready, BUT just in case your efforts to remove that black mark are close to being finished I thought I'd first check here with you. Any ETA you have in mind ? Don't worry I won't hold you to it. In the mean time I'm struggling to find the latest posted version of LVx. This version of LVx is dated Feb 2008 - like 3.3 years ago now !!! Do I also need to request some behind the scenes, off-the-record , skunk-works release of LVx as you offered Dave ? happy wire working. regards Peter

I had the exact same error message. I solved it by re-building the installer and reinstalling the executable rather than just manually copying the EXE from the build output to the program file DIR. rgds Peter Badcock Product Development ResMed Ltd

El_Frito, Unfortunately NI haven't properly implemented the marshalling code required to pass a reference to a .NET object into LabVIEW land. Refer to this post which summarises things. Adam Kemp is raising a CAR for it. rgds Peter Badcock Product Development ResMed Ltd

Casey, Thanks for your valuable feedback. regards Peter Badcock Product Development ResMed Ltd

Perhaps what I am trying to do is not possible. If one opens up the example I referred to at [2] , Right Click on the Automation refnum constant and "Select ActiveX Class" "Browse" and navigate to the type library file (*.tlb) created by the LabVIEW Application Builder (for a particular EXE you create - mine is named HelloWorld), you will find it only contains properties and methods - it does NOT contain events. Is that a limitation of LabVIEW ? Can LabVIEW not export events into type libraries ? (at least that is what is suggested in the help file [1]). I don't want to register for events from other applications, I want to register for events from a LabVIEW application (albeit eventually from another programming environment). I cannot seem to build a LabVIEW application which exports events into its type library. regards Peter Badcock Product Development ResMed Ltd [1] Enable ActiveX server—(Windows) Enables the ActiveX server so the application can respond to requests from ActiveX clients. The functionality of the ActiveX server in the application is a subset of the LabVIEW ActiveX server. When you build an application myapp.exe, Application Builder also creates an ActiveX type library myapp.tlb. The type library defines an application class and a virtual instrument class and exports both Application properties and methods and VI properties and methods. When you distribute the application, include the type library with the executable file. [2] C:\Program Files\National Instruments\LabVIEW 8.6\examples\comm\axevent.llb\ActiveX Event Callback for Excel.vi

OK, so rewording my situation and question. I have a LabVIEW program with ActiveX Server enabled. Properties and methods can be accessed fine from other programming languages. (specifically a C scripting language used by Test Complete). How do I fire an ActiveX event from the LabVIEW side which subsequently will cause some callback code to run in the other language. Essentially I want to do the reverse of what you see in the LabVIEW example here: C:\Program Files\National Instruments\LabVIEW 8.6\examples\comm\axevent.llb\ActiveX Event Callback for Excel.vi So instead of the NewWorkbook event coming from Excel causing "NewWorkbookCallback.vi" to run , I will be (programatically) firing my_own_custom_event from my vi causing some code to run in the other language. regards Peter Badcock Product Development ResMed Ltd

Thanks for chiming in Chris. You raise many important details that would need solving. Guess what, I just did a quick search and there is a product which will fit the bill Check out this RTS Real Time Embedded Hypervisor. The blurb says: "Deployment of multiple operating systems on multi-core processor platforms is a logical step in embedded systems design, thus reducing total hardware costs while increasing reliability and system performance." Check out the picture showing how memory and a network is shared. rgds Peter Badcock Product Development ResMed Ltd

Hi folks, A little thought experiment. I'm thinking about ways to get RT behaviour from a multicore CPU using something akin to a hypervisor. Lets say I have a Quad core CPU (oh, that's right I actually do..), anyway what if I could force the Operating system to only run on 2 of those cores and LabVIEW (not LV RT) run on the other two cores (perhaps under another O/S ?). This way LV wouldn't be interrupted by random O/S activity and would have closer RT behaviour. All the RT targets available have slower CPU speeds than what is available on desktops at any given point in time, so being able to do something like this would provide me with a cheaper/fast pseudo RT system. Waddya think ?? The NI-hypervisor only runs on NI RT platforms rgds Peter Badcock Product Development ResMed Ltd