Jump to content

Maksim Kuznetsov

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Maksim Kuznetsov

  1. Thank you for your feedback. The honest reason why I am asking is a hope that someone will tell me which approach from many is the better one. Every now and then I am having a dispute over this with my colleagues and I am always saying that typedefs create additional coupling, but I realised that I never understood what it actually means, it was like a rule I used throughout my projects. Now I am not sure if I was right or wrong, clearly I have a lack of knowledge. Maybe someone can share their approach and reasons behind it? Thank you!
  2. Hello James, There is a concept I am struggling to get my head around. For a long time I am following a method of not having typedefs in messages. Messages can contain various data and to make sure that the message is constructed correctly I have to consult the actor and copy the structure from it. Same applies for messages received. I believe this is called "zero-coupling". 1. If I am adding the actor reference to the VI, it brings all the dependencies of the actor to project, so I am becoming coupled to that actor, isn't it? (it is not like some generic reference) 2. Why in this case it is not advised to use actor's typedefs in messages (this could save time and less errors would appear during development)? 3. There is another method - to have a SubVI instead of typedef that will do the job of constructing (deconstructing) the message. But how is this different from using a typedef? SubVIs will also create more coupling. I have a feeling that my understanding of coupling is not full. It would be great to hear your thoughts about these points. Thank you! Kind regards, Max
  3. Thank you once again Dr. Powell for sharing this powerful approach. I can see it being used in "Metronome" actor (e.g. Set Period). And I already started to use it in my projects. If you don't mind I would like to ask you another question: I have an actor (A) that launches a sub-actor (B) to delegate some tasks to it. When sub-actor (B) publishes an event, actor (A) gets a message. However I would like to publish that message beyond actor (A). So that actors subscribed to actor (A) would also receive events from sub-actor (B). Currently my approach is to send Observer Registry of actor (A) to sub-actor (B) during initialisation. Then sub-actor (B) publishes its events into Observer Registry of actor (A) directly. Another idea was to republish the event from actor (A) when it gets the message from sub-actor (B). Neither of these methods feel right to me. The first one shares internal reference of the actor (A). The second method is not as efficient (receives, then sends again). How would you approach this?
  4. Hello, I have a little question about programming style. What do you think of using typedefs for message data? On the one hand when type changes in once place, all actors will get an update. On the other hand it creates additional coupling between actors. I am not sure what approach is better and why. Thank you!
  5. I am now thinking of creating PPL for a Messenger Library, that is the best solution. I remember 2 years ago you suggested: Creating a PPL and relinking VIs in existing actors to that PPL should work. However how would you approach creating the PPL that will also appear in LabVIEW palette for development (as it is now with Messenger Library)? I would like to distribute PPL to developers seamlessly without having them to dig into the PPL and look for particular VIs.
  6. Yes, Dr Powell, this is exactly what I was trying to do. Thank you for diagrams. I also realised it is not possible and shouldn't be possible based on this discussion: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-type-casting-between-classes-types-in-PPLs-lvlibp-s-or/idi-p/3136231?profile.language=en Why it was necessary? Due to how TestStand Interacts with LabVIEW application instances: http://www.ni.com/product-documentation/14335/en/ TestStand steps tend to use the same application instance as LabVIEW executable (based on Messenger Library), this is why steps that used Messenger Library from another location didn't work. I wanted steps to be easily distributable, so had to keep dependencies (including Messenger Library) next to them. NI suggests to keep LabVIEW steps in PPL, that didn't work for me because it changed the namespace of the library. However, as you suggested, also changing namespace of the actor I communicate to, worked! So now I have two PPLs with exactly same names, but with different contents. One with actor, second with steps. Additionally, to make TestStand use a different application instance I specified a project path for each step (it forces it to use another application instance). Then I continued my experiments and included steps directly into the Actor PPL and it also worked perfectly without having multiple PPLs. Just one Actor PPL, that has API VIs that are called from TestStand. So far so good, it works well. Thank you very much! It is a relief and I learnt valuable things. P.S. Sharing PPL Messenger Library should also work, it will involve a little bit of extra work.
  7. It is a good analogy. It is unfortunate that changing namespace affects the class names and hence brakes the communication. However for my particular task it is essential. I will try to remove the namespace from flattened address and see what happens. Thank you for all of your assistance and support. I highly appreciate it.
  8. I haven't done that because the main idea was to actually have a separate namespace for a ppl and for the executable. It is unavoidable.
  9. To eliminate the misunderstanding. I have 2 applications: One is a built executable, uses messenger library as is from VI package manager. Second is a ppl with one actor inside (possible on a completely different PC). I can't make these 2 applications communicate through a TCP messenger. I understand that PPL changes the namespace of all classes. Hence when flattening/unflattening messenger addresses the namespace is included. That is why communication doesn't work. To solve this I think I need to somehow remove the namespace when flattening and then add it when unflattening (in actor that runs from PPL). What do you think?
  10. Thank you for the link. But, the problem appear even if I just have a single Actor that uses dependencies from ppl. Basically as soon as "Messenger Library" is put in ppl or a library the TCP Messenger brakes (I can send message without reply, but I can't receive replies). Apparently PPL also creates a namespace for everything that is inside and that brings us back to your reply: Is there any easy fix that I can apply to make Messenger Library work from ppl and library? Kind Regards. Maksims
  11. Hi everybody. After couple of more days of thinking and trying, I managed to narrow down the issue to a very simple experiment. Making it work will solve the problem I've been facing for many days. Experiment setup: 1. Create a simple Actor with a TCPEventMessenger (server). Make it reply with some text to the incoming message. 2. Create another Actor that connects to the actor from step 1 (through TCP). Make it send a message (with reply). 3. Add actor from step 2 to project library. 3. Test both actors in development environment, they should communicate perfectly. 4. Create a packed library build specification for project library from step 3. 5. Now open the actor from the freshly built .lvlibp and try to run it. It should fail with a timeout error while waiting for a reply. This behavior doesn't make sense to me. Because when instead of building packed library I build an executable everything works perfectly. Why can't I build a packed library and make it work the same way. P.S. Packed library includes every dependency, same way as in executable. Any advice will be highly appreciated! Thank you in advance and happy new year! Kind Regards, Max
  12. I believe there is a misunderstanding and I am failing to explain correctly the issue that I am facing. Let me please try once again, if you still have patience. I prepared the following diagram: 1. TestStand Actor.exe is launched in LabVIEW Run-Time Server, hence the Messenger Library VIs will be loaded into memory. 2. TestStand Actor.exe runs the sequence file (with any kind of steps) using TestStand API. 3. Sequence File has some LabVIEW steps that are using Messenger Library VIs. LabVIEW Adapter in TestStand automatically uses the same LabVIEW Run-Time Engine Server as in step 1. Hence there will be a name conflict. Ideally I would build all of the LabVIEW steps into a packed library (as advised by NI). Doing that provides a namespace + puts all the dependencies into one file. However, this brakes communication in Messenger Library and steps become useless. Running steps without library produces a naming conflict in LabVIEW Run-Time Server.
  13. Unfortunately that didn't work. The same behavior appears as described in the initial post: "Send Message (without reply)" and "Receive Notification" work, however "Send Message (with reply)" doesn't. What I did was I created an .exe actor which receives and replies with a text message. Then I created a client actor that sends a message and waits for a reply. Source and Build for the client work perfectly. Then for a client actor I created a source distribution and included all dependencies in a library (that included Messenger Library). I also tried putting the client actor itself into a library, but still with no luck.
  14. Yes, you have a very good point here. Usually I follow this approach. However, TestStand Actor is allowed to load any sequence file through TestStand API. The sequence file itself sometimes calls LabVIEW code, which in my case by a coincidence use the same library that is already loaded by a Run-Time engine. For the sequence developer it is impossible to know that his steps will have a conflict in memory once deployed. Thank you for a suggestion about putting Actors and Messenger library under the library. It sounds like a potential solution, I will give it a go.
  15. Yes, the steps are source. I understand that ideally steps should be built and it can be achieved by building them into "packed library". But packed library automatically brake the communication (same as when changing the namespace of the Messenger library). Another possibility would be to build every step into an executable, but then returning errors, setting step input data would become more complex.
  16. Thank you for your reply. Indeed, I built a separate application (.exe) for TestStand. It is using the Messenger Library with TCP input messenger. Actors from other applications connect to TestStand Actor and run sequences, subscribe for sequence finished events, etc. That part works well. The conflict arises when the sequence file itself contains a LabVIEW step that connects to another actor (e.g. valve controller) and sends a command to it. That step also utilises the Messenger Library, but loads it from the folder next to the sequence (to make sure it runs on systems with LabVIEW Run-Time only). As a result I have a TestStand Actor that runs in LabVIEW Run-Time application instance, that actor loads a sequence that has steps that also run in LabVIEW Run-Time. And that's where problem arises. Sequence can't load any Messenger Library VIs because they are already in memory (loaded by TestStand Actor).
  17. Hello Dr Powell and everybody. I am facing some frustrating behavior, already spent many hours trying to figure it out, but no luck. Maybe you could assist me. In my previous posts I mentioned that I have been working on TestStand Actor. Current setup: TestStand API wrapped in Messenger Library. It is calling Steps that also use Messenger Library to send messages (through TCP) to other actors that control hardware. Issue: TestStand Actor and LabVIEW steps share the same application instance. Hence, I am getting a conflicts/errors when trying to run sequences. The same steps work perfectly from normal TestStand provided by NI. I am looking for a way to isolate LabVIEW steps code from the TestStand Actor. It can be accomplished by putting all the dependencies in "lvlib" or "lvlibp". This way Messenger Library in custom steps will have a separate namespace. However when putting Messenger Library in "lvlib" or "lvlibp", my steps can no longer receive TCP replies. Only "Send Message" without a reply address work (if reply address is provided the send message makes the destination address invalid) . Interestingly, the published events are received successfully. Do you know why would "Send Message (without reply)" and "Receive Notification" work, however "Send Message (with reply)" wouldn't? (when Messenger Library is in put in .lvlib) Thank you! Kind regards, Max
  18. Thank you for all the suggestions! Since I based my actor on NI example of TestStand UI the SubVIs were already configured to run in a separate execution and I still experienced blockings. That is why I thought maybe the actor itself has to run in a different execution and posted in this thread. However today I found out that the freeze was caused by a dialog box that was created asynchronously by the TestStand API (e.g. when it noticed that sequence file was changed). There is a "TestStand - Set TestStand Application Window.vi" that accepts VI reference and makes all the dialog boxes modal to that VI (I set it to TestStand ActorNR.vi reference). It works perfectly fine when TestStand Actor's front panel is the front-most window, no blockings. However if another actor's front panel is currently in focus (front-most) there will be no dialog box until I switch the focus back to TestStand Actor front panel. And in this case both actors get frozen until I acknowledge that dialog box. P.S. Simple front panel drag around with a mouse pointer make actors unfreeze. I think it is related to modality settings that I will explore in more details. Thanks again James and bbean. I highly appreciate your time and support.
  19. Thank you both for quick replies. Indeed the TestStand actor also is used as a GUI. So, it makes it difficult to call everything in SubVIs. There are cases when TestStand engine creates popups that automatically appear on top of the actor front panel (hence blocking it).
  20. Dr Powell, Thank you for the new release of the library. It is a beautiful piece of work. Today I faced a new challenge (sorry for bombarding the forum). One of my actors is using TestStand API to execute test sequences. I noticed strange behavior, when this actor is executing synchronous TestStand API calls that take a noticeable time (>200ms) other actors (5 of them, fully decoupled) are also being freezed until that API call is finished. I started researching what could cause this. I believe it is a deadlock because preferred execution system of all actors is the same: https://zone.ni.com/reference/en-XX/help/370052W-01/tsapiref/infotopics/lv_preferred_exec/ Ideally I would like to set specific "Preferred Execution System" for actors that require it. I tried to change this setting in VI properties for ActorNR.vi. But doing this affects whole class hierarchy and propagates to all actors (as a result they stay under the same execution system). Idea that I have in my mind is to create another actor type that is configured for specific execution system. It would be great to hear how would you approach this issue? Thank you! Kind Regards, Maksims
  21. Thank you for your work Dr Powell. I did some testing of the following VIs from the palette: And I can confirm that I was able to establish connection using Service Name or Specific Port and also it was possible to isolate actor from external network by setting net address to "2130706433" ( However I noticed that the "Name the TCP Service.vi" is now missing from the palette. I could still get it from the new "Create the TCP Server.vi" and wire it as a "event messenger subtype" to "Actor Startup" VI. Kind Regards, Max
  22. Thank you for your input on this! Indeed bbean is right, it could be or "localhost" converted to u32 net address. As a potential idea the "net address" could be a parameter when configuring the TCP Messenger. Thank you both! Kind Regards, Maksim
  23. Hi Dr James, Recently I've been thinking about the security when of TCP messengers. For example, often I am communicating with actors from TestStand steps. Everything runs on the same PC, works perfectly. However, I realised that if potential attacker knows the port of the actor, he/she will be able to connect to my actors from outside and potentially do harm. At the moment I see 2 solutions: 1. To configure Windows Firewall for the main application to only accept local connections. 2. To bind TCP socket to localhost by specifying "net address" here: The second solution will work regardless of firewall settings. It would be great to hear your thoughts.Thank you! Kind Regards, Max
  24. Thank you James for a prompt reply. Indeed the "Timeout Watchdog" will make it clear to the main if something goes wrong and if the code used is well-written there should be no occasion when actor becomes totally unresponsive (in the ideal case). Thanks again for everything.
  25. Dr Powell, First of all thank you for developing a dream library (framework), I've been using it for 2 years already. It is incredibly powerful and elegant. There are no words to express my admiration of your work! For couple of days I've been thinking about one scenario: Imagine there are 5 actors, each of them is dedicated to one particular piece of hardware or software component. They are launched by Main actor. Each of 5 actors has a state and it is updated once action is performed. Now, what if one of the actors gets into an infinite loop (or an action that will make it stuck). In this case it won't be able to update it's state. However my Main actor doesn't know about it, it only remembers that the last state of that frozen actor was, for example "good". 1. How to make the Main actor realise that one of its sub-actors is frozen? 2. What to do in this case with a frozen actor? How to restart it? P.S. I've been thinking about using the "Watchdog" actor. Create 5 of them in Main actor and share with subactors. Then inside of subactors constantly reset the Watchdogs. If watchdog wasn't reset, Main actor gets a message. Not sure if this is the most elegant solution. And there is still question 2 left. It would be great if you could share your thoughts about this. Thank you! Kind regards, Max
  • Create New...

Important Information

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