Jump to content

X___

Members
 View Profile  See their activity

  • Posts

    426

  • Joined

  • Days Won

    28

 Content Type 

Everything posted by X___

  1. X___

    VIM and units

    X___ replied to X___'s topic in LabVIEW General

    What happens after December 31, 3000 at 4 PM though? (timestamp value 34618060800 = x80F65B000 = b100000001111011001011011000000000000)?
  2. X___

    VIM and units

    X___ replied to X___'s topic in LabVIEW General

    Seems to work except that it will basically strip the unit from the number, which probably should be documented. I would "expect" a "united" numeric to result in a string with the unit label appended. <OT> I had to check what "Cast Unit Bases" does, as I never used it before. The help is quite unique in its warning: Essentially, if no unit is provided (as is the case in the new Scalar to String.vim), it takes the input and drops the unit (after conversion to the SI unit). The conversion is weird, as illustrated in the attached VI (Control with unit to Cast Unit Bases): I copied the first control and changed its unit: the result after Cast Unit Bases appears the same... ????? But it also allows you to transform a value in oz/min into one in liter... assuming that you have an indicator with the proper unit to collect the output. I am kind of at a loss as to what this was designed for (turns out to be useful for the VIM, bit other than that?). </OT> Control with unit to Cast Unit Bases.vi
  3. X___

    VIM and units

    X___ replied to X___'s topic in LabVIEW General

    Try typing s^-1 in your control... Or mi/s/Hz... This is the power of units. Not mentioning a convenient way to check the dimensionality of a formula (but that's because complex formulas in G tend to explode into spider webs quite quickly, unless - as one should do - one switches to the text alternatives where G does a poor job of visualization).
  4. X___

    VIM and units

    X___ replied to X___'s topic in LabVIEW General

    I do like units for UI. If my users want to use MHz rather than kHz, or ps rather than ns, I do not have to worry about any fancy UI gimmick. It works (it even will not let the users change the dimensionality of the unit of a control at run time, which saves me the headache to fight against mischievous or distracted typers). They are clearly out, for the worse in my opinion. As we all know, units have never been an issue in major earth-based engineering projects... As for why the x^2 and Quotient and Remainder, etc., "incompatibilities" were never fixed, NI has always had the convenient excuse that they were understaffed, had other priorities, etc. I wouldn't be surprised if the same pattern reproduced itself with NXG.
  5. X___

    VIM and units

    X___ replied to X___'s topic in LabVIEW General

    These comments are all right. Most users will only see the VIM though, which is what my warning was about. Feed a unit-scalar to a VIM? Better check whether the different cases in the VIM are equipped to handle it properly.
  6. X___
    I understand that NXG dropped units, is bug free and makes programming easy for those who will still need to program when it will be finally ready. Not that I could care less, but VIM, which were introduced in ODG (old gen) are challenged by them (this is of course not the only problem with units, but VIM being recent, this problem is). Take the scalar to string.vim that comes within vi.lib\Utility\Debug Log. If you feed it a numeric, it will work fine and spit out a string reflecting the value fed in. If you feed it a numeric with unit, it spits out garbage, as the cases in the VIM do not know how to handle units. Instead of treating the culprit as a "all other types not handled by the first few cases", it recognizes is as... a timestamp: The point is not so much that scalar to string.vim doesn't work as expected, but that you need to take this into account if you are writing VIMs and plan on using them with scalars with units (or any structure containing those), as they will not be recognized by the cases you will have written for scalars (which is how I discovered the problem). Some will say: well, obviously, since a scalar with unit is a different type than a scalar without. Shall the all-knowing among us be praised! I will argue that: - since VIM will in general have a garbage collection case, a scalar with unit might look like it is treated correctly by a VIM you do not check the internals of, but in fact will spit out garbage. Could be tricky to debug. - units are part of ODG, and the current VIM concept doesn't make it easy to handle them generically. Is it an easy thing to do? Maybe not. Anyway, programmer beware.
  7. X___
    No interest in NXG from this neck of the woods would be the feedback to the Powers that Were.
  8. X___
    I believe a LabVIEW Jupyter kernel is out of the question without NI involvement. And it wouldn't address my use case, as I would want users to work with data in python. Moreover, I would for instance lose access to all the parallel job tools that I have access on my local cluster supporting Jupyter notebooks 🙂
  9. X___
    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).
  10. X___
    just forgot to add that my comment about the lack of flexible grouping in LV referred to edit time behavior, which Wiebe's tool doesn't cover. Basically, we need to be able to group objects so as to be able to grab them and move them around as a whole (at edit time), but also be able to grab one inside the group and reposition it (ability which most graphical software provide; not sure about NXG). Essentially what one can do for members of a cluster, without the drawback I was illustrating above.
  11. X___
    I thought it might be helpful if I clarified my use case. Most of my development is LV-based, but I can hardly find anyone interested in working with that code (proprietary language, expensive, graphical, etc.) therefore, in order to be able to share and make what I do expandable by others, I need to interface it with something that is exactly the opposite. Jupyter notebooks are that thing today. What I am looking for is: 1) a way to send markdown text and graphing instructions to reproduce plots generated in LV (or plots that can't easily be produced in LV) in the Jupyter Notebook. The goal is to replace a custom-designed Notebook I based on a .NET rich text box control, which works fine, but is not interactive. 2) a way to pass data structures generated in LV (which the user will have extensive documentation about) to the Jupyter Notebook so that the user of the Notebook can do some processing on their own. 3) a way to send instructions (think custom scripting language) and data to LV. Point 3 is to some extent covered by your tool, as long as LV polls the kernel (and knows which variable to look for). Whether or not a better communication protocol (with user events?) can be designed is up. Points 1 and 2 are pretty much the same thing, the only difference being that 2) might involve bi-directional communication (LV sends data that is processed in the Notebook, which then sends back the result (see Point 3). The original use case, however, is merely to provide data for the user to do whatever they want with. A big unknown to me is whether it would make sense to have access to the Notebook structure within LV (cells, history, data).
  12. X___
    For my particular (ultra-simple) application, that would be an overkill, as I already handle that with a custom-made handler. For the general case, that could certainly be a way to handle multi-component objects. But my question is whether what @The Q is describing above is something that can be done within the wizard (picking one of the controls of the multi-component control as the starting class and doing the weight lifting to add the references to the other controls).
  13. X___
    Sending moral support your way...
  14. X___
    OK so the connection to a Jupyter notebook works, great. I can define a variable in the notebook and read its value in LV. Now how do I send something to the notebook from LV? 🙂
  15. X___
    Let us know when it is posted on VIPM's package list.
  16. X___
    I'm way above my head here, but are you saying that in principle the "clustering" of multiple control is just a convenience trick or is that bringing advantages (such as access to class properties via property nodes) that would be lost otherwise (defining a facade with multiple controls NOT bundled into a cluster)? Of course, what's missing for this to be even practical, is more flexible way of grouping objects in LabVIEW (that is, one that allows moving things within a group). Just to put my questions in context, I have developed a simple (well, relatively) way of adding a tip strip to graphs so that long plot names can be read without having the legend size explode. I was contemplating migrating it to a QControl, but the layout of a Graph (due to its accessory panels) can be quite random, and if everything (graph and tip strip) is put into a cluster, the problem I was raising above would potentially ruin the day in some UI cases.
  17. X___
    Sure, but there are cases like this (vertical "scrollbar" over horizontal "scrollbar", but this works also for the opposite situation): You can "interlace" two XY Graphs and move their "accessory" panels and not have any problems using either one, no matter which one is on top or in the back: It's just something to keep in mind before being bitten late in the development process.
  18. X___
    Unless I am mistaken, the composite control approach of using a cluster will potentially cause problems if such a control happens to be partially overlapping another control (on a VI panel). I tried to "dislocate" the large scrollbar QControl to emulate a moving subcomponent, and put a String control underneath the transparent part of the cluster (separate control) as illustrated below: Sure enough, this String control is inaccessible at runtime. Unless I am missing something, that's a caveat users may want to consider before embarking into complex control design...
  19. X___
    Thanks. I'll keep an eye on it.
  20. X___
    @The Q In the manual, you write (7.3 Methods): I don't see any example of a public method in the examples coming with the toolkit, so I am trying to figure out the intended use. My understanding is that if I want to add a method to a QControl (say, "Add Element"), I need to provide a VI which the user needs to use wherever they want to call that method, rather than having the convenience of using an Invoke Node and connecting the QControl refnum to it (which would be neat, as this would provide a built-in list of methods). Do I get the idea right? It sounds like a polymorphic VI for those methods could do the trick of providing a list of methods, and using VIs not shown as Icons would bring us close to an Invoke Node: The VI above has nothing to do with QControls, it's just borrowed from my own approach to the same problem (of native control enhancement), but it shows what I mean. If that makes sense, I wonder whether this is something that could be added to the Wizard? Something like "New Method from template" that would add a VI to (or create if there is none) a polymorphic VI and let the user define the number of parameters to use for that specific control (or fix that to one, I could live with either option)...
  21. X___
    @gb119 Outstanding work! Just getting started trying it, so bear with the basic comments: - The automated kernel path search on Windows fails to find ipython.exe located in C:\ProgramData\Anaconda3\Scripts\ipython.exe Since I have turned off "Enable automatic error handling dialogs" in Options, I couldn't figure out the problem until I dug down into the diagram (luckily that was trivial due to the nice code layout). Maybe a separate tab with an error indicator could help at that early stage? - Right now each LabVIEW code instance starts a new kernel and stops it upon quitting. This departs from the broader use case mentioned in your intro (remote kernel) and I am not sure whether that is because of the early nature of the project or because that would require a different design (clearly it would, but would it be fundamentally different?). In particular, the seduction for me would be to be able to interact with an existing Jupyter Notebook (having its own kernel already running) or better yet, spawn a Jupyter Notebook. Is that something you have in mind for the future? I'll go back to testing. Keep up this great stuff!
  22. X___
    In retrospect, I believe this would be a nice UI tool to define (contextual) menus: starting from a pre-populated template, unchecking boxes would simply remove that item (or sub-menu) from the final control menu.
  23. X___
    I think I understand what I was doing wrong: I was doing those tests (at least some of them) starting from an unsaved new project. You may want to check for that or strongly warn users against trying to use an unsaved project (you probably do, but even though I read the Getting Started Guide, I can't remember having registered this info). This being said, the sluggishness remains...
  24. X___
    No issues with the examples.
  25. X___
    All this being said, now I am completely unable to create a QControl, wherever I try to save it...
×
×
  • Create New...

Important Information

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

  I accept