Val Brown

QUOTE(Michael_Aivaliotis @ Mar 4 2007, 12:36 PM)

Here?

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.

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?

QUOTE(tcplomp @ Mar 2 2007, 12:00 PM)

EDIT: there is an english section

They have a forum with an (not that active), the extra options is a configured toolbar with extra buttons (synchronize amongst others), extra plugins (a dir size viewer, some like spacemonger:

Pre configured favorite places (profile/desktop/my docs/control panel), a lot of new viewers.

Just hit the download button on the link page.

Ton

OK, thanks. I'll look into it further.

QUOTE(tcplomp @ Mar 2 2007, 01:09 AM)

Total commander is an absolute must have, it is by far the best 'Norton Commander clone'.

Does synchronization, FTP (with wildcards), (un)zip, binary views, multiple file pattern renaming. Together with one of the add-on packs from totalcmd.pl ( or ), list extends dramatically and I can refuse to use explorer! :thumbup:

The program is shareware, but absolutely worth it's money.

Another good program is , as an XML/text/HTML editor

Ton

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?

"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.

QUOTE(dsaunders @ Mar 1 2007, 08:22 AM)

Considering that the LV 8.2 release came soon after the troublesome 8.0 release, and little if any code is being maintained in an 8.0 version, I would like to see an option in 8.2.1 to back-save directly to 7.1. Why install 8.0 just to get back saving?

And Tomi, weren't the majority of those bugs related to developing LVOOP code?

David

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!

QUOTE(AdamRofer @ Feb 26 2007, 06:06 PM)

Voting "never" did not work for me, or seemingly the other 0 people.

Perhaps never means 0 times?? ;-)

