Mike Le

Thursday, April 6th 2023

6:00PM Pacific

Zoom Meeting Link:

https://us06web.zoom.us/j/85349689601?pwd=dVNvZDZtWEFVUHFrZ1JzZTlrcVQrUT09

Hi all! After a long hiatus, San Diego LabVIEW user groups are back with another virtual user group.

Mike Le (CLA) will present on Bowzer, a LabVIEW project extension that makes developing in Actor Framework simpler and more intuitive. Bowzer provides a user friendly interface that makes browsing and understanding actors as easy as clicking through the case structure of your favorite traditional state machine.

Whether you're an experienced QMH power user looking for an easier way to get into actors or new to LabVIEW and looking to dig into more advanced frameworks, Bowzer can help you visualize actors in a more familiar and developer-friendly way.

Please RSVP by dropping a line in this thread so we can get a headcount!

And feel free to share our LinkedIn event with your LabVIEW colleagues and contacts:

https://www.linkedin.com/events/sandiegolabviewusergroup-bowzer7041772398311854080/

Thanks Ivan, I've been wanting something like this for a while! Very useful.

Hi all,

I was having this discussion with some coworkers. We were wondering if a CLA should imply that you are familiar and comfortable with LVOOP. If so, then it would seem the format or rubric of the CLA exam should change.

Current CLAs would be grandfathered in, so this is a question for how future CLAs should be vetted.

On 12/3/2020 at 11:57 AM, Bryan said:

Hopefully this alleviates any concerns about LabVIEW becoming unsupported in the future in favor of NXG.

Alleviates that concern while greatly heightening the concern that NI isn't positioning itself for relevance in the 2020s.

1 hour ago, Michael Aivaliotis said:

It would be great to have a project menu item, goto parent interface:

How would this work if a class has multiple interfaces? Maybe instead of a right-click menu option, some kind of visualizer that only shows the class's interfaces?

Haven't been in a few years; excited to see what's new in the community and what people are working on.

So I'm trying to convert Actor Framework into a PPL in a project with ~70 Actors. After I created the packed project library and tried to do "right-click --> replace with packed project library" on Actor Framework.lvlib, LabVIEW replaced every instance of Message Enqueuer.lvclass labels with "Actor Framework:Message Enqueuer". So this broke basically every class as unbundle by names for any given nested actor's enqueuer now point to labels that do not exist.

Even worse: for methods of all my old Message classes, the front panel terminals still pointed to the original Actor Framework.lvlib Message.lvclass. I suspect that front panel controls/indicators were not updated to point to the PPL?

Manually fixing this in all 70 Actors' private data and message classes is something I would very much like to avoid. I ended up reverting all the changes.

Does anyone have a guide on how to safely replace Actor Framework with a PPL in a large existing project?

I'm using LabVIEW 2016 SP1.

Want to cross-post this discussion from NI Forums and see if anyone here has suggestions.

https://forums.ni.com/t5/Actor-Framework-Discussions/Looking-for-IDE-Performance-Optimization-Suggestions/m-p/3961791#M6126

Boils down to, as you build large projects with AF are long build times unavoidable? What are best practices for avoiding long build times while working with AF?

Is there is a compilation of all the "tribal knowledge" about best AF/OOP coding practices for keeping build and IDE performance manageable?

Cyth Systems
9939 Via Pasar, San Diego, CA 92126
Wednesday, August 7th
6pm-7:30pm

San Diego LabVIEW user groups are back!

Ivan Gagne (CLED) will provide an overview of SQLite, a powerful file format for storing test data, debug logs, and configuration files. Followed by more informal networking and application discussions. Food and drink provided, novices to experts welcome.

Please RSVP by dropping a line in this thread so we can get a headcount for food, etc.

I have extensive experience in the medical device industry with a focus on systems testing/automation. I am highly skilled in LVOOP and Actor Framework. Please see my LinkedIn for details and references.

https://linkd.in/mikele

I can be reached at mike.q.le@gmail.com for inquiries.

17 hours ago, smithd said:

Probably not that helpful but just in case you weren't aware of this, someone out there already made a decent looking tab xcontrol:

https://decibel.ni.com/content/docs/DOC-21668

I swore off XControls because they don't play nicely with classes. I untangled one too many corruption issues from using an XControl with a class...

