Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/13/2013 in all areas

  1. I was on a roll and fixed/released the new OpenG Time and Array libraries too, so this issue should be resolved for now. Please let me know if there are any issues once you upgrade to the new versions.
    2 points
  2. Hey Everyone, I've rebuilt the OpenG File library (v4.0.1.22) with a fix for this -- I've added the "(OpenG)" suffix to the Window Title and palette names. vipm://oglib_file?repo_url=http://www.jkisoft.com/packages Please take a look and let me know if this works well. If so, I'll make the fix for the OpenG Array and Time libraries, too.
    2 points
  3. I don't think it takes too long after deciding to do an actor based project to run into the case where you have an actor spun off without a way to kill it. You'll figure that out and get your solution working so you can pass it off to someone else and forget about it. Soon after, that someone else will come to you and say something like "yeah, those actors are cool and all, but they're really hard to debug" I ran into some of these problems a while ago, so I decided to write a little tool to help with it. I decided to call it a monitored actor. Here were my design criteria: I want a visual representation of when a monitored actor is spun up, and when it is shut down. From the visual representation, I want to be able to: stop actor, open their actor cores, and see if they're answering messages The visual representation should give you an idea of nested actor relationships. Implementing a monitored actor should be identical to implementing a regular actor. (meaning no must overrides or special knowledge) Monitored actors behave identically to Actors in the runtime environment. It turns out that you can pretty much accomplish this by creating a child actor class, which I've called Monitored Actor. A monitored actor's Pre-launch Init will try to make sure that the actor monitor window is made aware of the spawned actor, and Stop core will notify it that the actor is now dead. The actor monitor window contains ways to message the actors and pop up their cores and such. I think it's fairly obvious what each button does except pinging. Pinging will send a message to the actor and time how long it takes to get a response. This can be used to see if your actor is locked up. The time it takes to respond will be shown in the ping status column. if you want to periodically ping all the actors, set the "poll Frequency" to something greater than 10ms. This will spawn a process that just sends ping messages every X ms. Where I didn't quite meet my criteria: If you were to spawn a new actor and Immediately (in pre-launch init) spam it with High priority messages, the Actor monitor window will not know about the spawned actor until it's worked through all the High priority messages that got their first. You probably shouldn't be doing this anyways, so don't. Download it. Drop the LVLIB into your project. Change your actor's inheritance hierarchy to inherit from monitored actor instead of actor. You shouldn't have to change any of your actor's code. The monitored window will pop up when an actor is launched, and kill it's self when all actors are dead. Final note: This was something I put together for my teams use. It's been working well and fairly bug free for the past few months. It wasn't something I planned on widely distributing. A co-worker went to NI week though and he said that in every presentation where actors were mentioned, someone brought up something about they being hard to debug or hard to get into the actual running actor core instance. So I decided to post this tool here to get some feedback. Maybe find some bugs, and get a nice tool to help spread the actor gospel. Let me know what you think. Monitored Actor.zip
    1 point
  4. Awesome now my prayers are answered. Next step will be to update my Right Hand Quick Drop Shortcuts to use the OpenG functions that I couldn't before.
    1 point
  5. I just updated my OpenG libraries in LabVIEW 2013 and everything looks good. For posterity, the new palette object names I observed were: OpenG Array Palette Empty Array? (OpenG) OpenG File Palette Build Path (OpenG) Strip Path (OpenG) OpenG Time Palette Tick Count (ms) (OpenG) Wait (ms) (OpenG) Wait Until Next ms Multiple (OpenG) With Jim's changes, all 6 of these OpenG VIs are now droppable with Quick Drop, and they display the proper owning palette when you right-click them. Thanks for implementing the fix, Jim!
    1 point
  6. Why not just use a DVR and the "global clone" just accesses the DVR
    1 point
  7. The Vision Common Resources install is FREE and allows you to use the IMAQ image control in your application. You don't get any image processing but it is fine for loading images and displaying them with all the ROI tools. I believe the only bit you need a license for is IMAQdx...
    1 point
  8. A bit of head scratching and some head banging later, I figured it out. The solution is quite simple actually. Lucky for us, the last event which occures after you the mouse is up, is registered and shows as being equal to previous. This will do exactly what I want. Some extra checking is required to trap maximize and restore sizes, but overall is a robust solution.
    1 point
×
×
  • Create New...

Important Information

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