messenger library Instructional videos on YouTube

[Laboule]

Hi James,

I'm using your framework for my project, and I really enjoy the functionalities and the usability.

But, I just upgraded from LV 2015 (with Messenger Library 1.8.3.82), to LV 2017 (with 1.9.6.99), and I met the Error 1003 issue, which seems to be linked with the issue 9 you're pointing here.

As far as I have a Main vi (wich was ActorNR) in charge of launching a lot of other actors. I just put it in non NR, and the issue is effectively resolved.

I see on the Issue 9 link that you're currently working on changing the Launching of NR actors.

Do you plan to release a new version soon? (btw, the workaround is acceptable)

Thanks.

[drjdpowell]

I'm trying it out on my own projects at the moment, but I intend to release it.  I could post a copy here if you want to try it.

[Laboule]

Hi James,

I don't need a copy for the moment as far as your workaround is doing the job.

On the other hand, I'm using your framework on RT Target.

Until now, I was only working in debug mode, and now would like to build an RTEXE.

During build process, I get an error at save step :

A VI broke during the build process from being saved without a block diagram. Either open the build specification to include the block diagram of that VI or enable debugging to include the block diagrams of all VIs in the build. Report this error to National Instruments technical support.

C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\drjdpowell\Messenging\Action MSG\Async Execute Shell.vi

Following the NI Kb : https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P826SAC

I uncheck "Remove block diagram" for my dependencies, and the build process goes well.

But, when I execute the RTEXE, an error on Async Execute Shell.vi is raised :

Error 1003 occurred at Error in launching "Logger(X)": Open VI Reference in Async Action.lvlib:Action.lvclass:Async Execute Core.vi->ReferenceMonitor.lvclass:Send Message when reference destroyed.vi->Parallel Process.lvlib:Startup type 2.vi:6480001->Actor Template Support.lvlib:Actor Startup.vi:7070010->Logger.lvclass:ActorNR.vi->Actor type2.lvclass:Actor.vi:6640001->Dynamic Launch Shell.vi:5450003->Dynamic Launch Shell.vi.ACBRProxyCaller.50C00004

Possible reason(s):

LabVIEW:  The VI is not executable.  This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

Async Action.lvlib:Async Execute Shell.vi

Do you have an idea about why this VI is broken during build process, and a potential idea on the intended steps for making this working well ?

Edit :

