Jump to content

harbenger

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0

About harbenger

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since
    2005
  1. I'm far from being an elder, however, here's my take on it: Maximize the number of display pixels you can put on your desk. Buy 2-3 large widescreen displays (at least 24", 27" is better, even one 30" is awesome). There are some video cards that support 3 displays which makes it easy to hook them up. LV is a graphical programming language. Visual landscape is key. Read this: link Justify your purchase with the applications you are developing. The needs of a GUI developer are considerably different than one crunching numbers or time critical control algorithms. Or, find out your max limit, price your monitors and spend everything else on your workstation and peripherals.
  2. Jim, I am curious what you mean by something that can merge/branch worth a damn. Is this a LabVIEW problem or a general SCC issue? It seems to me that the choice to move beyond SVN is largely motivated by the desire for distributed version control. I would be curious to know how much paradigm shifting has occurred in the new flavors of version control. In other words, do the new version control systems provide any better support for the basic versioning actions (checkout, committ, branch, merge, etc)? Git seems to be one of the few that claims to have started from scratch (and not from CVS/SVN) which may address this for you. I too have been looking for a new version control strategy. I've been looking at Bazaar which appears (at first glance) to be very similar to Mercurial: Python based, distributed version control and can work with existing SVN repositories. The differences are most likely minor yet made to appear grand (see here). The one issue I recently had was with a 3-way merge. Bazaar was unable to track a VI which was merged. After the merge it thought that the existing file was deleted and a new one was generated with the same name, which wasn't quite what I was expecting. I was able to kludge it and find a work-around. I would be curious how well LabVIEW's merging VI could be integrated into Mercurial. This would be a key functionality for me.
  3. My (limited) understanding of state machines requires that the next state logic be well defined. The QSM seems to create a hybrid state machine where the next state logic is an array. So, each state has an input which is the queue and then outputs it as next state logic. Luckily, I don't think this will change whether or not it is a Mealy or Moore machine. However, the utility of a next state array comes with the cost of increased complexity. I'm not sure you can use the traditional state machine representations as the queue allows any state to transition to any other state. And, as you mentioned, states can exist with no next state logic. This notion is completely against traditional SM design. If you have large SM's and/or want to regulate the transitions, I would be weary of using the QSM. If you have to use a QSM, I would try and model it as close to a traditional SM as possible. Hopefully you can eliminate any major vulnerabilities in your code. As for the Mealy/Moore question, one good place to look for information is in university course notes. Here is a >10 year archive for some good holiday reading. I'm sure there are better places for this, but this this one is familiar to me. http://www-inst.eecs...0/archives.html There is a primary difference between Mealy and Moore machines, which comes from the digital logic world: synchronization. In Moore machines, the output is dependent on only the current state. This means that the output changes at the clock edge when the SM transitions to a new state. This is not true for a Mealy machine. If the input changes inside a state of a Mealy machine, the output CAN change before the clock edge. Other side effects: Mealy machines typically have fewer states, but have synchronization problems when combining multiple SM's. I would say that we mostly program in a Moore-like structure: at a fairly high level, our states perform a specified function with little consideration of changing inputs. However, if your state's function (output) depends on inputs to perform, it would be a Mealy machine. Interestingly, the state transition is the same for both Mealy and Moore machines. It can be a function of inputs and the state. However, a decision must be made on the next state. In the digital logic world, the next state logic is traditionally synchronized to the clock. This means that the next state logic can change where the state will transition up until the clock edge. This can be lost in the software world, especially when event structures and queues throw out fixed timing altogether. I think there is a common misconception between how state machines transition and how the output is generated. The Mealy/Moore difference is really about how the output is generated, NOT how the states transition. My guess is that this confusion comes from moving a hardware defined (digital logic) concept to software. Outputs are now more than just digital bits as we have our states doing much more sophisticated things. If the function of our state depends on any kind of input, then technically it is a Mealy machine. I see two kinks in using QSM's: 1. Event loops break regularly (this is a loose term) scheduled state transitions. 2. There are queue management issues abound. My current favorite is when one state machine has two independent idle loops. If there are two events which cause the SM to switch between loops, it is possible that the queue will grow with state transitions that will never be serviced.
×
×
  • Create New...

Important Information

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