Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by shoneill

  1. 18 hours ago, X___ said:

    Sure. But then you cannot move the elements independently. Unless you ungroup, move, regroup.

    A modular object (such as a Graph) should be moveable as a whole, but its components should ideally be moveable individually. I have no idea how NI does that with their native controls, but this is obviously feasible. This is for instance something that was completely destroyed in XControls (an XControlled-Graph is frozen solid if I recall my now forgotten attempts to expand Graphs, unless you rebuild the whole independent component grabing and moving, as I was told by NI).

    Something can't be in a peer group and not be in a peer group at the same time. This is how the LV diagram "Group" works.

    What NI has is a parent-child grouping which is something different.  Not saying this couldn't be an interesting idea, just that it's not comparing apples with apples.

  2. You are setting your offset to 0.001 of a single sample. That's not going to be visible.

    The top value in your clsuter is your offset (zero X value). The second top value is the time spacing between adjacent data points (not the entire length of the plot).

    If you need 100 data points before the trigger, try

    Top: 0.001, Middle 0.00001, Bottom, your data

    You SHOULD use proper timing data.  If your data is recorded at 1MHz, the middle value should be 1/millionth in order to have your X-axis in seconds.

    Please note this also only changes the DISPLAY of your data, it has nothing to do with the data's ACTUAL position relative to your trigger. You need to set up your acquisition properly in order to guarantee that.

  3. 3 hours ago, Aristos Queue said:

    There are no plans to extend LV 20xx capabilities of XControls or anything similar. All work into improving G-based UI components is being done by NXG teams. I and others continue to push requirements to them (such as "let them be included in arrays"). (In case y'all are wondering, my role with NXG is largely "lead user kibitzer". I have worked on various parts of the code base over the years, but at this time, I am 100% tasked with adding features to LabVIEW 20xx, especially language extensions (there are others on my team working on editor improvements). The channel wires and the malleable VIs have been my work; there's a couple new data types in LV 2019 that fill some serious long-standing language holes. And LV 2020 should... well... let's say I'm kind of eager for it.)

    So your job is to make it as hard as possible for NXG to ever catch up with with LV 20xx? 😀

  4. 3 hours ago, Aristos Queue said:

    I don't believe this was ever promised.

    It was listed as part of the roadmap, with the added caveat, that such extension would be available only in C#. I certainly remember it being communicated as the way forward with regard to replacing XControls.  It was certainly used as a carrot, even if the word "promise" is not accurate.

    Then at the CAB in Austin some years back, we were told that won't be happening, that the existing control classes won't be extendable.

    I can't recall exactly who and when, but it was definitely communicated.

  5. 7 minutes ago, ShaunR said:

    I don't think it matters. If it's a package that comes with LabVIEW, you can choose to use it or not. 

    My usage of it or not is completely irrelevant to the point I was trying to make.

    NI should be working on a proper implementation of extendable controls (C# inheritance was touted, then it turned out that will be limited / useless). I fear they are looking for a way out of that corner. But still, if we're realistic, there'll probably be notnhing of that sort coming in the next X years, so this IS a boon. I just hope this doesn't stop NI working on a proper implementation.

    I'm not casting any shade ont eh toolkit itself, it looks pretty amazing.  The reason I think it might sway people at NI is because it IS good. If it would be half-arsed, I wouldn't be afraid. So from that point of view, technically speaking, 🧡

  6. 1 hour ago, hooovahh said:

    You are incorrect they do and it is amazing

    I don't think I am incorrect. It mimics the existing VI Server tree, but it does not extend it per se. I agree it's a great toolkit and has a LOT of potential, but it's just not the same.

    I've done something very similar, I'm aware of the benefits and the limitations of this type of implementation. Code changing properties of the control in parallel to the LVOOP approach can be very hard to manage.

  7. In end effect what we need is the ability to actually inherit from existing controls in order to extend their functionality. Just being able to extend a String control to allow for a dictionary should be possible without it being distinguishable from a "normal" String control on the FP or BD (Perhaps for some identification on the BD of it being an extended control).

    XControls never really offered this. Correct me if I'm wrong, but I don't think QControls do either.

    We were promised that NXG would get exactly this kind of extensibility, but having heard nothing more on it (and a few rumours to the contrary, I fear the worst).

    I have the feeling NI might use this as an excuse to see their promise of extendible FP controls as being fulfilled. For this reason and this reason alone I am skeptical and pessimistic.

    TL;DR. Technically yes. Politically and strategically no.

  8. To make sure no Events are lost I usually just register the user event at the moment of creation and pass out the event registration refnum for the event.  Then, any events sent before the Event loop is running are not lost, they are stored within the event registration refnum queue.

    A different idea is the ability to get the last sent value.  I typically involve the event loop in this as it "owns" the values and other processes may actually update the values (such as internal consistency checks) so that the last "sent" value is not actually up-to-date.  But I canunderstand the idea behind being able to efficiently get this value back.

  9. On 12/15/2009 at 5:35 PM, Daklu said:

    I discovered a case of 'QSM parallism.' What I mean by this is that a state queues up more states with the expectation that they will be executed immediately, but the queue still had states on it that it needed to execute to complete a previous process. That essentially (unintentionally) splits the execution into two separate paths that are interleaved on the queue, which of course leads to unpredictable behavior. The odd thing is the software seems to be working okay. I suspect dark magic is at work but I loaned out my copy of "Software Exorcism for Dummies" and haven't got it back yet.

    Separate out the external Queue from the internal one.  If the internal queue has elements in it, ignore the external queue.  Only read an element from the external queue when the internal is empty.

    You can extend this to N layers by maintaining a stack of queues, where element zero is the external queue (should never be destroyed).  All internal states which enque further states do so on a newly-created internal queue and pushes all other queues down the stack.  This way you get deterministic execution of your states.  Guaranteed execution order without interruption and a way of investigating the execution flow (depth of stack and so on). Of course when an internal Queue is empty, it is destroyed and the top-most queue is retrieved from the stack.

    I keep coming back to the definition of a "Pushdown Automaton" even though it really does not fit, but it helps me to visualise what's going on.  Imagine that the input tape and the stack are the same thing.  Each input tape is an element of the stack.  Pushing and popping input tapes allows you to essentially create subroutines.

  • Create New...

Important Information

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