Serial-data-corruption using example code

[SimonFay]

Now that I'm running application(s) built from the 'Labview<->Serial.vi' specimen code I'm getting corruption of the transmitted data (even single-chars) - are there any parameters in this code (and when using serpdrv) that require attention other than the obvious baud/parity/length/stop? Thanks

[mikeporter]

Those should be the only parameters required. How far are you trying to transmit the data? What exactly does the corruption look like?

Mike...

[SimonFay]

Mike - like a baud rate problem, that's what! I can run the same app'n on a PC already happily fitted with NI-488 serial-ports without intervening in settings and get clean data, but try it on PCs with conventional RS232 and it's mangled in a manner highly suggestive of baud-rate schism...(plus, writing-out from the port gives a framing error at the instrument end)

Shame: dispensing with NI488 had been vital to the project's success

[mikeporter]

Email me the code you're using to read and write the serial port and I'll take a look at it..

Mike...
mporter@arielcorp.com

[Dennis_Knutson]

LabVIEW <-> Serial.vi uses VISA and not the old serpdrv. That explains why it works on a pc with NI-488 installed - those pc's have VISA. To use the VI on a pc with just serial ports, install the VISA run-time engine.

[SimonFay]

Thanks chaps, installing VISA has greatly improved matters (even managed to capture some data although must restart app'n for each successful catch). Wonder if any of you know of a most-likely meaning for Error Code 16392, a code with an apparent multiplicity of meanings that has been popping up after every catch, prompting app'n restart. Too much data in buffer? Reduce n in "read n bytes"?

[Dennis_Knutson]

That's a framing error according to the error handler. Check the serial port configuration.

[SimonFay]

eh? I thought that if my captured data was readable then the config must be OK - the config couldn't change mid-run could it?