Jump to content


  • Posts

  • Joined

  • Last visited

About PJS

  • Birthday 08/05/1969

Profile Information

  • Gender
  • Location

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since

Recent Profile Visitors

1,371 profile views

PJS's Achievements


Newbie (1/14)

  • Reacting Well Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges



  1. I have gotten a VM working in virtualbox using the PC utility from MAX. My issue is that I really want to be running NI-Linux Real-Time (Intel x64-based) and not pharlap. If I read this right, That is for a real time cdaq chassis. I am developing software remotely from the hardware and would like to do some things and test within the linux environment connected to my pc.
  2. Seeing what changed with the Lava forums. Been a while

  3. QUOTE(Neville D @ Aug 23 2007, 06:36 PM) my architecture allows for logging. But the listbox control is interesting... could setup an input on the initiialize of my queue to open a clone front panel, and then use that listbox idea to display a state history, so to speak. hmmm, interesting idea. It might get a bit complicated since the manager can handle multiple queues running at once... but a debugging tool to look into non, the less. Might be nice to use a multi-column list box, with iteration next to it... so that the number of duplicated states are not adding to the list. In that I mean, if you keep going back to the same state, a counter would run up, rather than keep adding the same state. Many times, I have an issue, where I go to the wrong state, over and over... so rather than have 100 lines of "state a", I would have "State a" in once column and 100 in the next. Now if it is ping ponging between two states, then those entries would be logged... Plus I see other benefits of the multicolumn.. which is out of the scope of this conversation at the moment. I may have to play a bit this weekend.
  4. QUOTE(Ben @ Aug 23 2007, 07:53 AM) Not wanting to take the credit, it was suggested up higher. If you click on the link to my samples, there is a template ready to download that provides a base framework. Amazingly similiar to others I have seen. I guess when you are on the right track, you start to see convergence on simularities. It implements all that I have suggested above, And can very easily be modified to a two loop machine. The one feature I have not seen in similiar architectures is using a multiline string to add states rather than the pesky array constant. For me, it makes it infinitly more readable. For all, feel free to comment good or bad.
  5. This reminds me of a conversation that went on some years ago petitioning NI to remove sequence structures from LabVIEW as well as another that wanted global variables removed. The core of both arguments was actually due to poor user implementation, and NOT the actual tool itself. This framework, like any other tool works just fine if the programmer has discipline. naming states with some sort of grouping method, logical dividers, a state, for debugging, that catches undesired cases, a cluster that is passed thru so that adding/deleting variables that need to be accessed in every state is on ONE wire, some sort of error handling routine AND the ability to log what the machine is doing are MUSTS. GEE, just like the arguement to remove GOTO statements from basic and fortran when I was doing that in the late 80s. The environment and frameworks are never responsible for making up for poor programming. This is not a criticism... When I look at my original labview code from back in 1993, it is enough to make me puke, but the race conditions, lockups and other problems I had back then were due to my poor programming decisions, and NOT from the ability to shoot myself in the foot! My $.02. No inflation here. LOL
  6. oh no, I was not taking this personally.. LOL. Just stating that I was not utilizing a generic interface. actually the opposite, I expect the parent class to access the data of the child class.
  7. oh no, I was not taking this personally.. LOL. Just stating that I was not utilizing a generic interface
  8. These are not your garden variety decoders. These are professional grade decoders in use at the head ends of TV station transmitters. So no, not a generic decoder. However, one system can handle up to 16 decoders.. that may or may not share the same settings. Does that make sense? There are other classes that I will implement such as a files class... but if I can grasp this interlink... then the rest will come easier. I guess since LabVIEW OOP does not implement properties... such as a .dot interface. It does make it more difficult.
  9. QUOTE(Tomi Maila @ Aug 20 2007, 01:22 PM) I understand how to do what you are saying, it seems that it is a workaround. I might have performed the inheritance wrongly. decoder != "is a" setting. Rather, decoder "Has a" setting. Thus my desire to 'attach' hSettings to hDecoder. I am not trying to argue, rather I am trying to understand. The end user has reasons to change settings for those instances and , may change them on the fly. Thus a class all to themselves with plenty (about 200) properties (you would be amazed at how many settings an mpeg decoder can have.) However hDecoder need only know the hSetting in order to implement the settings on it's specific decoder. I think once I get my head around solving this understanding the rest will come quickly.
  10. At the behest of Tomi... I am posting here. I have been doing a lot of reading here, the NI forums, and expressionflow.com. Frankly a lot of the theory goes over my head, so I can take it on faith for now. It seems that most articles are really to show you the benefits, but not how base implementation of how OOP in LabVIEW is done. Or I am just to entrenched in data flow... and am having trouble getting my mind around this. Either way.. I want to do this right, and not just work around it. When I envision OOP, I see an object (class) with actions (methods) and adjectives (properties). Well at least in my little mind, I have yet to find an explanation or mapping if you will of LV to OOP at least in layman's terms. Quick background on me... I have been using LV since 1993, and am a certified architect. I only say this, not to brag, but to give you an idea that I know my way around LabVIEW pretty well. My programming background before LabVIEW was Fortran and Ansi C. I have dabbled a bit in VB, Python, C++ and C# although my abilities are very infantile there. All this being said, I am trying to take advantage of OOP design and implementation in LabVIEW. So here is the start of my little project (OK there are almost 700 calls that I have to map, the nice things is I have the class breakdowns and descriptions from C++... It is a matter of replicating them in LV. I am wrapping a large library for a mpeg decoder card. My current project simplified. I am starting with two classes. 1) decoder 2) settings. At a basic level (this is where I am at in this project) I instantiate a new decoder class... No problem, call this hDecoder. I instantiate a new settings class, again no problem, call this hSettings. Now that I have these two objects, my problem is that I want to 'attach' hSettings to hDecoder. I had assumed that if the decoder class inherits from the settings class, then I could do this... But LV does not seem to allow me to access the data stored in hSettings. Under the hood, so to speak...the decoder class is instantiated, there is an U32 handle that is a pointer in memory for the decoder that is being utilized. The same is also true for the settings. Once those settings are instantiated, they should belong to a specific MPEG Decoder in the PC. OK now that I have these two things, the next thing I need to do is to INIT the MPEG decoder. This method should belong to the decoder class. This method not only requires hDecoder, but also hSettings. In a nutshell, there is a memory space allocated for me to setup everything that this decoder requires in order to operate. In order to invoke these in the specific decoder, I pass the handle to the specific decoder of the memory space that contains it's settings. These things are handled between the DLL and the driver for the decoder card. My "work around" is to write a VI (property node, in the settings class) that extracts the U32 handle for that instance of settings, public properties.. that I can call and then store in the decoder class. Well maybe this is not a work around, but it seems to be I should be able to attach the settings to the decoder, and then access that data through passing in the decoder class to it's method of initialize. I am hope I am clear, if not please let me know. Thanks in advance, Paul
  11. repeatively writing to TDM files causes memory leaks. I do not know if this belongs here. NI is aware and it is corrected in LV8.
  12. Funny, you can not access the SCC functionality from the custom menu dialog. Have to open your SCC tool to take action. Should be an easy fix for a future version!
  13. The only issue here is that they have to be different for every divider. Not a major big deal, but there non the less, plus tunnels need to be addressed. I frequently turn off the default if unwired to keep me from making an oops. With various state machine architectures, this should be a feature available in the state case similar to the custom menu dividers.
  14. Bookmarks or Hot spots in diagrams. Frequently queued message architecture has lots and lots of states (see my next wish). I would love to be able to set a bookmark, hotspot, hyperlink and have a floating palette that allows me to one touch navigate centered on that section. Please do not forget the back! Yes, I know I can set a discrete text tag down and use the find, but that is a crippled work around at best and I get no back.
  15. PJS

    Wire Labels

    My only issue with Wire labels would be, that it would place the labels in the worst place possible, the way auto-wire routing works. If they do it, you should be able to slide the label along the wire! Additionally, you should be able to click on a wire and have it inherit the label from the previous junction. If you put a wire description in outside of any structure, the wire on the inside of the structure does not maintain the description. FINE, but allow me to right click on the wire and inherit the description. That would be my implementation. Plus color coordinate the label to match the wire!
  • Create New...

Important Information

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