legacy serial i/o

[Val Brown]

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.

[Rolf Kalbermatter]

QUOTE(Val Brown @ Feb 13 2007, 07:14 PM)

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.

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

[tnt]

QUOTE(Val Brown @ Feb 14 2007, 01:14 AM)

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?

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.

http://lavag.org/old_files/monthly_02_2007/post-2311-1171439697.gif' target="_blank">

good luck...

TNT

[Val Brown]

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)

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?

[tnt]

QUOTE(Val Brown @ Feb 14 2007, 09:13 AM)

Actually this is no longer true in LV8.x, and that's why I had to migrate to VISA.

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?

[Rolf Kalbermatter]

QUOTE(Val Brown @ Feb 14 2007, 03:13 AM)

Actually this is no longer true in LV8.x, and that's why I had to migrate to VISA.

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?

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

[Val Brown]

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)

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.

[Rolf Kalbermatter]

QUOTE(Val Brown @ Feb 16 2007, 02:27 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.

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.

The CPU usage is an effect of the asynchronous operation of VISA nodes. It's a bit strange in fact since asynchronous is supposed to just safe CPU and in fact it does but in a strange way, due to LabVIEWs internal cooperative multithreading. Synchronous operation would lower CPU usage but block the diagram they are executing in until the operation is finished. The additional CPU usage is in so far not that bad as LabVIEW does relinquish the CPU to other tasks quite happily if they are there. If they aren't then yes it tends to grab quite a lot of the CPU to make sure to service the asynchronous call as fast as possible.

Dropped connection errors such as -1073807194 certainly have to do with the driver somehow. It could be that the driver got reset by whatever reasons. Maybe an USB bus reset. -1073807343 is insufficient location error, meaning an invalid VISA resource. -1073807264 is a strange error for serial port as Controller in Charge is a GPIB term but as such also would point to a driver error.

So yes from two of your errors I would conclude a serious serial port driver or hardware issue. The insufficient location error would point IMO to some wiring errors where you do not wire a valid serial port resource to the functions. The old serial functions were a bit more forgiving in this somtimes as they were just assuming a default number that pointed to the first serial port. But this was at the same time a serious software design flaw too.

Rolf Kalbermatter

Rolf Kalbermatter

[brian]

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

[Val Brown]

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?

[Neville D]

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

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.

[Val Brown]

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.

[Neville D]

QUOTE(Val Brown @ Feb 20 2007, 11:46 AM)

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.

In my experience the serpdrv was more forgiving of error conditions and seldom generated any errors (even if error conditions existed). This gave the false impression that things were fine.

You could try to trap the errors you are getting and either automatically reset the serial port and restart your communication or else try ignoring them to see if you can still communicate.

another issue is the output voltages on the USB adapters seldom reach the values as defined by the "recommended standard" (RS-232). It might be a low voltage issue causing the errors, or a floating ground.

It might be adding a few delays of 5 or 10 ms in a tight "bytes at port" loop.. it might be incorrect serial port initialization settings.. or another application having access to the particular port (Hyperterminal open?).

It might be a missing termination character on your data string.

You could try monitoring your serial ports using "portmon" (or was it serialmon ? Just google it) while under use with VISA and with serpdrv.

It might be poor design on the software.. without more specific info, (post your code), or more detailed debugging on your side (simplest serial comm that exhibits your problems) its difficult to play "doctor".

Neville.

[Val Brown]

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.

[brian]

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

[Val Brown]

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?

[Val Brown]

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.

[kai_n]

Sorry for answering so late. I found a link some weeks ago giving some VI-files and a dll-file, which has to be given away with the final application. In my Eyes, these VIs are even better than the original Labview ones. Just check them out!

http://www.mhst.de/downloads.html

[Val Brown]

QUOTE(kai_n @ May 8 2007, 01:00 AM)

Sorry for answering so late. I found a link some weeks ago giving some VI-files and a dll-file, which has to be given away with the final application. In my Eyes, these VIs are even better than the original Labview ones. Just check them out!

http://www.mhst.de/downloads.html''>http://www.mhst.de/downloads.html' target="_blank">http://www.mhst.de/downloads.html

Thanks for the reply. Yes, I had already tried that code and, as I indicated in a reply further up in this thread, I ran into some problems with that code and could not get it to work. I still haven't been able to get that other serial code working -- for whatever reason -- but the good news is that the NI legacy serial code was successfully used for a deployed version built with LV8.2.1. AND, that deployed version works in XP as well as in Vista.

[TG]

I don't mean to barge in but

Personally I have never understood why the legacy serial support has to be removed in later versions of LabVIEW.

Its one thing to hide it but remove it is quite another.

Why can't the customer decide what he needs to get his Application working?

Serial communications (as bad a bus as it is) is not going away any time soon in my world where instruments

in Laboratories still use it.

[Neville D]

QUOTE(John Rouse @ May 8 2007, 10:46 AM)

I don't mean to barge in but

Personally I have never understood why the legacy serial support has to be removed in later versions of LabVIEW.

Its one thing to hide it but remove it is quite another.

Why can't the customer decide what he needs to get his Application working?

Serial communications (as bad a bus as it is) is not going away any time soon in my world where instruments

in Laboratories still use it.

John,

For a complete explanation see http://openmeas.blogspot.com/2007/02/la-mort-du-serpdrv.html' target="_blank">Brian Powell's blog

Serial support isn't being removed; just the ancient serpdrv with its potentially buggy architecture WILL be removed in a future version. It's only a matter of time.

All the issues that people have with the VISA serial implementation (licencing, size) have long since been solved. Time to move on.

Neville.

[Val Brown]

QUOTE(Neville D @ May 9 2007, 08:55 AM)

John,

For a complete explanation see http://openmeas.blogspot.com/2007/02/la-mort-du-serpdrv.html' target="_blank">Brian Powell's blog

Serial support isn't being removed; just the ancient serpdrv with its potentially buggy architecture WILL be removed in a future version. It's only a matter of time.

All the issues that people have with the VISA serial implementation (licencing, size) have long since been solved. Time to move on.

Neville.

That's simply not my experience and, for that reason alone, I think it's important to NOT preclude access to serpdrv. Don't make it "easy" to use -- OK. Give preference to VISA in forums, etc -- OK. Don't support serpdrv -- OK, and nothing new. But what is the real reason that it has to be precluded?

If someone could answer THAT then I might rest a lot easier in this. But until then, I'm going to continue to be a small voice in support of continued choice -- even if it means knowing the back door means to use it.

[Rolf Kalbermatter]

QUOTE(Val Brown @ Jun 2 2007, 05:29 AM)

That's simply not my experience and, for that reason alone, I think it's important to NOT preclude access to serpdrv. Don't make it "easy" to use -- OK. Give preference to VISA in forums, etc -- OK. Don't support serpdrv -- OK, and nothing new. But what is the real reason that it has to be precluded?

If someone could answer THAT then I might rest a lot easier in this. But until then, I'm going to continue to be a small voice in support of continued choice -- even if it means knowing the back door means to use it.

As already mentioned it is old code in the LabVIEW source code together with a just as old external file. It won't be adapted in any way to support new platforms, the tools to create the old serpdrv file are long outdated (serpdrv being similar to an LSB in some ways), it is sooner or later going to break on OS revisions, does not support many features of serial ports (port enumeration etc.) and so on.

With the device manager in the Macintosh OS being completely different nowadays, the only reason to keep that code in LabVIEW is by now serpdrv. Nothing else can and will make use of it.

While the actual code in LabVIEW probably does not account for more than a few 10kB, it is always a good idea to keep an eye out on things that can be removed. As it is LabVIEW has mostly just continued to grow from a 4 MB executable in 5.1 to a more than 20MB executable already in 8.21.

While serial port communication isn't always trivial, fact is that VISA works very well for me in all applications that I have. If your code needs the old serpdrv to work correctly there is something wrong with it and you better start to schedule some time to look for a rewrite instead of waiting until it is breaking somehow, which will be always at a moment you have 20 other projects too that need to be finished yesterday.

Rolf Kalbermatter

[crelf]

Well said Rolf :thumbup:

[fliesskomma]

ZITAT(Val Brown @ Jun 2 2007, 12:29 PM)

That's simply not my experience and, for that reason alone, I think it's important to NOT preclude access to serpdrv. Don't make it "easy" to use -- OK. Give preference to VISA in forums, etc -- OK. Don't support serpdrv -- OK, and nothing new. But what is the real reason that it has to be precluded?

If someone could answer THAT then I might rest a lot easier in this. But until then, I'm going to continue to be a small voice in support of continued choice -- even if it means knowing the back door means to use it.

Hi Val,

I began using legacy serial drivers with LabView 6.0 which worked quite well with most devices to communicate with.

Later on, I developed Software for some serial communication with several serial ports, beeing busy at the same time. Every time when there was a continous (115kbd) bytestream to read, with a size above of a couple kByte, serious dataloss occured.

So I changed to VISA (Lv6.1 ... Lv7.1), where I could adjust read- and write buffer size and all communication errors vanished.

The adjustable buffer feature of VISA was the deciding reason for me to change. I didn't find this feature in the legacy drivers. Please tell me, if I'm wrong.

Maybe this information could prevent you running into problems.