messenger library Instructional videos on YouTube

[drjdpowell]

I've started to make some instructional videos on YouTube for my Messenger Library.   I was inspired by Delacor's nice videos on their new DQMH framework and also by Steve Watts' CSLUG channel.  Any feedback appreciated.

 

James

[Yair]

These are great, but they tend to drag on a bit too much. I would suggest considering either editing or planning them carefully enough so that you have a higher SNR. For instance, the third video has a good explanation of the value of relabeling messages, but it comes after a pretty long video.

 

Also, you might wish to start with a video about the basics of the framework. As it is currently, it focuses a lot on actors and less on messengers.

[drjdpowell]

I’m more going for SER, Signal-to-Effort Ratio, at the moment as I have limited time to spend on things like editing.  Something is better than nothing.  And a programming instructional video that doesn’t drag is a pretty high bar (not sure I’ve seen many of those!).

[LogMAN]

Is it best to ask questions in this thread? Hard to tell for me, however YouTube is just not the place for it

 

For now this is the best place, so here I come:

 

@drjdpowell: In your last video you related to the MVC (or CMV as you called it). As I understand it, an Actor can actually be any combination of Model, View and Controller.

 

In text-based programming languages (like C# for instance) it is common to separate them entirely into separate classes (best case would be zero-coupling).

In LabVIEW I think it is okay to separate the Model, but keep the View and Controller close together, as they are bound by design (FP/BD). This applies, unless the View and/or Controller is some external hardware or something alike.

 

What is your recommendation on this?

How did you combine them in your actual projects?

 

@everyone: Please feel free to give your thoughts on this too.

[drjdpowell]

Most of the web references to MVC is about frameworks and architecture, where the M, V, and C are distinct and clearly separable things.  I’m less interested in how to define boundaries between things than in flow.  Directions and arrows.   The User exerts control on the state of the application.  The User views the state of the application.  

 

Here’s the Wikipedia diagram for MVC

 

 

If you search, you’ll be confused by seemingly different diagrams, which divide up Controller and View differently, but they all have the key flows between User and Model.  I follow the principle, rather than trying to have specific application layers identified as M, V, or C.  

 

— James

 

PS>  a link to the video referenced.

 

 

 

[eberaud]

CLA practice exams are good examples of how the MVC diagram can be applied.

[LogMAN]

Most of the web references to MVC is about frameworks and architecture, where the M, V, and C are distinct and clearly separable things.  I’m less interested in how to define boundaries between things than in flow.  Directions and arrows.   The User exerts control on the state of the application.  The User views the state of the application.

...

If you search, you’ll be confused by seemingly different diagrams, which divide up Controller and View differently, but they all have the key flows between User and Model. I follow the principle, rather than trying to have specific application layers identified as M, V, or C.

LabVIEW (or rather 'G') is entirely flow-based, so this makes sense. This answers my question to some extend. I actually like to define boundaries between things as clear as possible in order to make my sources accessible for the other developers in my team. So as an example: If my Actor acquires some data and provides it for the outside world, it might have its own visual representation and maybe you can control it (so basically MVC in one Actor). On the other hand I require multiple visual representations to fit the data on different screen resolutions (pure VC units). There are boundaries I have to define. I can either have a 'default' resolution in my core Actor with additional VC Units, or the core Actor is never shown and all resolutions are from separate Actors as VC units.

I guess I'll have to play around and think about this for a bit.

 

CLA practice exams are good examples of how the MVC diagram can be applied.

Thanks for the hint, I'll look into them.

[drjdpowell]

 So as an example: If my Actor acquires some data and provides it for the outside world, it might have its own visual representation and maybe you can control it (so basically MVC in one Actor). On the other hand I require multiple visual representations to fit the data on different screen resolutions (pure VC units). There are boundaries I have to define. I can either have a 'default' resolution in my core Actor with additional VC Units, or the core Actor is never shown and all resolutions are from separate Actors as VC units.

You can also treat the core Actor’s Front Panel as the “debug†UI, since it is easy to add a lot of indicators.

 

Personally, I usually have a lot of actors that are MVC-in-one-actor for their own part of the application.  So ‘temperature control’ actor probably has control/view of the SetPoint, PID and other parameters, and can be inserted into a subpanel in the main app.  Then additional Views or Control can come from elsewhere (a summary screen of many temperature controllers, say) but these VC tend to deal with smaller subsets of “Model†(such as just the SetPoint).

[OlivierL]

LabVIEW (or rather 'G') is entirely flow-based, so this makes sense. This answers my question to some extend. I actually like to define boundaries between things as clear as possible in order to make my sources accessible for the other developers in my team. So as an example: If my Actor acquires some data and provides it for the outside world, it might have its own visual representation and maybe you can control it (so basically MVC in one Actor). On the other hand I require multiple visual representations to fit the data on different screen resolutions (pure VC units). There are boundaries I have to define. I can either have a 'default' resolution in my core Actor with additional VC Units, or the core Actor is never shown and all resolutions are from separate Actors as VC units.

I guess I'll have to play around and think about this for a bit.

 

Thanks for the hint, I'll look into them.

 

Hi Logman, As you suggest, VC can (should?...) be merged into one VI in my opinion.  We design most of our code with VC merged into one VI (actually offen multiples VI for different interfaces) while the Model is really just doing its core task.

 

Also, we try to not use the GUI of the Model/Actor directly so it can run in a higher priority thread instead of in the UI thread. It makes a difference for us in some cases on Windows and it helps us when using our libraries on a Real-Time targets as we already have the all GUI clearly separated and are able to easily debug from any PC (assuming your actors support some kind of TCP communication) even when the Target is running independently.

[drjdpowell]

Attached is the demo project developed over the Actor to Actor communication and Controller-Model-View videos.  LabVIEW 2015.

 

Messenger Library Demo.zip

[drjdpowell]

I’ve added a couple of more videos about the Register-Notify system used in Messenger Library.   A couple of people identified Notifications as something I had not explained sufficiently (especially the difference between an “event†and a “state†notification).  So I have added Register Notify and Notification “Hookup†of a dynamic actor (and generic messages).  The later video also shows a technique of handling messages to do with multiple controls in a single Variant-based case.

 

Updated example code:Messenger Library Demo.zip

 

 

I’ve also made an initial Introductory video to SQLite in LabVIEW.

[jimc1041]

Your instructional videos on the Actor to Actor communication are very informative. However, I had trouble when I tried to modify the examples to utilize your TCP messengers such as would be required for a remote cDAQ/cRIO system. Do you have any examples of this nature?

[drjdpowell]

On March 13, 2016 at 1:48 AM, jimc1041 said:

Your instructional videos on the Actor to Actor communication are very informative. However, I had trouble when I tried to modify the examples to utilize your TCP messengers such as would be required for a remote cDAQ/cRIO system. Do you have any examples of this nature?

See this new video on youtube.  I modified the demo so that 'Instrument' is running on a separate project behind a TCP server, with 'Top Level' connecting as a client via a Remote TCP Messenger.  I also showed the use of an 'Address Watchdog' to shutdown 'Top Level' if ‘Instrument' disconnects.  

 

Here is the code (start the server first):

Messenger TCP Server.zip

Messenger TCP Client.zip

 

I think I forgot to mention it in the video, but note that the Client project does not load the code of “Instrument", and the Server Project does not load the "Top Level" code.  Thus, nothing is locked and you can edit freely (this is a problem in some architectures).  This is done internally by the TCP server/client actors by keeping all reply addresses in flattened form on the remote target.  If you use custom probes you will see most replies or registrations become something like "Route back to QueueMessenger and then to Flat", which is confusing but means "send back to the TCP actor running this connection, then via TCP to the remote system, and then to this address (unflattening it first)".  Please note that only Reply Addresses are converted; you cannot send an address as data in a message and have it work on the remote system (attach it as a Reply Address instead).

 

Please note that I have yet to do a Real-Time project with Messenger Library.  I do have a current project using modified TCP actors to communicate with a non-LabVIEW client from another developer (using JSON messages), but that isn't the same.  So please don’t be afraid to ask for help or to make suggestions.  Please see if you can run this example with ‘Instrument' on the Real Time system.

 

-- James

 

 

Actor Manager for this TCP example.  Note that the 'Control Server' actors are entirely unmodified, and have no knowledge that they are talking to 'Instrument' via TCP.   Because everything is by message (no DVRs, no Action Engines) it is easy to convert things to remote operation.

Edited May 16, 2016 by drjdpowell

[jimc1041]

Thank you for your quick response.  I do not have access to my cDAQ system right now.  I will have to let you know how it works later.  I really like the messenger library you have developed and I am just learning about it's full potential.  Thanks for your work on this.

[bmare]

Hi,

 

I am doing a project using your messenger library as it seems very interesting and easy to use.

However, I do have a question about the reentrant actors.

I want to be able to launch multiple instances of the same actor, and afterwards choose to which one of the instances I want to send a message.

I tried to put the actors in an array after launching but that doesn't seem to work.

Is there a way to do this?

[drjdpowell]

Hi,

 

I am doing a project using your messenger library as it seems very interesting and easy to use.

However, I do have a question about the reentrant actors.

I want to be able to launch multiple instances of the same actor, and afterwards choose to which one of the instances I want to send a message.

I tried to put the actors in an array after launching but that doesn't seem to work.

Is there a way to do this?

Is your actor reentrant?  The VI should be named “Actor.vi†(rather than ActorNR.vi) and set as shared-reentrant.  If that isn’t the problem please post an image of your launch code.  I use arrays of actors in some of my projects (and the library has VIs meant specifically to work with arrays) so it does work.

[bmare]

Hi

 

I made a sample project to test the array and now it works. 

Seems I made some mistakes in the wiring. 

In the attachment you can see how I did this using the DEV template. 

[drjdpowell]

Seems I made some mistakes in the wiring. 

I suspect you had some error in calculating the index.  â€œInsert into array†will fail if you have the wrong index (so inserting at index 3 in a three-element array will produce a four-element array, but inserting at index 4 will silently fail).   I would use Build Array instead.

[bmare]

Alright. 

Thanks for the advice!

[drjdpowell]

On 13/03/2016 at 9:56 AM, drjdpowell said:

See this new video on youtube.  I modified the demo so that 'Instrument' is running on a separate project behind a TCP server, with 'Top Level' connecting as a client via a Remote TCP Messenger.

...

Please note that I have yet to do a Real-Time project with Messenger Library.  I do have a current project using modified TCP actors to communicate with a non-LabVIEW client from another developer (using JSON messages), but that isn't the same.  So please don’t be afraid to ask for help or to make suggestions.  Please see if you can run this example with ‘Instrument' on the Real Time system.

I've just got the evaluation kit for an sbRIO with RT Linux.  I ran the example with 'Instrument' on the sbRIO; I found that the OpenG zlib compression library did not deploy to RT Linux.  So I had to disable zlib with the following Project Conditional Disable: ZLIB_Compression == OFF

Otherwise I didn't make any modifications.  But I (so far) have not been able to get my custom probes working on RT, so I'm investigating other RT-usable tools.

-- James

[drjdpowell]

Here is my current RT version of the example project (to go with the newest version of Messenger Library).  To run the actor manager on the RT, you'll need to add it to the project (its in <LabVIEW>/project/Messenger Library).Messenger Library RT Test 2015.zip

[Mads]

On 18.5.2016 at 5:10 PM, drjdpowell said:

I've just got the evaluation kit for an sbRIO with RT Linux.  I ran the example with 'Instrument' on the sbRIO; I found that the OpenG zlib compression library did not deploy to RT Linux.  So I had to disable zlib with the following Project Conditional Disable: ZLIB_Compression == OFF

1. What version of OpenG Zip library did you try to install (it has to be done using the Custom Software Install feature in NI MAX by the way...)? I'm using it on NI Linux RT targets (cRIO-9030 and sbRIO-9651) without any problems (thanks a million Rolf Kalbermatter). Here is a thread where my initial request for Linux RT support was discussed.

[drjdpowell]

I didn’t notice the MAX install part, so that might be my problem.  Thanks.

[npap]

Hi, 

 I've installed version 1.9.6.99 on LV2015 f1 but i am unable to run either the original or the updated  Messenger Library Demo.zip. In both cases there are some differences from the code. 

I've run into the following problems. 

On original Messenger Library Demo:

I could not execute this at all. I had 1003 Error 1003 occurred at Open VI Reference in Actor type2.lvclass:Get Dynamic Launch Shell Reference.vi->Actor type2.lvclass:Launch inside Dynamic Launch Shell.vi->Actor type2.lvclass:Launch Actor.vi:1050001->Top Level.lvclass:ActorNR.vi

 

  On updated Messenger Library Demo, 

1) When I executed the Instrument Actor, the Metronome would not produce an event metronometick (so no updating). when I added a button and added an event case, it worked, so I guess the problem was with the Metronome. 

