Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. Is this what you are doing? SubPanel_Main.zip
  4. If you open it with Open VI Ref and then close it before calling Close Reference, there shouldn't be a Save Changes dialog. The only way I replicate is if I leave the panel open after the VI finishes running and then the user closes that panel (which is correct behavior). Is that what you're doing?
  5. Yesterday
  6. I have an application that is using subpanels, and I am having some issues where they seem to be missing button clicks. This is sporadic and not isolated to one specific button but seems to happen throughout the application on various screens. I look in the event inspector window and the value change never fires when these events are missed, so it's as if whatever is managing these events is missing it completely. After two or three clicks it will take. I know it's tough to help without a reproducible case, so I am mostly posting this to see if others have run into this behavior because I have been spinning my wheels.
  7. Thanks Fab, I am waiting on the LAVA admin(s) to do that.
  8. Could you save for previous verison of LabVIEW, maybe I'm slow but I'm still back in 2017.
  9. I would like to create pause button to pause the process. Then a Run button that when pressed will continue from where it last stopped at. . Attached is my programme. . I would really like your help. . Thank you. . FM_demod_solution.vi FM.bin
  10. It is loaded with Open VI Reference. The Explain Changes" dialogue states that it is a cosmetic change (A front panel object was resized). My current suspicion is that it is linked to the "Fit Control to Pane" setting of the xcontrol on the host VI and/or the facade (which the actual control is also set to). I've at least now ascertained that it also happens in normal sub-panels too and is repeatable. Maybe I should just publish it with a known issue - something I have always hated to do. Then at least others can fiddle with it.
  11. Can you share some examples if available?
  12. Hi Jeremy, Would you please update http://lavag.org/bbq to direct to this post? It still directs to 2018 BBQ. Thanks, Fab
  13. So this is where it gets trickier. Intrinsically the kernel-client protocol is geared around sending strings to the kernel and by and large getting strings back. This makes sense if one thinks the client is essentially a terminal with a keyboard, a screen and a human. So trivially you can express the data to be sent to Python from LV as an assignment statement "x=3.141592654" and have that executed on the kernel and it will create variables in the kernel's namespace - but it's hardly efficient if what you want to do is send a moderate sized 2D array of floating point numbers over. I think the solution is to implement a pair of Comm[1] objects to send and receive custom messages[2] in which data can be encoded in a more efficient way and used to manipulate the globals() on the Python side and request specific variables to be sent back to Python. I've had a look around at various 'binary json' serialises and liked the look of ubjson[3] the most (ideally I'd implement the Python pickle algorithm in LabVIEW, but that didn't look fun!). That would solve the how to encode the data for transfer part of the problem. The actual mechanics I think will involve a CommunicationsChannell LabVIEW class that has methods to squirt the python needed to create the Comm objects at the kernel end, deal with the kernel requesting to open it's side of the communications back to the LabVIEW and then methods to send arbitary LabVIEW data and request Python data and map it back to LabVIEW types. Finally it will need to implement comm-open, comm-close, and comm message types - but they're basically easy given the class hierarchy that already exists for messages. All of which is great, but I'm running out of Easter vacation, about to hit the summer exams and I'm the departmental exams officer so have negative free time for a few months! [1] https://jupyter-notebook.readthedocs.io/en/stable/comms.html [2] https://jupyter-client.readthedocs.io/en/latest/messaging.html#custom-messages [3] http://ubjson.org/
  14. Thank you for your kind reply. I totally understand about while loop mechanism. It's helpful for me.
  15. PS: Did I mention that the design of these things was arcane and bad? Yes? Ok. 'Cause it's true. I have a long list of lessons I hope NXG learns.
  16. XControls work just fine... if you dance with them the way they were intended. *head bang* If you don't want data to be saved, one way is to not put it in the State data. If you only need the data in the facade, add a shift register. But if you need it lots of places, put a global unique ID (GUID) in the XControl's state data, something that never changes after creation, and create an LV-2 style global with a lookup table from the unique ID to the data. You can create GUIDs on any LV OS using: LabVIEW 2017\resource\Framework\Providers\API\mxLvGenerateGuid.vi Changing the state shouldn't cause the VI to need to be saved unless it needs to be saved. So, yes, sure, in the IDE in a directly called VI, yes, changing state dirties the VI. But obviously that doesn't happen in a built app. AND, importantly, it doesn't happen in the IDE for any dynamically loaded VI (unless you are adding the 0x1 flag to track changes, in which case you get what you requested). If you're loading the hosted VI into a subpanel, that means you're working with it by VI Reference. So load it using Open VI Reference (without the flag) and the problem of being prompted to save should go away.
  17. Last week
  18. 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? 🙂
  19. That solves part of the problem, but not all of it. Using the Convert State for Save ability lets you stop writing volatile state information to disk, but it doesn't stop LabVIEW from thinking that the host vi (i.e. the one you've put the XControl into) requires saving. That happens as soon as you toggle the state changed boolean in the action cluster. You need to have an entirely separate means of storing volatile, per instance, state and then not touch the state boolean in the action cluster unless you really do mean to record a change that would require saving. I've been using variant attributes on a variant stored in an LV-2 style global, but I guess one could use 1 element queues, or even, gods forbid, a global variable! That said, I;ve just realised that I ought to have coded the Uninit Ability on my XControls to clean up the per instance variant attributes when the host vi goes out of memory....
  20. @Yassamina BERKANE The answer is the same as it was in 2006: dequeue and concatenate. A ragged 2D array is not (and never will be) meaningful in LabVIEW. Because the compiler cannot guarantee that you're going to add arrays of all the same size to the queue (you might be doing that, but it cannot be proven from code because refnums can be shared all over the place), any attempt to ask for all the queue elements in one array will have them each wrapped in a cluster. If you dequeue and concatenate, you can build a 2D array yourself.
  21. Isn't there an optional ability VI you can add to an XControl that will modify the state before saving? It says it's specifically for this purpose.
  22. Aww, that's a shame. It would still be nice to get it added to LabVIEW though; then it will be possible to use this framework without adding a big dependency. New data types sound exciting though; are you allowed to say what they are? (A hint at least?)
  23. LogMAN

    LabVIEW Memes

    We'll grow into it eventually 😋
  24. ShaunR

    LabVIEW Memes

    am I doing this right?
  25. How to overlap 2 images along overlapping area in labview? I have tried many methods but I am not getting desired result. mask.vi
  26. I think so. Well. I know so but I'm unsure of the mechanism since it is an xControl on a VI that is loaded in a sub-panel of another xControl (if that makes sense-it's nested). When exiting, the host VI (loaded in the sub-panel) wants to be saved. I can stop it by not updating the display state of the xControl on the loaded VI host, but then the facade doesn't update properly. Additionally, it doesn't seem to be every time; just sometimes which is proving to be a barrier to finding a work-around. If it's not loaded in the xControls sub-panel (even a normal subpanel), then it all works as intended. I have, since, thought of a couple of things to try, but it'll have to wait until I can get round to it again. Amen.
  1. Load more activity
×
×
  • Create New...

Important Information

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