Jump to content

Dan DeFriese

Members
  • Posts

    201
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Dan DeFriese

  1. Of course not, a non-member subVI should certainly be allow to access an object. I don't see them as being the same role. The constant declares an origin of dataflow. Controls and Indicators are used to pass data through the program.
  2. Why shouldn't it be reset, and why should the class user care? The data is private. I would expect the class user's to use the public interface privided by the class developer (e.g. Init.vi, DoThis.vi, DoThat.vi, SetThis.vi, GetThat.vi, Close.vi) and not should not be concerned with the class's internal data representation or the default value of private data. Isn't this is the whole purpose of encapsulation?. If anything I'd suggest that LabVIEW be changed to not allow a class constant to be placed on the block diagram of a non-member VI. ~Dan
  3. If you are the class user I'd say that you shouldn't be messing with the default value of the private data. That is, the class should be initialized explicity by the class user using the public accessor functions provided. Maybe I'm missing something, but your argument appears to assume the internal representation of private data would retain the same data type... What if the designer decides that the private data should be represented as a numeric instead of a string? At that point your default value on the original block diagram would be meaningless. The implementation of the private data is, and always should be, at the discretion of class developer. ~Dan
  4. How is the 'View' VI being launched? If its a dynamically called *.vit this is the expected behaviour. Can you post a screenshot of how 'view' VI is called. Edit - actually after re-reading your discription "If I move the 'view' vi to somewhere NOT under a class icon of the project explorer window - top level under 'My Computer' or even a Virtual Folder - the 'view' vi will terminate automatically - which is what I want." I'm confused.
  5. Obviously, you'll need to read spec for MIL-STD-1553. Before that, however, you'll need to answer the questions: 1) How I'm I going to convert a 1Mbit/s interface to a 115kbit/s interface? 2) Why am I building a test interface when I could buy it? ... I'm making an assumption here that you're making test equipment since your're posting here. In any event, I assure you that you will not save $$$ doing this from scratch. 1553 is just a little less complex than ethernet. Anyway, if you're unfamiler with 1553 you may want to check out the tutorials provided by DDC (Data Device Corparation) and GE FANUC. http://www.ddc-web.com/Products/MIL-STD-1553/DesignersGuide.aspx http://www.gefanuc.com/library/detail/11743 Sital sells IP Cores for 1553, if your're interested. http://www.aerospace-technology.com/contractors/electronic/sital/ FWIW ~Dan
  6. Not sure how typecast is implement in LabVIEW. However in other languages (such is C) typecast is actually an operator, not a function. Using typecast just tells the compiler that the data in the memory location for variable x should be interpreted ('re-cast') as being of datatype y. That is, there is no function call at runtime associated with performing a typecast. However, I suspect the flatten to string primitive does do some low-level data interpretation / copying and may of some computational overhead. Swap bytes sounds like something the CPU instruction set would implement directly so I can imagine that this would be significant by comparison. Mostly speculation but I hope that helps. ~Dan
  7. Unfortunately, I haven't had the the need or time to use LabVIEW ActiveX Server since the Intermediate course. But you might look into this http://zone.ni.com/reference/en-XX/help/37...lv_activex_srv/. There's a some VBA example for calling LabVIEW from Excel in the examples folder: labview\examples\com\freqresp.xls. From Excel you can edit the LoadData macro to view the source. Hope this helps. Dan
  8. QUOTE (udai @ May 31 2009, 11:08 PM) A time-tag will only tell when the messages arrive at the test card. There's no way for your test software/equipment to know the "freshness" of the data being aquired and transmitted by the RT unless, of course, this information is encoded in the 1553 data stream.
  9. QUOTE (udai @ May 27 2009, 11:58 PM) I can't think of any "universal" ways to do this other than the time-tag. Some Driver APIs (AIM) may have bit in the receive data block that can be set during the read operation. What device are you using?
  10. QUOTE (n00bzor @ May 27 2009, 02:55 PM) Impossible! It doesn't work yet. Post what you've tried. QUOTE and i think the main problem is the 6009's power output on the digital ports (on analog it controls the circuits perfectly). Problem is that i need 5 control lines out of the daq, and i only have 2, so some form of multiplexing isn't an option also. Are you saying that you have one of those NI-USB-6009 DAQ gizmos? Are your optocouplers really drawing 10mA (This is 2x the rating of the 6009 analog outputs so I'm puzzled.) What is the part number for your optocoupler? Maybe provide a drawing of your setup? Is an external power source available to power a simple transistor amplifier stage between the 6009 and opto. Maybe this could be powered with the 5V 200mA power source from the 6009 itself? ~Dan
  11. QUOTE (udai @ May 27 2009, 07:32 AM) Assuming that you've purchased a COTS board from Condor, AIM, DDC or whatever. You should be able to check an IRIG time-tag when poping messages off the receive FIFO. Check your manual for details.
  12. QUOTE (n00bzor @ May 25 2009, 10:03 AM) You should really look at the specs for the given sound card. Generally, they'll only produce enough power to drive a set of headphones (.5-2Vp-p). What exactly are you trying to do? (Beyond destroying a perfectly good soundcard ) Obviously, cost is an issue for your project, but if you more some more specifics maybe someone here can guide you to cost effective solution. Perhaps using a parallel port (one of those USB adaptor kind if need be) or $10 demo module from ftdichip.com would be more appropriate. ~Dan
  13. QUOTE (Jim Kring @ May 20 2009, 07:56 PM) That's not cheating, this is pragmatic engineering. I'm still looking for a pendulum ducky that Homer Simpson used so I can automate close the Resolve Load Conflict dialogs.
  14. Is there a reason your just customizing one of the built in knobs? What your proposing should be trivial, but quite time consuming. Try posting what you've done so far and maybe someon here could explain why its not working the way you expect. (e.g. perhaps you angle is in radians and not degrees or something.)
  15. QUOTE (Yair @ May 17 2009, 01:31 PM) This was exactly my first impression of LabVIEW. Well, I think my words were more like: "...what a sh#$% language, this is so fu!*#%CONTENT% hideous... Hey boss, please tell me again why you want me to start using this crap!...". It wasn't until after someone like the two of you (Yair and MRoss) that this stuff started making sense to me. Thanks!!!
  16. QUOTE (lovemachinez @ May 14 2009, 11:46 AM) Uninitialized shift registers are roughly equivalent to 'static' keyword in C. Based on Mark's example, a subVI like this my work for you:
  17. QUOTE (jonmcbee @ May 12 2009, 05:55 PM) I don't think your missing anything. The vi typedef is so the caller knows the connector pane layout and can link the dynamic vi... This is the same principle used for DLL calls (you need to know the function prototype before you call it.) Try to standardize on a connector pane for your plugin VIs. I can think of a couple workarounds if that can't be done, but I'll ask for a few specifics first. Of course, if your plugins don't need to accept or return values then just use the RUN VI invoke node. ~Dan
  18. QUOTE (Raph31 @ May 11 2009, 10:37 AM) This may not be wise. This path information is only useful during devepment and would be stripped out when build an executable. I think the better approach would be to create a polymophic function that is selected based on the datatype.
  19. QUOTE (Black Pearl @ May 7 2009, 09:44 AM) Absolutely! Keep in mind that defects (bugs) are not limited to logical programming errors... SE texts generally suggest that the vast majority of software defects are created during requirements phase (either through omission or misinterpretation). By comparison, logical errors are actually quite rare.
  20. QUOTE (Black Pearl @ May 5 2009, 05:36 AM) This will always be the case. Doesn't matter if you're developing for Microsoft, NI, or XYZ. Invariably, your customers will expect a certain amount of flexability in your product... they call it SOFTware for a reason. QUOTE ...we never ever get any specs on how to design our software... Your the software domain expert - its your responsibility to spec out the design the software. Though, I assume you meant requirements specification. Nobody, will ever hand you a complete set of requirements. You'll have to dig for them...then YOU put them in writing and review with the customer. Yes, things will change...but any changes after the initial commitment should be tracked using a defect tracking tool: Serena Tracker TeamTrack DevTrack Bugzilla, or whatever.(You could even do this with a spreadsheet if you want to be cheap... but, you get what you pay for.) I've found that using defect tracking helps me keep current development controlled and keeps a history of common requests from my user base. Future projects benefit because I already know what questions to ask. IMHO, UML is worthless for capturing requirments since the customer usually doesn't understand the diagrams. I find, simple flowcharts and screenshot prototypes much more effective. Anyway, my favorite SE related handbook is "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt, David Thomas
  21. QUOTE (marscru @ Mar 24 2009, 02:16 AM) 1) Yes (anything is possible), but obviously you've seen the first of many consequences. Review the event programming caveats in the LabVIEW help for details and other rules. Nesting event structures is bad form I suggest you don't even think about going down that path. In fact, if you think you need more than one event structure in a given VI it's time to re-think your logic. 2) An event structure certainly be can be used to initiate this, but there's no reason to nest events. 3) I'd typically maintain a 3rd array to maintain an index set. Also, from what your describing, assigning a row or column of a 2D array from 1D array may result in unintended padding or empty cells if the 1D array size is not constant. If you post your code with a few more operational details we may be able to provide better guidance.
  22. QUOTE (zmarcoz @ Mar 17 2009, 02:54 PM) Microsoft has certifications out the wazoo http://www.microsoft.com/learning/mcp/default.mspx#CERT. They have freely downloadable "Express" Editions of all their Visual Studio development tools (Visual C++, Visual Basic, etc...). Just browse around the Microsoft.com and msdn.com websites.
  23. I'm not sure I understand your question. What do you mean by pause LabVIEW (Wait Milliseconds ???)? Which part of your system will be sending the "S" character to start the aquistion (LabVIEW or PIC)? Also, your VISA read timeout is ridiculously high (300000000). I imagine you use the 'Abort' button alot Could you explain why you chose this value? Anyway, try posting a flowchart or something that better illustrates what your trying to accomplish? Then, we can go from there. ~Dan
  24. QUOTE (Oliver Barrett @ Mar 13 2009, 03:09 PM) You could place all your booleans in a cluster (hide the frame if desired). The implement your BD logic using an array. The Cluster to Array and Array to Cluster primatives when time to update the FP control.
  25. QUOTE (tamimi87 @ Mar 11 2009, 01:38 AM) Sounds like you two separate modules operating concurrently (parallel loops)... and both of these modules are trying to access the hardware resource at the same. If this is the case, you might consider rewriting the app so modules are combined (i.e for loop) or use a semaphore in each module to protect the shared hardware resource from the parallel / simultanious access.
×
×
  • Create New...

Important Information

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