Jump to content

ShaunR

Members
  • Posts

    4,881
  • Joined

  • Days Won

    296

Everything posted by ShaunR

  1. QUOTE (rolfk @ May 10 2009, 10:59 AM) It means you can't just "Read X Chars" until >= "file size" without getting an error. The choice is you either monitor the chunks in relation to the file size and at "file size -Read X Chars" change the "Read X Chars" accordingly, or ignore the error only on the last iteration. If you have another way, I'd be interested. But I liked the old way where you didn't have to do any of that.
  2. Agreed. There are certain people,however, I know who would disagree (purists who prescribe to the infinite decomposition approach). My problem is that complex function is what I do over and over again (measure pk-pk waveform, rise time etc, etc) but the hardware is always changing. Not only in the devices that are used to acheive the result, but in the number of different devices (might require just a spectrum analyser on one project, but a motor, a spectrum analyser and digital IO on on another). This I get. And for something like the "message pump", which has a pre-determined superset base of immutable functions is perfect. But for hardware it seems very hard to justify the overhead when drivers are supplied by the manufacturer (and can be used directly), "to make it fit". Yes the Agilent has a "Voltmeter" function, but it also has the maths functions which the others don't have so that needs to be added. Also. Just because I have abstracted the Voltmeter" function doesn't mean I can plug-in any old voltmeter without writing a lot of code to support it. If it added (lets say) a frequency measurement. Then my application would need to be modified also anyway. I get this too, And don't want to turn this thread in to OOP vs traditional, that's not fair on Daklu. The value I see in your interface approach is that it seems to make more of the code re-usable across projects, intended or otherwise The interface definition needs to be a superset of the project definitions, but that is easy for me since the higher functions are repetitive from project to project (as I explained to Omar). The intermediary "translation" could work well for me but the prohibitive aspect is still the overhead of writing driver wrappers which prevents me from taking advantage. I have one question though. Why do you have to "Link" to a device? Presumably you would have to know that the device driver is resident before hand for this. Can it not be transparent? Devices are (generally) denoted by addresses on the same bus (e.g RS485) or their interface or both. Can the "Exterface" not detect whether an instance already exists and attach to it, or create it if it doesn't? Also, where do I download the example with the Agilent included (I tried from the original post but it is the same as before) <p>
  3. QUOTE (Daklu @ May 9 2009, 06:20 PM) I like the abstraction (I always like the abstraction....lol). And I see where your going with this and like it (in principle). But the main issue for me (and is one big reason I don't use classes) is that we are still not addressing the big issue, which is the drivers. My applications are hardware heavy and include motors, measurement devices (not necessarily standardized DVM's and could be RS485/422, IP. analogue etc), air valves and proprietary hardware....well you get the picture. The hardware I use also tends to change from project to project. And (from what I can tell) to use the class abstraction, I need to wrap every function that is already supplied by the manufacturer just so I can use it for that project. Take the Agilent 34401 example in the examples directory for instance. If I want to use that in your Architecture, do I have to wrap every function in a class to use it rather than just plonk the pre-supplied vi's into my app which is pretty much job done? The drivers tend to use a seemingly class oriented structure (private and public functions etc), but there just doesn't seem any way of reconciling that with classes (perhaps we are just missing an import or conversion function or perhaps it exists but I haven't come across it). I know you have shown some example instruments, which strikes me as fine as long as you are developing your own drivers. But could you show me how to integrate the Agilent example into your architecture so I can see how to incorporate existing drivers? After that hurdle is crossed, I can see great benefits from your architecture.
  4. I read you document and (on the first) pass it all made sense. And I have downloaded the example, but I'm missing a load of JKI vi's (presumably in the Open G toolkit somewhere). I'm looking for them now. Just thought I'd say "something" since your eager for comments Just a little patience. Not everyone is in your time-zone and it is the weekend after all.
  5. QUOTE (Ton @ May 9 2009, 03:06 PM) Personal preference. For me. I like to see controls/indicators and their associated property nodes at the same level so I can see whats going on and apply probes without delving into sub-vi's. I had one bug in someone elses application that I needed to fix where on certain occasions a particular control would change its decimal places and others their colour when they shouldn't. The culprit was 5 levels down the hierarchy from the vi's affected and was a property node that changed the DP (amongst other things) dependent on a limit test supplied from another parts of the code (they didn't include the upper limit).
  6. QUOTE (postformac @ May 9 2009, 01:24 PM) It is if you pass the refnum to the sub vi. If you just select the property node and select "Create Subvi" from the Edit menu you will see what I mean. I don't consider it as good coding practice since it hides what you are doing. I would prefer to see a vi that returns the new values to the property node in the same vi as the control appears.
  7. QUOTE (Yair @ May 7 2009, 05:52 PM) Lets hope it goes out of scope before you run out of memory then. QUOTE (NI Help) If you use the Obtain Queue function to return a reference to a named queue inside a loop, LabVIEW creates a new reference to the named queue each time the loop iterates. If you use Obtain Queue in a tight loop, LabVIEW slowly increases how much memory it uses because each new reference uses an additional four bytes. These bytes are released automatically when the VI stops running. However, in a long-running application it may appear as if LabVIEW is leaking memory since the memory usage keeps increasing. To prevent this unintended memory allocation, use the Release Queue function in the loop to release the queue reference for each iteration. ----------------------- QUOTE (Yair @ May 7 2009, 05:52 PM) In any case, no one is forcing you to use these (or even a new version of LV). You can go back to an old version, but I still don't see why you say that you have to worry about memory, etc. in the newer versions. Tetchy
  8. QUOTE (crelf @ May 8 2009, 07:25 PM) That's kind of irrelevant. A customer will blame you (the supplier) not NI for stopping production by a fault in your software. Generally you will get a phone call and they will demand you come on-site to fix it. At best, it costs you (as in your company) 1 engineer on a field trip. But we also have a suppliers that we guarantee minimum down time and incur penalties for lost production. So far this year, we have had 2 occurrences similar to this, luckily not with a supplier we guarantee, but it still cost an engineer a day off each time from projects he should have been on (and car rental, etc). We have been using Labview and Labwindows for donkeys years, But there have been murmurs recently from the upper echelons in our company, that Labview is "too risky" and although it may be better in the short term because of the short development cycle, in the long term it may cost too much especially as the sales guys have just gone and sold 2 more guaranteed down-time contracts. In the current climate we have loads of c++ programmers looking for projects and the "powers that be" are looking for excuses to utilize the spare resource. I'm fighting like hell at the moment to get the SSP paid this month. And this sort of thing isn't helping me fight my corner.
  9. Such a simple request yet not as trivial as it first seems. Nevilles idea will most certainly work if you trust whoever is drawing the triangles. Hopefully you can go with that. But if you want a programmatic method, more complicated, but less demanding on the user you might try the following..... 1. "Threshold" the image (I'm looking at your blue icons) to get it in black and white. 3. "Fill holes" so that the center part of your triangle is fully blocked (i.e. you have a solid triangle). This is your major mask. 4. Scale your mask down by a factor (say 5%). And invert. This is your minor mask. 5. Combine both masks. 6. Apply the mask to your original image. You should now just have the white triangle without drawing anything.
  10. Yes. The callbacks were also saved in 8.6.1. I've attempted to save back to 8.0 and took them out of the LLB. Hopefully converted them all, but labview was very insistant on saving them in its current version. Try these anyway and let me know. Download File:post-15232-1241736385.zip
  11. This may help (Hint: Polygons) ROI Descriptor
  12. Everything you need is in \examples\instrsmplserl.llb\Advanced Serial Write and Read.vi
  13. QUOTE (Aristos Queue @ May 5 2009, 12:06 AM) Thats more like it does unless you tell it not too. But I can see where you are coming from. I was more talking about if I called method A and passed that data to method B and then on to C. Do I now have 3 copies of that data just because I invoked those methods (and labview has loaded but not released the VI's)?. Or is it just pointer arithmetic (as it would be in other languages ) and there is only 1 data structure and only a pointer is copied? QUOTE he workaround I mentionned is indeed the use of the vi request deallocation which just seems wrong to me for such simple task in an environment that handles memory automatically. This is one of the aspects I really don't like about the "new" labview (far more I do like though). One of the reasons Labview was much faster in developing applications was because (unlike other languages) you didn't have to worry about memory management. As such, you could get on and code for function and didn't necessarily need an in-depth knowledge of how Labview operated under the hood. There used to be no such thing as a memory leak in Labview applications! Now you have to really make sure you close all references and are aware of when references are automatically created (like in queues, notifiers etc). It's good news for C++ converts because they like that sort of nitty gritty. But for new recruits and programming lamen (which was really where Labview made its ground) the learning curve is getting steeper and development times are getting longer.
  14. It's a bit like the Error thrown on end of file in file functions. Technically correct, , but counter-intuitive and a pain in the proverbial.
  15. QUOTE (sachsm @ May 4 2009, 10:04 PM) Ta very muchly. But I was more interested in how it works.
  16. So does invoking a property or method cause Labview to copy the data in an object? Or is it all pointer arithmatic.
  17. QUOTE (sachsm @ May 4 2009, 02:53 PM) Is there a write up somewhere on the "mirror" library approach?
  18. QUOTE (Jarimatti Valkonen @ May 4 2009, 08:33 AM) If your going with a model-view architecture the (very) old method of using a data pool works well. If you put all your data in a global vi or variable and get your controller to update the global, you can bolt on different UI's for different views.
  19. QUOTE (Aristos Queue @ May 4 2009, 02:02 AM) Ummm. Maybe it had something to do with this statement from Ernest. QUOTE (Ernest Galbrun) The data is constituted of a 2D SGL array whose size may be a few millions of elements.
  20. QUOTE (ccie @ May 3 2009, 11:45 PM) Interpret it as "it doesn't work"...lol. Can't make out much from your graph. The time is in arbitrary units (ms, seconds, light-years?) and you haven't told me what what you are expecting (pk-pk voltage 10-100V? 20ms period?). You say the A2D comes through the serial port. How? Does it have a serial interface and your reading AScii characters? Or are you using the serial port as a digital IO and expecting a bit pattern representing the voltage. The source would also tell us what you are trying to do and expecting. Assuming it's not a software issue. I would check the polarity of the diodes. Getting one round the wrong way is easy to do and easy to check. Then I would probably stick a sig-gen up the A2D and see what was displayed. If you then get what your expecting, its your rectifier. If not its either the A2D or the PC (software or hardware). With all these things its a process of elimination. Segment the system into testable parts and iteratively narrow it down 'till you find the culprit.
  21. QUOTE (Ton @ May 3 2009, 02:51 PM) LOL. Looks like you pressed the send button just before me
  22. Open your own dialogue prompt (File I/O>>Adv File funcs>>File Dialog) and pass the filepath to the save vi. The File dialogue express VI enables you to set the default extension and passing the filepath means that the default dialogue won't be invoked.
×
×
  • Create New...

Important Information

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