Thoric

Thanks, but that's what I thought I'd tried and it didn't work for me. My classes are perhaps bit more complex (A is actually a child of some other parent), so I wonder if that's complicating this. Certainly the entire class heirarchy is not in the lvlib. I will give it another go though! 🙂

Hi Francois - as I mentioned in my second post that didn't work for me. B referenced A1, cross-linking the two libraries, and B1 in the clone was therefore uncalled. Did I do it wrong maybe? I used the Save A Copy method on the library to achieve the clone. Do you have an alternative approach?

Well, so far I have one ugly workaround - clone A as B and A1 as B1 into a new folder. Programmatically create a New Project, add B and A1 (its natural dependency), find A1 and call method "Replace Item With" using path to B1, set to "Save All without Prompts", then close the Project without ever saving it. This updates B to use B1, and seems to be the only way to get the "Replace Item With" method to work. Takes about 8 seconds though. I originally tried putting A and A1 into a library and cloning the library, but this didn't prevent the issue, and it also blocked access to "Replace Item With".

I have two classes (A and A1), and A1 is present on the block diagram of VIs within A.lvclass. I want to clone this precisely, so that I have two new classes B and B1, with B1 appearing in the VIs of B. I don't want B using A1. When I use the LVClassLibrary.Save A Copy method on A and A1 to create B and B1, I predictably get B using A1, and a lonely B1 with no callers. How can I either avoid this, or fix this? I don't see a way to "replace all calls to A1 with B1" or "Replace A1.lvclass with B1.lvclass" in B. I briefly looked at the method LVClassLibrary.Replace Item With but I don't see how I can use it when A1 doesn't appear in B's "library view" Note that B and B1 will later go on to be modified, so A and A1 are kinda like source templates. Ultimately there will be C and D and E, each customised slightly, but based on A.

The link to the file is dead?

For this to be useful in my application, which is networked and takes advantage of the TCP Messenger, the UDP port would need to be configurable. Also, our network admins have strict policies which could interfere with UDP. Although it's allowed, it can't cross certain hardware boundaries between networks. So although we can get TCP Messenger to cross networks, UDP would likely fail.

2017SP1 is fine for me. We have a generic configuration actor that uses JSON. Will be interested to compare your approach, if you include one in the toolkit.

I've narrowed this down to this probable cause: If an actor in a library that's drawn in as an unneeded dependency uses "TCP Actor" to make it remotely accessible then the build of the structure fails when "Remove unused elements from Libraries" is set in the app builder, as is the default for LabVIEW. I've attached code that demonstrates the build error (LV2017) and if you remove the TCP Service subVI from the actor UnusedClassWithinLibrary.lvclass the build then succeeds. @drjdpowell Any clues as to why using the TCP service features on an unused actor within a library could cause a build to fail? Needing to keep "Remove unused elements from libraries" set in the builder inflates my executable by over 100% because it then draws in masses of unnecessary code. MessengerActorBuildFailDemo.7z

My fix for now is to move the "IGOR_Sync.lvclass" actor out of the containing library "IGOR Sync.lvlib". This ensures the actor isn't present and therefore not "removed as an unused item from the library" during build. But I think I need to get to the bottom of why this perfectly valid situation is creating a build failure. Any thoughts? Is the class structure/tree being broken in the builder when the unneeded actor is removed from the library? That would be a LabVIEW builder bug.

OK, so I made a Source Distribution out of the failing actor, which included all it's references/dependencies. Wrapped this one actor and the copied dependencies into a new project, created a build spec and it fails. Good. So I have a test environment. Checked into SCC. Remove ActorNR.vi from Class I removed ActorNR.vi from the class (with the rest of the class content to maintain accessibility) changed the DD terminal to Optional. It still fails. If I run ActorNR.vi it works fine. So this problem isn't necessarily related to the DD requirement. Mass Compile I don't think this is necessary given I've created a fresh Source Distribution, but tried for completeness. No reported errors. The build still fails. Note: The build error (Cannot save a bad VI without its block diagram) appear to suggest the problem is with: vi.lib\drjdpowell\Messenging\Parallel Process\Parallel Process Library\Startup Handshaking.vi. Clearly this VI is not broken in source. Remove Identity from ActorNR.vi I realised the ActorNR.vi was still referencing actortype2 as it had the identity class control. Deleted it. Build still fails, same error but now it points to vi.lib\drjdpowell\Messenging\Parallel Process\Parallel Process Library\Startup type 2.vi Investigating the dependency libraries One of the three libraries this actor calls upon actually contains a Messenger actor. An actor that's not required in this case, but exists within that library. When removed from the library, the build process succeeds. Rewind I rewound my source code branch, so this problematic actor is now an actor again, and tried the last step of removing the other unused actor from the dependency library. Build succeeds. So this is my situation (see image attached).