2) When I executed the Top Level actor, I got the error: Error 1003 occurred at Open VI Reference in Actor type2.lvclass:Get Dynamic Launch Shell Reference.vi->Actor type2.lvclass:Launch inside Dynamic Launch Shell.vi->Actor type2.lvclass:Launch Actor.vi:1050001->Top Level.lvclass:ActorNR.vi

3) (this is not so much of a problem), I could not understand the "new" class Control server, and how to use it. 

 

 

Thanks in advance.

 

[drjdpowell]

This is Issue 9, I think.  It's an annoying "pick-your-poison" issue.   The alternative is to accept the "locked-code" bug.   The problem is that an "ActorNR" non-reentrant actor can theoretically try and launch itself, and LabVIEW is rejecting that possibility by preventing the launch of any actor (including "Metronome") if an "ActorNR" is run from the run arrow.   

A workaround is to rename the "ActorNR.vi", either to "Actor.vi" (and change to shared-reentrant), or to any other name (this means they are no longer "launchable" but you can still run them from the arrow).

I may go to back to the design that has the "locked-code" bug with the next version, as at least that is more annoying than a true block, as you just need to reopen your project occasionally.  But if I can make time, I might be able to come up with a better workaround.

BTW, the newest Messenger Library now contains the non-TCP project (modified to work) as an example.

Edited February 2, 2018 by drjdpowell