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 subject
  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 demonstrat
  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 refresh
  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 suc
  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
  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
  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
  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
  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.