I finally succeeded to make evrything working when I also uncheck "Disconnect Type definition", "remove unused members of project libraries", and I unchecked "Remove block diagram" for my main VI too. (I didn't want to enable debugging).

What I finally don't understand, is not about your framework, but about this error 1052 during build process. What does that exactly mean ?

Thanks. Regards.

Olivier

Edited July 5, 2018 by Laboule

[drjdpowell]

I suspect one of your actors, or something it calls, is broken in the build.  "Async Launch Shell" is what calls all the actors, and any one being broken will throw an error like this.  What I would do to debug is build all my actors as separate EXEs.  Even if they don't do anything when run by themselves they should at least run.  See if you get an error in building one of them.   Unfortunately, debugging EXE problems is very painful and time-consuming.  You could try re-asking your question on the main "Messenger Library" thread, as other developers who use it on RT have posted there and may have advice.

Edited July 5, 2018 by drjdpowell

[Laboule]

Hi James,

You're right, I should have written on the other thread for not polluting this Topic. But now it's done, I would like to close this with the solution of my problem.

Actually, I had a kind of corrupted VI, not easy to see, and not found just building each actor independently. I just realized that something went wrong in my code behavior, and apparently, the VI didn't executed at all (always returning default values), but not easy to debug as it was a reentrant SubVI.

I finally rewrote this VI from scratch, and also did a mass compile (because I had a 1min freeze of LabVIEW each time I stopped my main VI, and that created insanity errors  https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9QYSA0 )

Everything went back nomal after that, and I'm now able to build my Applications without removing Block diagrams.

Btw, I realized when unchecking "Remove unused members of project libraries", that you have a broken VI in one of your lib : "Extract Variant to Data.vi" from SendMSG.lvlib

Regards

[kronoseleven]

@drjdpowell, thanks for the impressive framework and hard work!

I'm attempting to wrap my head around the TCP implementation example (the zip files from your post above on March 14th 2016) of the messenger framework and am having some difficulty...

The example works out of the box when both ends are run locally, however trying to run the server on a laptop and client on my workstation, I ran into an error:

followed by

After doing some debugging (trying to follow the call chain through lots of abstraction) I discovered that one of my breakpoints had caused it to work!

I tried changing the timeout constant in Create.vi (of RemoteTCPMessenger.lvclass) that is passed to the "SendMSG.lvlib: Query.vi" from 3sec to 15s and the client will now connect to the server everytime without error, sometimes taking as long as 16+ seconds to start showing data from the server on the client front panel.

I can reduce the timeout down to 11sec and still end up with ~16s worth of a wait for data to show up.

My first question feels like a dumb one, as I can't even find the code that might answer my question, my search stops at RemoteTCPMessenger.lvclass:Send.vi where the class implementation choice leads me right back to the same diagram.  

What causes this wait?   

I also wanted to ask if you had any diagrams or documentation for this great framework, it's obviously very capable and I want to use it for that reason but feel like I need to know more about what's going on under the hood should I run into trouble in a new implementation.

Thanks!

 

[drjdpowell]

This is Issue 34, I think?

[kronoseleven]

Looks like it to me, where is the Get LV Version vi for me to be sure? I searched and didn't get any results...

thanks!

[drjdpowell]

Are you using the debug tools?   Such as Tools>>Messenger Library>>Actor Manager, where you can open the diagram of any running actor:

 

Here I'm running the TCP example included in Messenger Library.

You can open the TCP Client actor and see where it handles the message:

 

Edited May 5, 2020 by drjdpowell

[drjdpowell]

An annotated handling of the "From Starter: Connect to service" message.   The Negotiate Version subVI (which talks to teh Server) is taking longer than the default timeout.

 

 

Edited May 5, 2020 by drjdpowell

[kronoseleven]

 

Thanks for the replies, and admittedly I was not using your actor manager tool- Firing that manager up I found the tcp primitive you pointed out immediately.  

Seems I wasn't fast enough to reply, poking down a bit further it seems like the TCP read here:

takes a considerable amount of time the first go around... after which it executes as fast as expected.

If the server is running and passing data why would this vi be waiting?  Assumign the sever is putting more than 4 bytes on at a time...

thanks again!

 

 

[drjdpowell]

Can you run a standard LabVIEW TCP example between you two machines?  That would tell me if the slowdown is in Messenger Library itself, or in the lower level TCP layer.

[kronoseleven]

3 hours ago, drjdpowell said:

Can you run a standard LabVIEW TCP example between you two machines?  That would tell me if the slowdown is in Messenger Library itself, or in the lower level TCP layer.

Good idea, I'll do this and post up!

 

edit:  I'm having some issues with the example, makes me think it may be due to the particular network setup I have?  I'm gonna try with another box to see if it makes a difference.

 

edit2: pretty sure there's an issue with having multiple NIC's on different subnets... my second computer I tried this on was an old win7 box and I cant get VIPM2020 to run so I'm loading onto a laptop for now for another test

Edited May 5, 2020 by kronoseleven

[kronoseleven]

So I ran the Simple TCP example from NI between my workstation and a few computers.  I think having your connection on a different NIC (than your default route) might be causing the trouble I'm seeing with this example.

With Simple TCP Example, I'm getting between 5-90ms max execution time on TCP read here with max lookup:

 

 

Long story short (I ran into a ton of unrelated issues with the 3 computers I tried here)- I think the longer delay could be due to having multiple NICs on my workstation, and that I was trying to talk to a client on the non default route (meaning my internet comes from 192.168.1.0/24 and I was trying to talk to a client on 10.1.1.0/24).

With the client on the same default route (not on my workstation), I'm now seeing between 2-2.5 second delay before the client seems to start rx'ing data with the messenger example.

I'd like to try to get a better measurement than my stopwatch but my first attempt to push this re-entrant vi fwd and show values didnt go well... And I accidentally saved some of the dependencies under LV2020 so I have to go roll those back before I can try to reverse what side the client runs on.

edit: with roles swapped the client picks up on it faster than I can adjust to stop the timer, I'd say well less than quarter of a second...  

edit2: RemoteTCPMessenger.lvclass has an exec time between 50-100ms 

Edited May 7, 2020 by kronoseleven

[Neil Pate]

20 hours ago, kronoseleven said:

So I ran the Simple TCP example from NI between my workstation and a few computers.  I think having your connection on a different NIC (than your default route) might be causing the trouble I'm seeing with this example.

With Simple TCP Example, I'm getting between 5-90ms max execution time on TCP read here with max lookup:

 

 

Long story short (I ran into a ton of unrelated issues with the 3 computers I tried here)- I think the longer delay could be due to having multiple NICs on my workstation, and that I was trying to talk to a client on the non default route (meaning my internet comes from 192.168.1.0/24 and I was trying to talk to a client on 10.1.1.0/24).

With the client on the same default route (not on my workstation), I'm now seeing between 2-2.5 second delay before the client seems to start rx'ing data with the messenger example.

I'd like to try to get a better measurement than my stopwatch but my first attempt to push this re-entrant vi fwd and show values didnt go well... And I accidentally saved some of the dependencies under LV2020 so I have to go roll those back before I can try to reverse what side the client runs on.

edit: with roles swapped the client picks up on it faster than I can adjust to stop the timer, I'd say well less than quarter of a second...  

edit2: RemoteTCPMessenger.lvclass has an exec time between 50-100ms 

I do not know the details of this messaging protocol but I can say that if the TCP/IP transmit packet sizes are small Windows will, by default, wait a bit to see if there is any more data to be sent so it can transmit it a bit more efficiently. See here.

This is usually more annoying than helpful.

Happily it can be turned off. Take a look at the TCP_NoDelay VI in this library. I did not write it and I am not entirely sure where I got it from but it works really nicely.

 

Win32 Util.zip

Edited May 7, 2020 by Neil Pate

[LogMAN]

16 hours ago, Neil Pate said:

I did not write it and I am not entirely sure where I got it from but it works really nicely.

You probably got it from this KB article (also includes VIs for other platforms): https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019NZfSAM

[kronoseleven]

@Neil Pate Thanks for the suggestion! and the link to the KB @LogMAN

I grabbed that library and looking into the no delay vi I see setsockopt is the call into wsock32.dll...

here's some more info I found, not sure which way I'll try to implement yet but feel like I might want to tread carefully or at least be sure I know how to unset this once I change it.  

https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-setsockopt

I also found this site showing the toggling of it via registry which might be my first attempt:

https://www.fixwindowserrors.biz/blog/disable-nagle-algorithm-in-windows-10

Looking in the registry I realize this is actually a setting on a per-nic basis, so I guess I will apply the change to all nics for this test since I think it may be related to windows looking for the client...

I'm going to set up the same test and run it in both states to see if there's any difference. 

 

 

 

[Neil Pate]

9 minutes ago, kronoseleven said:

@Neil Pate Thanks for the suggestion! and the link to the KB @LogMAN

I grabbed that library and looking into the no delay vi I see setsockopt is the call into wsock32.dll...

here's some more info I found, not sure which way I'll try to implement yet but feel like I might want to tread carefully or at least be sure I know how to unset this once I change it.  

https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-setsockopt

I also found this site showing the toggling of it via registry which might be my first attempt:

https://www.fixwindowserrors.biz/blog/disable-nagle-algorithm-in-windows-10

Looking in the registry I realize this is actually a setting on a per-nic basis, so I guess I will apply the change to all nics for this test since I think it may be related to windows looking for the client...

I'm going to set up the same test and run it in both states to see if there's any difference. 

 

 

 

I am pretty sure it is on a per socket basis. Setting that should have no effect on any other applications.

[kronoseleven]

@Neil Pate  That's a real good point, whereas the reg tweaks are made accross the board I presume, but I'm not 100% sure where to put the nodelay vi.

 

I will try it here:

edit:

I put the no delay vi in write and read of the TCP Messenger library and did not see any effect in this test. @drjdpowell would you reccommend a better call spot? 

a few notes:

-latency measurements were made with phy stopwatch rounded to tenth

-10.3.3.3 has 3 active NICs, 10.3.3.1 has 4 active

-TCPNoDelay.vi was place in both write and read of TCP Messenger.lvlib vi's

*had to increase the timeout value mentioned earlier in this thread... 

 

Edited May 8, 2020 by kronoseleven

[drjdpowell]

I strongly doubt TCP delays are your initial problem.   These are designed delays of up to 200ms, so they can't cause a many-second delay.

[LogMAN]

@kronoseleven What is the ping between your clients?

As @drjdpowell mentioned, 16.2 seconds is not normal. The no-delay function won't do much of a difference.

[Neil Pate]

1 hour ago, kronoseleven said:

@Neil Pate  That's a real good point, whereas the reg tweaks are made accross the board I presume, but I'm not 100% sure where to put the nodelay vi.

 

I will try it here:

edit:

I put the no delay vi in write and read of the TCP Messenger library and did not see any effect in this test. @drjdpowell would you reccommend a better call spot? 

a few notes:

-latency measurements were made with phy stopwatch rounded to tenth

-10.3.3.3 has 3 active NICs, 10.3.3.1 has 4 active

-TCPNoDelay.vi was place in both write and read of TCP Messenger.lvlib vi's

*had to increase the timeout value mentioned earlier in this thread... 

 

Yeah as others have pointed out, the nodelay technique is for getting millisecond type response times. Something else is going on in your system.

[kronoseleven]

@LogMAN

 

I also killed all firewalls on both nodes... and there's no switch or router involved in this case...

[LogMAN]

Very strange. Ping looks fine. TTL=128 also indicates that the machines are on the same network, so packages should send fine. Are you able to copy large files between the systems with reasonable speed?

Also, you can use Wireshark to monitor traffic between your machines. That way you can check if a package gets lost, resend or blocked by other data.

In the past I had trouble with cheap NICs that weren't able to keep up with many small packages because of checksum offloading. This was particularly problematic on Windows 7 and seems to be fixed on Windows 10. You can try disabling it in your NIC settings. Note that there are multiple offload options.

[kronoseleven]

>Are you able to copy large files between the systems with reasonable speed?

@LogMAN interestingly enough... dumping a 1G+ file in a shared folder I'm only getting 11MB/s  and the read (for crc of file copied) was 10MB/s  

I only see the delay at the initial connection, but now in mentioning that I feel the need to go make sure all the data coming in isnt 16 seconds behind....

 

 

 

Edited May 8, 2020 by kronoseleven