Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by todd

  1. producer consumer employer employee judge executioner
  2. lordexod, when AQ says he won't share the information, that in itself is useful information. Since the implied intent was not clear (that XNodes can corrupt a VI), he was then more explicit.
  3. That still doesn't work for the case where Status Array is all 1's. On the fourth (and last) iteration, the output of the increment is 4, but the output of the feedback node is 3.
  4. That's what I thought, but the fourth iteration of the loop outputs the left side of the Increment, which is at 3 for the "100%" case. I don't like the Enable terminal, in this case.
  5. I've tried a few things: removing all classes and methods from the library in the project viewer - then adding them back. Doing the same thing from a separate lvlib-only project-type window. The xml files look fine.
  6. How does one resolve this? I have a project in 2011 that claims all private data ctl files are incorrectly claimed by a library. Moving the classes out of and back into the lvlibs didn't help. Even making a new class in a new blank project doesn't work. Downloading 2011SP1 right now. I only looked at "incorrectly claimed" because LabVIEW crashes every time I add a string control (or indicator) to an existing class' private data.
  7. There's a "DisconnectFromLibrary" invoke node.
  8. Oops, I forgot something. The vi knows it's part of an lvlib, too. Take a vi that's in a library, copy it somewhere else on disk, then open it - it looks for the lvlib.
  9. The .lvlib file contains a list of files in the library. If you double-click on an lvlib file, a list of VIs in that library shows up. Right-click on a file to "Remove From Library". Then check in the lvlib file.
  10. Ok, something is slowly becoming more clear for me. I've been trying to write vis that look like the "traditional" left-to-right, open/do stuff/close - and have one by-ref wire running across the diagram into and out of an actor's API. (That way users don't have to know anything about the AF. It makes writing tests easier for me, too.) So far, I've been sending across the Send Queue and creating top-level send messages for each "write this" command, and reply messages for each "read this" command. It sounds instead like I should be sending a queue pair across. Or bundle the Message Queue Pair with the Caller-To-Actor Send Queue, or just bundle the Caller-To-Actor Queue and Actor-To-Caller Queue. That way the actor's API can be all in one virtual folder of one library. Anything I'm missing, here?
  11. Yes. Actually, I'm bringing up the actor-based driver from scratch on the side - copying in the existing personality developed in the slave-loop-type driver. I have only three or four apps that use this driver, currently. I actually did a fair job keeping most of the code modular/componentized. The main reason I'm attempting to refactor the driver is because some of the inheritance decisions I made didn't allow for new types of device functionality that came along. The other reason is normal "oh, I wish I'd have done this a little different the first time". Ok, good! I like this feedback. I'll try some separate data-engine-type actors that get started by the device actor, and put their Send Queues in the device actor's private data. Data types can change over time, too, so using data-actors allows me some inheritance freedom. One of my main goals is to keep the "test case" VIs very simple - one actor's Send Queue runs along the diagram for all control and data grabbing operations. As for needing an instrument connected, I made the base "transport" class a simulator that has its own data-actor (child classes of transport can be things like "com port" and "GPIB", for example). While testing, data can be injected into the simulator's buffer to be read by the device driver. Thank you!
  12. The whole thing is an overhaul, so no worries there. I suppose the actor's methods called by messages would access the DVRs. Thanks for the suggestion! I'll try it out. I'm standing in the dark - stop shooting!
  13. The intent definitely is to have the data storage internal to one actor. That keeps the "user API" simple: all interaction with the actor is done via it's Send Queue. In the QMH/LV2G "pre" code, the LV2Gs are called in the user code (for initialization and for getting data) and in the slave-loop/QMH for the instrument (primarily for adding data). This particular device has one instance, at the moment. I need to be able to support adding additional copies of the same instrument. I also want to make it very easy for a user to use this instrument in their code. My goal is to have one Send Queue per instrument - as opposed to a driver and five or six LV2Gs. I haven't taken the time to replace the client-specific parts of the "pre" code so I can post an apples-to-AF comparison. I do use lossy queues in the working code. What I have not figured out is a good way to make the data stores available to the actor's Send Queue. Should there be one data-store actor per LV2G replacement? Should there be a set of DVRs that get created in the Actor Core override and handled in the parent Actor Core? Thank you both for looking. On a side note, I've added a Simulated Byte Stream actor and bundled it into the Simulated transport class. I'm starting to really like actors.
  14. (Cross-posted in the NI Actor Framework community: https://decibel.ni.com/content/groups/actor-framework-2011) I have a device with a serial interface. The device is always listening for commands. Some commands cause an immediate response, some commands cause a continuous response, and some responses show up without having given a command. There are several types of responses (streaming and immediate). In my current code, I use several LV2 globals to hold the most recent 5 minutes of each type of data. In a particular test, I can retrieve the most recent value, all values, the next new value, etc. WIth AF, I can't figure out a good way to replace the LV2s. In the attached zip file, the main code is in "main.vi" and "SerialDevice.lvlib Actors Sim.lvclass Actor Core.vi". Any advice or analysis is appreciated. Note that some inheritance is there since the protocol can (and does) change often, and I need to maintain backwards compatibility. 2011 Serial Device Project.zip
  15. A It makes me think of "build array" and "delete from array".
  16. No offense taken. I agree that I don't understand your design architecture. I disagree that the control values are read AFTER the dequeue element primitive. You can see it in your VI if you enable Highlight Execution. Attached is my weak attempt to show it in a simpler way. Note that there are always more Y values on the front panel than Xs.
  17. As jcarmody said, the user Event Structure only has a case for Shutdown. In your consumer loop, the FP terminals are read before any dequeue happens.
  18. It's right on the Getting Started Window (new project from template, or so). See the beta forum for an update to the sample project, though. Arg, this doesn't count as talking about the beta, does it?
  19. I can't find the post, right now, but someone showed how to use the in-graph picture. Here's my copy of their VI. use picture to show arbitrary x axis labels.vi
  20. Finally! AQ is going to provide text-based LabVIEW!
  21. Not linux - but since windows VMs were mentioned: I've run a win7-32 target in the free "Windows Virtual PC" on a win7-64 host. USB hardware worked. I installed the "Integration Features" so the target could see the host's drives.
  22. That vi does not do anything with the serial port - nor does it split a string into lines. Perhaps it is the wrong vi?
  23. What OS are you using? I have the simplest of keyboards, and there are many times the letters get missed as I type (Win7-64)
  24. Based on your excel file, you want a graph like the bottom one in the attached image, but with more ticks on the x-axis (... 8, 9, 10, 0, 1, 2, ...). Apparently, you still have to use a workaround. See the non-trivial ideas in the links from Erik's comment in this idea: http://forums.ni.com...es/idi-p/921601
  • Create New...

Important Information

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