Separate VI Operating on Same Object

[smithed]

Actually I'd argue the same is true for both UDP and TCP, at least within the context of LabVIEW's APIs. A successful send on a TCP write only means it reached the LabVIEW buffer. It might fail to send later, but you won't know how far it got. Being sent at the socket layer just means the other OS got it, it doesn't mean theres an application reading out the data (not for a while, due to the various buffers). Once its in memory, many people (myself included) have a variety of routing components in their code which might lose or mishandle the data, etc. 

I actually just saw one case of this trying to debug some streaming code -- my pharlap system insisted the connection was still good, while my windows host was continuously re-trying connections. It kept writing and writing and writing and LabVIEW never once told it the connection was bad, but no client got the data. I think this issue is related to the hardware it was on (I had a similar problem with NI vision failing to detect a disconnected camera on this computer) but nevertheless it happened 😞

For what its worth, my solution to the above in general is that anything I want to be reliable goes through an end-to-end request response-protocol (http in this case but it doesn't matter), and by end-to-end I mean the loop I'm trying to talk to has to be the one to get the message, rather than some intermediary.

[drjdpowell]

I meant resend-command-on-timeout isn't a strategy for a tcp connection, as the resend will always fail if the first send failed.  Though if one has to reestablish a broken tcp connection, then one is in the situation of not knowing what messages failed to get through.

---

@smithed wrote:

For what its worth, my solution to the above in general is that anything I want to be reliable goes through an end-to-end request response-protocol (http in this case but it doesn't matter), and by end-to-end I mean the loop I'm trying to talk to has to be the one to get the message, rather than some intermediary.

---

A solution I strongly agree with.  And more than just get the message; the final loop should respond after handling the message, and report the success or failure thereof.

[patrick.wright · Accepted solution]

Thank you for all the good feedback and advice. 

After reading through all your comments I came up with a possible solution.  The actors which I want to synchronize and order will be nested actors of a controller root actor.  Each nested actor will define a set of normal messages and abstract reply messages for the caller (i.e. controller) to override and essentially "register" itself to the nested actor.  These "reply messages" will tell the controller to execute its next step.  The controller will be implemented as a state machine where each reply messages (or any other message) will change the state based upon the current state and expected input.  I also toyed with the idea of creating "register for messages" methods in the actors (which by themselves are messages) that would allow different root actors to "register" themselves into an array within the nested actors so that they send reply messages to all attached actors; which I think is pretty much redesigning an event registration framework.  In addition, any GUI VIs will be updated via user events sent by the controller root actors.

That being said, the more I have worked with LabVIEW on this project, the more I am realizing it is extremely difficult to naturally fit the concepts required to develop a multi-window desktop application in it.  Event if I manage to do so, the code will end up being very difficult to follow and maintain.  It looks to me as if LabVIEW more naturally works with algorithms that are similar to hardware where dataflow and wires makes sense.  For this application, I think I am going to switch to good old C++.

[drjdpowell]

---

---

---

@patrick.wright wrote:

Thank you for all the good feedback and advice. 

After reading through all your comments I came up with a possible solution.  The actors which I want to synchronize and order will be nested actors of a controller root actor.  Each nested actor will define a set of normal messages and abstract reply messages for the caller (i.e. controller) to override and essentially "register" itself to the nested actor.  These "reply messages" will tell the controller to execute its next step.  The controller will be implemented as a state machine where each reply messages (or any other message) will change the state based upon the current state and expected input.  I also toyed with the idea of creating "register for messages" methods in the actors (which by themselves are messages) that would allow different root actors to "register" themselves into an array within the nested actors so that they send reply messages to all attached actors; which I think is pretty much redesigning an event registration framework.  In addition, any GUI VIs will be updated via user events sent by the controller root actors.

That being said, the more I have worked with LabVIEW on this project, the more I am realizing it is extremely difficult to naturally fit the concepts required to develop a multi-window desktop application in it.  Event if I manage to do so, the code will end up being very difficult to follow and maintain.  It looks to me as if LabVIEW more naturally works with algorithms that are similar to hardware where dataflow and wires makes sense.  For this application, I think I am going to switch to good old C++.

If you have strong C++ skills then you should go with what you are good at.   Were you to stay in LabVIEW you really should look further than the Actor Framework, which only one many alternate frameworks.   Creating multi-window desktop applications is my bread-and-butter using "Messenger Library", which has easy-to-use registration messages and replies (videos of a small example project).    The DQMH is also a very popular framework to investigate, which has excellent documentation.

[Mark_Yedinak]

As drjdpowell stated, if C++ is your strong point then use that. However I would disagree with your statement that LabVIEW is not capable of doing the job. I have developed many very large, multi-window, distributed systems using LabVIEW. It is definitely quite capable.