Jump to content

Thoric

Members
  • Content Count

    140
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Thoric

  1. 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?
  2. 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
  3. 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?
  4. 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?
  5. 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.
  6. What's wrong with using the Mouse Down? filter event to detect a click?
  7. 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!
  8. 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.
  9. 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...
  10. 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!?
  11. Hi James, I tried your probe anyway - unfortunately it causes a deployment error (see image). Without investigating, I'm guessing there's something in there not compatible with RT? I already log the 'states' to a log file, which is how I know if the appropriate states are being fired in each actor. Plus I log all errors to a separate log file. Trying your ideas: 1) Already made that change, just in case 2) Double checked wiring - it's fine. So I took a look at "vi.lib\drjdpowell\Messenging\ObserverRegister\ObsReg Core\ObsReg to Table.vi” which shows how to take an ObsReg Core class and represent it's data in tabular form. How can I use this to investigate the number of Observers on the subactor notifier before I send the reply? I presume this is the motive? Deployment errors when using probes: This is how I record the states to file:
  12. James, the code works in development mode, so using the probe (assuming it works on RT) will show no issues. It's only once built into an executable and deployed that the problem occurs. Once built, I don't see how I can use probes :-(
  13. So, the first thing I tried was a delay between registering for notifications, and sending the first message. This fixed it. So there's a race condition. Basically I can assume that the registration request is performed asynchronously and is not complete before the subactor sends back a message in response to the "Deploy_FPGA" message. James - how can I ensure a regsitration request is complete before the subactor sends a notification?
  14. Errors are captured in the final "" state, so if there was an error it would be sent to the caller (Main) where I log all errors. I don't see any such error. Also, no TCP usage. In the meantime I just quickly created a new project with two actors, one calls the other, and proven: 1. The Self:Initialise state cannot send a notification to the caller - it won't receive it (you knew this, bug 13) 2. Sending a message to the subactor directly after registering for notifications, which gets the subactor to send a reply, does work. But it didn't in my actual project work, only in the test code. So there's either a race condition, timing error, or something else different. I'll look into this more tomorrow.
  15. I tried avoiding the use of Self:Initialise by sending a message to the subactor immediately after registering for notifications. It still didn't work:
  16. I should add that this is in LabVIEW Real-Time 2017 SP1. When launched from the IDE it works fine, but when compiled and deployed as an RTEXE that's when I see this issue.
  17. I'm returning to some Messenger work after a short break, which might explain why I can't see what's wrong with my Messenger Actor based project. Right now I have a Main actor which is responsible for launching a number of sub-actors. One of these is the FPGA actor. Directly after the launcher I register for all notifications. Within FPGA actor, the "Self: Initialize" message runs a number of states, the final one being to publish a notification event. This is to be received by the Main actor to known when it has initialised. Unfortunately this event is not received by the Main actor. I believe this might be because the registration request has not yet been processed by the FPGA actor, and therefore the notification event has no listeners and is effectively unheard. So my question is: what's the correct way to launch a sub-actor such that you can receive a message from it once it has completed initialisation steps? Main Actor launches FPGA subactor and Registers for All Notifications FPGA Actor performs three initialisation steps, the third being to provide a Notification Event
  18. For your front panel to resize to fit a changing front panel control, you will need to programmatically adjust it. There is no way to do this automatically. Smarlow has shown a great example above of how to do this.
  19. Just be careful with kerning. A "w" character followed by a "a", for example, might be narrower than the sum of the "w" and the "a" separately. I'm not sure how advanced the text printing functions are in LabVIEW, but true-type fonts are often kerned.
  20. Can you set the FP to not show when called, then programmatically show the front panel within code. This ensures the FP will not display until it's actually running. Just a thought.
  21. James, I believe the risk is only with variants and there's actually been no change to their flattened syntax since LV8.2 A 2017 flattened string refused to be interpreted by older LV code is purely a precautionary act. However annoying it is one can understand perhaps the design intent. So unless there are improvements in the NI pipeline for flattening variants then I don't believe there are any risks with forcing the version to the same as the Messenger toolkit source version (2011).
  22. I have a separate issue. When I load my project which uses Messenger toolkit, LabVIEW warns that the "Library information could not be updated". This pops up three times consecutively, yet once cleared everything seems to work OK. I've seen this before, when I used Messenger library about two years ago on another project LabVIEW used to complain with the exact same notification (today that project loads without the warning). I've only see this warning when I open a project using Messenger toolkit, so I think it's fairly safe to assume it's related? I was wondering if anyone else had seen this behaviour? I'm using LabVIEW 2017 on Win7 SP1 currently, but two years ago it was on 2014 within a VM (still Win7). OK - I did some deep digging, this issue has nothing to do with Messenger toolkit. Apologies.
  23. My experience having used this technique in my own application (not Messenger Framework related, but nonetheless the same issue) is that it works without loss. This flatten function honours any attributes within the variant. It does not, however, include a bitness setting, so you cannot set the bitness to your own choice. However, this shouldn't be an issue when passing data between Messenger actors. There are, as far as I understand, no changes to the variant flattening syntax since LabVIEW 8.2, so unless something changes in the future there would be no loss of info using this.
  24. My issue is not with Messenger, but with my own variant handling code between differing versions of LabVIEW. The LabVIEW version data requires 8 bits, not just the top 5 bits. For example, LabVIEW 2012 is represented by x12008004. But if the Messenger library (built in LabVIEW 2013?) were to enfornce the same LabVIEW version format for all flattened data then they ought to be compatible across all instances. I'm still battling to get this to work in my own code - I'm encountering problems associated with nested variants (A variant as part a few items in a cluster array, which is passed through a message which uses its own variant container), whereby the inner variant is always unflattened to empty. Might simply be that I have something mixed up somewhere, need to keep investigating...
×
×
  • Create New...

Important Information

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