Jump to content

PeterB

Members
  • Content Count

    80
  • Joined

  • Last visited

  • Days Won

    1

PeterB last won the day on June 29 2011

PeterB had the most liked content!

Community Reputation

1

About PeterB

  • Rank
    Very Active
  • Birthday 08/31/1971

Profile Information

  • Gender
    Male
  • Location
    Sydney, Australia

LabVIEW Information

  • Version
    LabVIEW 2010
  • Since
    1994
  1. 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.
  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.