Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Thoric last won the day on August 10 2017

Thoric had the most liked content!

Community Reputation


About Thoric

  • Rank
    Very Active
  • Birthday July 17

Profile Information

  • Gender
  • Location
    Durham, UK

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since

Recent Profile Visitors

1,683 profile views
  1. 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.
  2. 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.
  3. 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 c
  4. 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.
  5. 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
  6. 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
  7. 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 GU
  8. 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
  9. 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!
  10. James, Can you advise on the following build error using Messenger library please. My code is not broken. It runs from source perfectly fine.
  11. 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?
  12. 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
  13. 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 pla
  14. 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?
  • Create New...

Important Information

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