I'm trying to create functionality similar to browser tabs. The main containing VI is a split pane with a tab control in the top pane and a subpanel in the bottom pane. If the user hits a "close" button for a given tab, I want to stop that VI's execution and (if it's currently being displayed) unload it from the subpanel.

I wanted the framework to be as flexible as possible, so even programmers unfamiliar with Actor Framework could use it to launch any VI into a tab simply by feeding in a path name or reference.

Basically I need a way for the VI to detect if it's "done." When it's been torn out of the Tab Container into a separate dialog, everything's fine. But when it's "x'd out" as a subpanel, then I don't know what option I have other than explicitly defining a reference for it (such as by launching it as an Actor and restricting the framework to only loading Actors).

Hi all,

So I'm trying to create a general use UI framework. One of the things this framework can do is load VIs by file path into subpanels or dialogs, then switch the behavior of the launched VIs between subpanel and dialog.

If the VI is currently running as a dialog and is closed, then cleanup is easy: I use the "Panel Close" event.

But for the subpanel case, I don't know if there's a handy event ready like that. Any suggestions? I want the framework to be as generic as possible.

If I can't come up with a good solution I might just require that all subpanel VIs being run like this must be an Actor and simply use a Send Stop Msg.

Thanks.

placement of a fixed maximal number of replicas of the element cluster on FP, and visibility of those needed (will become inconvenient for large numbers)

I've used this solution before; how many elements are you looking at and what do you mean by "inconvenient"? I've been able to do it with an array of ~50 elements with no problems. I find the cluster elements automatically by searching through the main cluster's sub-references.

If you're talking hundreds or thousands of references then it would be slow to start up, but if it's in the dozens, I don't notice a performance hit.

So I just started trying to submit some activities for the "CLA-R by points" program.

Does anyone know what's going on behind the scenes, or why there have been so many delays? Is NI still planning on supporting it? Based on the comments I'm reading on the recertify board and a few conversations with other CLAs, it seems like things have been slow for a good long while.

I guess there was a brief period last year when they were responsive, but then the replies have slowed down to a crawl again?

I ran into this same issue recently. It happened right after I added a DVR containing a typedef to the private data of one of my classes. Do you know if you did anything like that beforehand? What do you think fixed your code before and after the rewrite?

Look just in the enabled case.

I actually did try making a simplified version but I couldn't get the error to occur there. So there's something slightly more subtle going on with the actual implementation.

Also take the time to recreate your personal configuration as much as possible on a new LabVIEW install, exercise where the settings are beforehand so you don't loose time when configuring your machine on which you do the exam.

I'm not sure if this is still permitted, but when I took the exam I was allowed to bring a copy of my LabVIEW INI file. Definitely recommend asking your proctor if this would be all right.

Named WF Array Project.zip

I created a project that demonstrates what I'm trying to do and the error. I'd really appreciate it if someone familiar with the Advanced TDMS palette could take a look.

This was coded in 2013SP1. If you need it back-converted, let me know.

Sorry about the file hierarchy, the project is located here:

Workspaces\V12000\_V12000 Common Labview Code\Named WF Array\Named WF Array.lvproj

That was a nasty one that got me all the time.  If you can isolate it like that user we can get NI working on it, or testing it on different versions of LabVIEW.  What version are you using for this by the way?

No, I'm trying to write each channel separately as a 1D array, using the "Set Next Write Position" function to select channels.

I'm using 2013SP1.

Let's make some (very) basic troubleshooting: have you used Advanced Open with "enable asychronous?" = TRUE? And then used VIs from TDMS Advanced Asynchronous Pallete to read/write in all your processes?

Yes, asynchronous is set to True and I'm using the Advanced palette for all subsequent read/writes.

For now I've given up on trying to use multiple references and am just trying to get a single reference to work. Even here I'm running into problems.

I was converting to Extended Precision and then back to Double, but "Always Copy" is probably the better fix. Thanks!

I've attached a VI that illustrates some weird behavior with an Advanced TDMS Write node. I have a work-around but figured it was bizarre enough to share with the group.

Basically, trying to input a 1D double array from a "Split 1D Array" node causes a broken arrow in some situations.

Advanced TDMS Write Polymorphic with Broken Wire Behavior.vi

Hi guys,

So I have an application that uses TDMS for data-logging. There's a continuous memory leak as I write new data. It's alleviated somewhat by setting disk cache high for each channel, but as I'm acquiring data continuously over long periods of time, this isn't a great long-term solution.

I've tried switching over to the Advanced TDMS palette, but I'm having a lot of trouble getting an implementation going. A single TDMS file is accessed concurrently by multiple processes. Ideally, I want each process to open its own reference to the file. This wasn't a problem with the standard TDMS palette, but I'm getting errors with the Advanced palette.

For example, error -2539 states:

"LabVIEW:  This file cannot be written to, because it is opened and locked by another thread or process. This typically happens when a file is written by a hardware driver, for example NI-DAQmx."

Is concurrent access not allowed in the "Advanced" palette? Or do I need to do additional work in the Open step to allow concurrent access?

I find myself in this situation a lot, where I have an Actor that inserts itself into a subpanel. I want to look at what's going on in the Actor Core block diagram.

Typically I'd stick a breakpoint there so that the particular Actor clone's BD will pop up. But in that case, the front panel also opens, which very often leads to buggy behavior or errors when the Actor later tries to stick itself into a subpanel.

Anyone have some workaround suggestions for this? I run into the problem a lot and always slug through somehow but I figure someone's got a better procedure.