Jump to content

Maksim Kuznetsov

  • Content Count

  • Joined

  • Last visited

  • Days Won


Maksim Kuznetsov last won the day on April 30 2017

Maksim Kuznetsov had the most liked content!

Community Reputation


About Maksim Kuznetsov

  • Rank
    More Active

Profile Information

  • Gender

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since

Contact Methods

Recent Profile Visitors

1,130 profile views
  1. I have an OPC actor to which I can subscribe for channel data change events. Channels are strings. However after some time I realised that using strings was not that convenient, especially if one of the channel names changes. So, I decided to create an enum of all OPC channels and subscribed in the following way: This approach allowed me to leave the OPC actor unchanged. Then this is how I handle the events: Now if need to change the OPC channel name, I can just change it in the typedef without touching anything else. Also writing/reading channels (separate messages suppo
  2. Hello James, Another short question from me. Are you planning to return the "attachment" feature for the outer-envelope? I remember using it for some time, but after installing the latest messenger library it seems to be gone. Thank you! Max
  3. Thank you for sharing your opinion on using parent classes for actor references to prevent unwanted code coupling! I will use Send class. That would be great, really looking forward to these changes. ____________________________________________________________________ If I ask too many question, please tell me! But I have another one. I use TCP messengers quite often to send messages and subscribe. That works perfect! However today I tried to send a local queue in a message for the receiver to reply when asynchronous action is finished: The problem here is that I sh
  4. Hello everybody, I am currently cleaning up my projects and thought of the way that could potentially reduce the amount of things loaded in the development environment. This is the architecture used at the moment: Actor named "Main" launches actors A, B, C, D, E. The last actor E is launched and requires addresses of C, D. I pass these addresses (C, D) as specific actor references. That means that if I want to debug just actor E, the development environment will load actors C, D as well. And if one of them is broken, actor E will appear broken as well (even if I don't wan
  5. 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!
  6. 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
  7. 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
  8. 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!
  9. 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.
  10. 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 th
  11. 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.
  12. 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.
  13. 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 wh
  14. 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
  15. 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. Crea
  • Create New...

Important Information

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