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