Jump to content

Val Brown

Members
  • Posts

    754
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Val Brown

  1. QUOTE(Michael_Aivaliotis @ Mar 4 2007, 12:36 PM) OK, that did it. Thanks! I'm a bit surprised that I couldn't get to the same place by right-clicking and exploring from there on the Invoke Node. No matter how I did the search from there I simply couldn't find that Method. Again, thanks. That's a great feature.
  2. I'm using LV8.0.1 and am trying to implement: VI Server:VI:Front Panel:Center Which is a method, at least according to the Help system (Search Front Panel: center to see the entry). I simply cannot find this method when I try to set up an invoke node for it. I know that I can invoke this method (although I think of it as a property) by using the VI Properties interface but I need to be able to set this programmatically, not statically. I'm sure I must be doing something really DUMB, or perhaps DUMBER AND DUMBERER but 'whatev' (as my 20yo daughter would say) is happening, I can't figure it out. Can anyone help me out with this?
  3. QUOTE(tcplomp @ Mar 2 2007, 12:00 PM) OK, thanks. I'll look into it further.
  4. QUOTE(tcplomp @ Mar 2 2007, 01:09 AM) I use Total Command and agree -- it's essential. But I've never used either of the add-ons you've suggested and the links are only in Polish. Can you describe some of the benefits/features of the add-ons and/or can you point me to a way to get the info myself in English?
  5. "Save for previous failed for some unspecified reason. Memory could be full or the disk access may not be allowed." This message has consistenly appeared when trying to save the lvproj file from 8.20 to 8.0. Some times there were error messages about files being in the "wrong place" and so having to be loaded from an alternate location. Even when the requested files were copied to the indicated location -- and that particular "missing file" dialogue wasn't seen -- the same ending message as above was given.
  6. QUOTE(dsaunders @ Mar 1 2007, 08:22 AM) OK so here's a bit of a conundrum for me. I'm between 8.0.1 and 8.20. I have a project that I've been preparing to deploy using 8.0.1 and I've NOT wanted to migrate to 8.20 because that means downloading another LVRTE for my users. But I'm NOW having problems tyring to Save For Previous version -- specifically trying to back migrate some 8.20 code to 8.0.1. I get a "///can't complete..." the backwards save messge, indidcating memory may be full or... What's up with that and are there any good suggestions about how to actually complete a Save For Previous in this situation? BTW I did a search on Save For Previous here but wasn't directed to any specific threads. Perhaps it's just another "Dummy" question but any suggestion on how I could better navigate LAVA??? -- which IMO absolutely rocks!
  7. QUOTE(AdamRofer @ Feb 26 2007, 06:06 PM) Perhaps never means 0 times?? ;-)
  8. QUOTE(Val Brown @ Feb 21 2007, 02:05 PM) OK, so here's the follow up, for those who are still at all interested. The legacy i/o functions are working fine as of LV8.0.1. I assume that they will continue to function in LV8.2 but haven't done that test yet so can't confirm it. I'm still looking for a function that is not implemented in the legacy i/o set. I wat to have a function that will return an array of currently active serial ports -- like what the "comm serial port list.vi" provides in the openg serial library that was mentioned in an earlier post. I'd rather not have to use that specific VI, as I'd have to include its DLL support and the GNU stuff, etc; so I'm hoping that someone can point me to a windows API call or some other option. That way I can list for users the current, available serial ports and make their lives easier -- and I obviously don't want to do that through VISA either! Thanks for everyone's help.
  9. QUOTE(brian @ Feb 21 2007, 01:25 PM) OK, that's really interesting. Can you detail for me -- here or back channel -- exactly what you did? I'll try again to restore that functionality as I know how to do it and see what happens. I certainly hope I'm pleasantly surprised. BTW was it 8.2 or 8.0.1?
  10. QUOTE(rolfk @ Feb 13 2007, 11:20 PM) Rolf: Thanks for the suggestion re: Henz's serial port library. I've been trying to use it but am stumped and I'm certain that it's a fairly silly "stumping point" but, none the less, that's where I am. So I've thrown together a little demo which always returns 0 bytes at port. It is a trivial demo, just open the port, configure the device and see what's there at the port. The device is always "spewing data" so I should at least be seeing some bytes at port. Any help for the "next step" re: this library would be GREATLY appreciated. As I say I'm sure I'm doing something really silly and just can't see it.
  11. QUOTE(Neville D @ Feb 20 2007, 09:40 AM) I've used every version of VISA up to and including 4x currently. No, I wasn't using VISA until I was forced to do so with LV8. All through LV 7x I used the legacy i/o trick of copying the older serial.llb to replace the one in which the old functions were used as VISA wrappers. So my deployed code actually did call the older functions; however, LV 8x specifically disallowed this work around. I have tried a range of PCs both for development as well as deployed. And multiple different adapters. The KeySpan 19HS has consistently worked the best. All versions of VISA from 2.6 on Multiple different serail cables, as well as native PCI-based solutions, etc. It's been a real problem that has been "solved" by a two-fold process: 1. An older deployed version of my app built using LV7x and having the option to use or not use VISA. 2. The current deployed version built using LV8.0.1 and requiring the use of VISA.
  12. QUOTE(brian @ Feb 19 2007, 03:29 PM) Brian: I'm talking about the serpdrv VIs and I do believe that you will find that the code was already "ripped out" as of LV 8.0. Do you have any specific suggestions for my restoring that functionality? That would be REALLY helpful. I can give you prior SRs for this issue, going back to the "serial compatibility" VIs from LV 7x. They NEVER worked and so, throughout LV 7x days I used the "workaround" to continue using the serpdrv-related VIs. This is what I would truly love to do now but am blocked from doing so, as I pointed out above. BTW, the issue isn't USB-serial -- we had the same problems with the "serial compatibility" versions of LV7x when using 9pin serial ports, ie without USB-serial converters. What details would you like about the difficulties I'm seeing under VISA?
  13. QUOTE(Jim Kring @ Feb 18 2007, 02:11 PM) I thnk I take somewhat of a "middle path" here. LV scales well and allows for ad hoc programming, esp for fairly inexperienced system developers. Those are both strengths and both need to be kept in mind when pursuing these ideas. Perhaps I'm a good example about this. I have a background in Unix, C, C++, BASIC, etc, etc and yet have done my development work in LV, beginning with LV5x. Why did I go with LV -- despite other members of the team virtually demanding C++? The primary reason was how well ad hoc development could be done, esp "promoting fast failures" through prototyping. Where have the problems occured? With integrating external DLLs and with serial interfacing. I've posted on the serial interfacing problem elsewhere and it's an interesting aspect of this entire situation. The long and short of it is that VISA has simply never worked well in my major project. Now you would think that it would, but it doesn't and hasn't. And this despite the hard work of several LV consultants over the years and the work of NI to try to support the issues. Development templates and scripting are wonderful but the real world interfacing also needs to be handled well and that's many times where the real implementation issues arise.
  14. QUOTE(rolfk @ Feb 14 2007, 01:29 AM) I doubt it's the USB driver -- I use the KeySpan 19HS and have done so for quite some time. Used the 19 QW before that. If you give me another to try I will do so. I also don't think it's a multithreading issue -- the app has been multithreaded since the get go and, again, had no problems. I got out of doing serial interface over 20 years ago -- back in my Unix days -- and I really don't want to go back there so I'm hoping somebody has a really good suggestion or two in addition for me to follow up on, short of just diffing in and starting over. QUOTE(tnt @ Feb 14 2007, 01:07 AM) The screenshot was taken in LV8.0 and I verified that the Serial.llb is also present in LV8.20 Could you explain more what goes wrong when you are using VISA? Yes, lots of dropped connections -- error -.....194, -.......264, -.......343; and loads of performance hits -- enormous increase in CPU% as contrasted with prior releases that used the legacy i/o functions.
  15. QUOTE(tnt @ Feb 14 2007, 12:00 AM) Actually this is no longer true in LV8.x, and that's why I had to migrate to VISA. QUOTE(rolfk @ Feb 13 2007, 11:20 PM) First with the exception when starting with VISA I haven't met anything that could have been done with legacy serial but not with VISA. I'm using it quite often for all kinds of serial communication and haven't seen serious troubles in quite a while also with USB to serial adapters. If you really need to do it otherwise your best bet will be to use Martin Henz's serial port library that you can download from http://www.mhst.de/downloads.html. But the only real reason so far for using that was that it is independant of NI licensing which used to be complicated and difficult in the past (but they fixed that in the meantime) and it's installation is not requiring a 100MB download from NI. No functional reason to use that so far. Rolf Kalbermatter I've tried using that exact library but also got error messages from it and have received no follow up from Martin about what they mean. There were also some problems with the "Bytes at Port" function (whatever it was called), and it wasn't clear if that has been addressed. Have you used and/or otherwise tested that library?
  16. I'm continuing to experience a number of challenges using VISA with my deployed app. I access a serial device, now days using a USB-serial converter, and this has just been complicated by my needing to use VISA since LV8 came out. In LV7x I could continue to use the older "legacy serial i/o" primitives and these worked wonderfully. The problems is the NI has, in it infinite wisdom, somehow made it impossible to "hack around" to continue using those older VIs and functions. I'm wondering if anyone out there has come up with a way to still use the older legacy serial i/o functions within LV8? BTW the original deployed version of the app used LV5x and, throughout the evolution of the product, we ALWAYS had problems with the VISA interface. And that's the reason we maintained the use of the legacy serial i/o code even though NI no longer supported in after LV6x.
  17. Thanks so much. I've not used much of TSVN -- just Commit and Update really -- and I'm still not used to it being accessed via right click instead of a separate All Programs style access.
  18. OK, but how do I get to that window in TSVN?
  19. For me the pressure will come to migrate as new computers become increasingly more difficult to find with XP installed. Until then -- and until I'm satisfied with the stability of Vista -- I plan to stay as far away from it as possible. That's mostly because of the stability issues, as well as the general issues that come with migrating code to a new OS.
  20. For a deployed executables, check out: http://digital.ni.com/softlib.nsf/websearc...625709F005BAB77 -James Is that actually the latest NI-VISA RTE? I believe I have a v4.0 in use in my deployed software.
  21. Did the "beans" get moved to a new top-level?
  22. Yes, well that's what I was thinking and I was kind of hoping someone might have already done something just like this as an eg. I'm looking through the various threads to see what shows up. I'm glad to see that the PCT is actually being used creatively.
  23. I'm wondering if anyone has come up with a way to use the "Skin" process of WMP but in re: to LV Front Panels and XControls? It seems to me that it would add quite a lot to the UI experience if an end user could choose amongst a set of "skins" for an app and/or specify/create new ones. Any good ideas of a place to start?
×
×
  • Create New...

Important Information

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