Jump to content

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Laboule

Share this post


Link to post
Share on other sites

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 by drjdpowell
  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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:

image.png.4291f106f04a5c9576dce09df8d9da7f.png

followed by

image.png.c0c299923205654e3ca5b17f631058de.png

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!

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

1473147857_2020-05-0512_32_34-ActorManager.png.b0b98a42a7d3111395b14d312ebe2589.png

 

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:

1519500720_2020-05-0512_34_43-TCPClientActor.lvclass_Actor.vi_6640001(clone)BlockDiagram.png.ff09671b92d6ed8182a63c1eb3e3ce58.png

 

Edited by drjdpowell

Share this post


Link to post
Share on other sites

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.

 

 1539294186_2020-05-0512_34_43-TCPClientActor.lvclass_Actor.vi_6640001(clone)BlockDiagram.png.5d317f3019cb25121f7f8ae5681e45e0.png

Edited by drjdpowell

Share this post


Link to post
Share on other sites

 

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:

image.png.f90222f037a214ec1dc4cb552494e936.png

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!

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by kronoseleven

Share this post


Link to post
Share on other sites

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:

image.png.436eb8c66aaace3267effc3feec54fbb.png

 

 

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 by kronoseleven

Share this post


Link to post
Share on other sites
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:

image.png.436eb8c66aaace3267effc3feec54fbb.png

 

 

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.

image.png.e1d3780e025275bf52fad374f5d9fb60.png

 

Win32 Util.zip

Edited by Neil Pate

Share this post


Link to post
Share on other sites

@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. 

 

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

@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:

image.png.bfd2f20f30ae690f1fe1ef706232c00e.png

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

image.png.2734d9cab6d8357d24d06b942e7b3e56.png

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

 

Edited by kronoseleven

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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:

image.png.bfd2f20f30ae690f1fe1ef706232c00e.png

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

image.png.2734d9cab6d8357d24d06b942e7b3e56.png

*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.

Share this post


Link to post
Share on other sites

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.

image.png.7d89ad6f2d862d1dfed26c0b41cc197d.png

Share this post


Link to post
Share on other sites

>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 by kronoseleven

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By drjdpowell
      View File Messenger Library
      An extensive library for passing messages between parallel processes. Generalizes the communication method, allowing the message sender to use the method provided by the receiver. Supported communication methods include wrappings of simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.
      Communication patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates.  Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.
      An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..).  An "Actor Manager" debug tool is also installed under the Tools menu.  Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the Actor Model).
      ***Introductory Videos are on a YouTube channel.***
      ***A great summary of many Messenger Library sources, provided by Bob W Edwards***
      Original conversation on this work is here.

      Now hosted on the LabVIEW Tools Network (but note that the latest version will often be on LAVA)
      ***NOTE: latest versions require VIPM 2017 or later to install.***
      Submitter drjdpowell Submitted 11/27/2012 Category LabVIEW Tools Network Certified LabVIEW Version 2013 License Type BSD (Most common)  
    • By drjdpowell
      An extensive library for passing messages between parallel processes. Generalizes the communication method, allowing the message sender to use the method provided by the receiver. Supported communication methods include wrappings of simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.
      Communication patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates.  Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.
      An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..).  An "Actor Manager" debug tool is also installed under the Tools menu.  Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the Actor Model).
      ***Introductory Videos are on a YouTube channel.***
      ***A great summary of many Messenger Library sources, provided by Bob W Edwards***
      Original conversation on this work is here.

      Now hosted on the LabVIEW Tools Network (but note that the latest version will often be on LAVA)
      ***NOTE: latest versions require VIPM 2017 or later to install.***
    • By drjdpowell
      I’m hoping to add some sample projects to my “Messenging” package, and I thought it would be easy and instructive to rework one of NI’s templates, “Continuous Measurement and Logging”, as it is already somewhat actor-like with three communicating modules.  Attached is a (back-saved for 2011) copy of the NI project, with my version included (run “Main.vi” for the original, “Main.lvclass:Actor.vi” for my version). 
       
       I kept the basic functionality the same, but couldn’t resist changing some of the UI (in the old code, “Main” controls the UI; in the new code, published state messages from the Acquisition and Logging Actors set the UI).
       
      Continuous Measurment and Logging with Messenging.zip

       
       Any comments appreciated.   Is this example less clear than the NI original?  Why?  How could I improve it?
       
      In particular, is code like this (the most complicated interaction, I think) understandable without heavy documentation?  It’s a “Start Logger, then Start Acquisition, then Unset the Busy Cursor” three-actor chain message:

      I’m thinking of making a “Send Chain Message” subVI (that accepts arrays of addresses and message labels) to replace the above code.
       
      — James
×
×
  • Create New...

Important Information

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