QUOTE(Val Brown @ Feb 21 2007, 02:05 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?

Well, I'm certainly surprised. I just got these VIs to work on a native XP box. So perhaps this is still a viable solution after all.

BTW, NI still "officially" believes that this solution doesn't work and is precluded in LV8x -- FWIW.

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.

QUOTE(brian @ Feb 21 2007, 01:25 PM)

I have a project that I keep deferring that says, "remove all the device manager code from LabVIEW". The device manager is the piece that is used by (and only used by) the old LabVIEW 6-era "serpdrv" serial VIs.

Val Brown said that you could copy these pieces to LV 7 and they will work, and if you copy them to LV 8, they won't work.

I was a little skeptical of this, because I hadn't done anything to actively disable the device manager (yet). But on the other hand, we don't test serpdrv any more, so it's certainly possible for something to go wrong. As we sometimes say, "code rots".

Anyway, I decided to copy serpdrv, _sersup.llb and serial.llb from LabVIEW 6.1 and install them in my LabVIEW 8.2 directory. From what I can tell, it is working. I sent "*IDN?\n" to an Agilent 33120A, and got a response back. "Bytes at Serial Port" also seemed to work.

I don't condone doing this, but I do think the escape hatch is still in place. I was actually a little disappointed that it worked, because I'd just as soon go ahead and rip out the device manager code if it isn't working.

Brian

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?

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

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.

QUOTE(Neville D @ Feb 20 2007, 09:40 AM)

Hi,

I have used serial VI's using VISA from LV 6.0.2 all the way through LV 7.1 with PC serial ports as well as USB-Serial adapters on a laptop. Some of the applications involved quite high data rates and ran for days on end (monitoring fuel-cell applications).

I have never experienced the kind of instability you are talking about. What version of VISA are you using? There used to be a problem with version 2.6 (or was it 3.0?) but that was fixed ages ago.

Like Brian mentioned, even starting LV 7, the "serpdrv" VI's were just wrappers on top of the VISA functions. They had already been "ripped out". So essentially you have been using VISA for a long time.

Have you tried

1 A Different PC

2 A different USB adapter

3 A different version of VISA (earlier or later)

4 A different serial cable

I don't remember what brand of USB adapter we used, but it was some cheap OTS unit that (thankfully) worked right out of the box. But if you do have issues with your USB adapter try looking to see if NI offers a product. It may not be cheap, but you are guaranteed it will work with VISA/LV.

Neville.

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.

QUOTE(brian @ Feb 19 2007, 03:29 PM)

I was actually working on a blog posting about "serpdrv" when I discovered this thread.

It wasn't clear from the original post if the discussion was about the old "serpdrv" VIs (used from LV 2.5 through 6.x) or about the "serial compatibility" VIs (used in LV 7.x and later). They have the same API, but the latter are implemented on top of VISA.

To my knowledge, we didn't do anything in 8.x to prevent the "serpdrv" VIs from working, but we haven't tested that scenario in a few years. As I'll mention in my blog, it's inevitable that in the future, we will actively do something to keep "serpdrv" from working. (Basically by ripping out some code from LabVIEW.)

I'm not aware of problems with the "Serial Compatibility" VIs in 8.x. I do know that we've had issues in the past with various USB-Serial devices. If you're using a computer with a built-in serial port (read "PC"), you might try that to see if there's a difference in behavior. If you're using a Mac, I'm interested in what you learn, because I'm thinking of connecting my Mac Mini to my stereo receiver and TV through serial cables.

I also want to comment on Rolf's message about CPU usage. There's supposed to be code in the VISA driver to prevent it from using so much CPU when it's waiting for the asynchronous I/O. If you're seeing that in the latest driver, I'd be interested in knowing that it's still a problem. Send me the details.

Brian Powell

LabVIEW R&D

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?

QUOTE(Jim Kring @ Feb 18 2007, 02:11 PM)

I'm with Mike on this one -- I respectfully (and strongly) disagree with this perspective. I feel that it's not fair to say that it is LabVIEW's fault that an application does not scale. LabVIEW applications can be made to scale just fine, but it does requires frameworks, software engineering (and team) know-how, and a lot of discipline to do so -- for example, you need some form of OOP design and framework, you need templates, automated builds, automated unit test execution, a well communicated software development process, collaboration tools, etc.

Sorry if I seem a little defensive, but I'm pretty fired up about this. I love LabVIEW (and need my applications to scale well) and thus, I've dedicated a significant fraction of my career working on tools that allow LabVIEW applications to scale and trying to educate myself and others on how to do better software engineering in LabVIEW.

I guess the point of my rant is that, in my opinion, we all need to focus on (and be vocal about) the real problem with the state of software engineering in LabVIEW -- that the state of software engineering tools for LabVIEW is pretty meager. And, NI isn't facilitating this, as much as they could, in my opinion. The solution, in my opinion, is an open, machine-readable/writable source code format (I vote for XML). I good first start would be to open up http://forums.lavag.org/LabVIEW-VI-Scripting-f29.html' target="_blank">scripting.

Cheers,

-Jim

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.

QUOTE(rolfk @ Feb 14 2007, 01:29 AM)

No I haven't really used it for actual communciation. Just the serial port enumeration to display available serial ports in a user interface that communicates through XML with an external application that does the actual (proprietary) serial protocol. Seemed like overkill to have to install VISA for that functionality and the VISA Find Resources is also a bit slow.

The fact that you get errors in Martins library too seems to point to flaky USB-serial adapter drivers. Have had them in the past too, with causing me all kinds of troubles such as working for hours and suddenly not doing so without a reboot. There are definitely USB adapters and USB adapters and finding the good ones is a trial an error operation. Possibly the old serial functions just didn't do proper error handling, masking those problems althogether. They are from a time when Windows was 3.1, 16bit and anything than multithreading so they probably got away with anything but a proper error handling. Win32 is a bit more demanding but the legacy serial driver has to my knowledge not been updated much since the initial development somewhere in 1991 and probably was a bit of a mess from the old 16bit to 32bit translation hacks that had been necessary for the Windows 3.1 version. For Win32 it was probably mostly recompiled but not much more.

It definitely had its quirks and limitations but maybe your library just works around them somehow and now you face troubles with adapting these hacks and quirks to VISA proper.

Rolf Kalbermatter

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)

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.

QUOTE(tnt @ Feb 14 2007, 12:00 AM)

Hi,

when upgrading older projects to LV7 or LV8, I did not have any troubles using the old-style RS232 vi's,

only now they use VISA under the hood, but I haven't noticed a difference in behaviour.

If you are more familiar with the old-style RS232, you could keep on using them,

these are located in in the vi.lib\Instr\Serial.llb but are not present on the default palettes.

good luck...

TNT

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)

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?

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.

right-click in explorer and...

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.

So, thanks for answers.

I hope I found out the problem. TSVN checks all changes in all windows files (recursively) which deals something which version controlled files(incl. Windows Temp Directrory). May happen that TSVN and LV want to open or change the same file simultaneously and here it crashes. To avoid this, change settings in Tortoise options shown on the picture (so set from "standard" to "shell"). I found it out using Filemon Tool, which shows all events in windows (which file on which time was opened, changes and so on).

Regards, Eugen

OK, but how do I get to that window in TSVN?

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.

You've hit the nail on the head.

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.

Ben: please repost your question as a new discussion topic. I think it is worthy of being a top-level post, and it is certainly off topic for this thread. But it's a good question.

Did the "beans" get moved to a new top-level?

Here are several options I can think of -

...Probably the most "skinny" skin would be to create your controls as pictures and use the picture control to generate your interface.

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.

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?

Thanks fpr the example.