So I started by cloning the first actor that has a problem and creating a build spec for it, then removing content bit by bit until it built OK. It was only happy when I removed the last reference to a typedef cluster that belongs to another library (which I'll call LibraryA). I started again with the same actor, cloned it, checked it still doesn't build, removed only references to LibraryA's typedef by "disconnecting from typedef" wherever it appears in the actor and it then built ok straight away. The fix has nothing to do with all the other things I'd removed, just typedef linkages to other libraries. I tried the same with the second failing actor. Check it still fails to build. This actor has typedefs from two other libraries in it (LibraryA and LibraryB). Removing links to these wasn't enough. I also had to remove links to all typedefs, including one that belonged to a toolkit. Then it finally built. Thoughts anybody? Every actor I've created has typedefs from libraries and toolkits in it. But only these five actors appear to have a problem with incoroprating them. @Neil PateThanks for the idea, but these actors have no stale or unforgotten disabled code in them. They're really clean and some a even super simple. The classes also have no bad VIs in them. @bbeanThanks for the idea, but I haven't changed their thread preferences. I'm not sure actually can without breaking the dynamic dispatch rules.

OK, good idea. So I painstakingly built each actor independently and 11 built fine, 10 failed. I think some of those that failed are only failing because they call one of the other failing child actors, so of the 10 failures only 5 are at the bottom of the tree hierarchy and I think these are the culprits. So now, the question is "What about these 5 failing actors is causing a build failure?". Do they exclusively have something in common? Their roles are: One is Dialogue style GUI Editor for populating an Array - a relatively simple actor. Another is a Dialogue style GUI Editor for a more complex file management need. Manages remotely (FTP) stored files. A third Dialogue style GUI Editor for managing another Array - a relatively simple actor, like (1). A local file management actor for receiving configurations and collating them into a JSON file - a simple decoupled actor with the ability to gather JSON objects from any other actor for storage and retrieval. A simple actor that adds log entries to a local text file, and uploads the local file to a remote FTP folder. So they don't all have one common dependency that the other actors don't also use. The first three present their FPs, but so do many other actors. Some depend on FTP interaction, using a separate internal library we have, but not exclusively so. I think I'll try cloning one of these 5 actors, trial build it then strip out 1 feature, and repeat until it builds successfully to determine which component is the problem...

I wanted to get back to this thread because you've effectively said that by using dynamic-despatch the actor launcher is pulling in virtually all my code and therefore it is near impossible to tell what's wrong; implying that there is a broken VI somewhere in my code that prevents the app builder from completing. But I'm certain there isn't anything broken. The code runs in the IDE. If I open all VIs there are none broken. None. So I don't see how your argument stands. I need to discuss further because I'm encountering annoyances associated with the workaround to disable "Remove unused members of project libraries" option and would like to go back to getting this properly sorted.

Thanks JKSH: Closed LabVIEW and cleared the compile cache - same error Altered the Build Spec to not "Remove unused polymorphic VI instances" - same error Altered the Build Spec to not "Remove unused members of project libraries" - it built Rechecked "Remove unused polymorphic VI instances" - it still built. In Short: The key is disable "Remove unused members of project libraries". Can't recall having to do this before, but hey ho. Whatever works!

James, Can you advise on the following build error using Messenger library please. My code is not broken. It runs from source perfectly fine.

Hi Igor. In your Readme you state "If input string is 38, 39, 86, 87, 134 or 135 bytes long, the output is incorrect." I tested all string lengths up to 1608 and it failed for 67 strings (various lengths). Do you know why your library doesn't work for certain length input strings, and might it also be wrong for other lengths too? Maybe I can help determine a fix if you have any clues where to look?

I was adding a 'quick' feature to my framework - in retrospect it wasn't the right approach so I've changed my tactic and now I have a better implementation that doesn't require this actor knowing the message origins. I appreciate knowing now though that the addresses are directly identifiable, even if we cannot extract any information about the address from it. Thanks James

James, Is it possible to glean information about the sender of a message? In my Actor I receive a message and it would be useful if I could learn some originator details, namely the Name of the Actor (VI Name perhaps). I wonder if it's possible to learn this info from the Reply to... indicator of a Read Reply Address call? A little bit of background - I want my actor to be smart enough to recognise where a message has come from. It's 'actor agnostic', except for one in particular, and if packets come from that one particular actor I want to perform additional tasks. I can't place additional information into the message itself, so I need this actor to be able to determine the source of the message automagically. Can we do that?

Yeah, playing with this I can see that there's no native way to gracefully handle this. There are tools out there for creating custom popup menus, you can use one of these to generate a dynamic menu that appears beneath the ring control, just as the native control would?

Now I'm intrigued. I want to play to discover, but I might not get to a PC for a while, so apologies if it takes me a little while to reply.

What's wrong with using the Mouse Down? filter event to detect a click?

Interesting - these offerings are significant effort. I was hoping for something simpler, but I wonder perhaps if the use of a 'globalised' notifier is the solution I need. As you state, it's for a limited and clearly defined purpose. I'd be interested to see suggestion 1, (the helper loop, with the main actor template becoming the manager of an internalised worker), provided as another template option from the scripting tools. Thanks for the advice James - professional as always!

James, This may have been answered before, so forgive me if it has. The actor model you use ensures sequential execution of the Event Structure and State Machine. This means the state machine can complete its task(s) without interference from the event structure, because the event structure literally cannot react to any incoming messages until the state machine completes its stack and yields execution. But what if you have a case where this is unhelpful? For example, consider that the state machine is in the middle of a series of state changes, controlling hardware and taking measurements, when an Emergency Stop message comes in. I would want the emergency stop message to be received and reacted upon immediately, with the event structure being able to inform the state machine that it needs to take into account this emergency stop state, change its task list (stack) and instead put hardware in a safe state with immediate effect. Currently I don't see a way to do that without the state machine yielding to the event structure at regular intervals (every 100ms for example), which requires some uncomfortable coding styles. I could, for example, let the state machine yield to the event structure with a status flag set in the shift register that the Timeout Case uses to recognise a need to return to the state machine. This would give the event structure a chance to look at incoming messages and react. But what if a benign message comes in that would normally be held back until after the state machine was finished? Suddenly it gets processed and dealt with too soon. This is why it's important not to yield to the event structure before the state machine is ready to process new requests. Alternatively I somehow use a notification style message within the state machine itself, enabling the possibility of checking an Emergency State notification at regular intervals within the state machine, preventing the need to yield to the event structure. But this notifier would have to be populated from outside the actor, because the event structure is not free to create the notification. This means we now have external source able to directly influence a privately scoped state machine, bypassing the controlling event structure and defeating the primary principle of the actor's stacked structure. Or do we let this fly because we're just using it for emergency notifiers? Your counsel is greatly sought, my friend.

And the problem has returned. No changes. This has to be a race condition. Sadly I no longer have the diagnostic code in there so I have no way to see if the Register had any Observers. I'll reintroduce the code and do some repeat testing (multiple reboots of CompactRIO). Update: I can no longer get it to fail. With or without the code segment above looking at the register, it now always works. And I've literally changed nothing else. ...I wonder if a career shift into crop farming would prove less stressful...

OK, so I think I worked it out. I recover the DVR and run ObsReg to Table.vi and export to file. Unfortunately, introducing this diagnosis code caused the problem to vanish. With this code in place, the issue does not occur. Out of interest, the resultant table contains: All State ObserverSet; 0: EventMessenger (0x79B00000) All Events ObserverSet; 0: EventMessenger (0x79B00000) All Errors -- We have one Event Observer established. Hence the message was received and no problem occurred. For sanity I removed the diagnostic code and recompiled it, and the problem is still gone. Aargh! I haven't changed a single other thing! What's going on!?