LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial-data-corruption using example code

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
0 Kudos
Message 1 of 8
(1,695 Views)
Those should be the only parameters required. How far are you trying to transmit the data? What exactly does the corruption look like?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 8
(1,695 Views)
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
0 Kudos
Message 3 of 8
(1,695 Views)
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

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 4 of 8
(1,695 Views)
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.
0 Kudos
Message 5 of 8
(1,695 Views)
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"?
0 Kudos
Message 6 of 8
(1,695 Views)
That's a framing error according to the error handler. Check the serial port configuration.
0 Kudos
Message 7 of 8
(1,695 Views)
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?
0 Kudos
Message 8 of 8
(1,695 Views)