outport.vi erratic response.

[Kura]

Alright, I start by opening a VISA with com1, my serial port, and then I use outport.vi to send a byte through the port. The program pauses for 25 milliseconds, and then sends a second byte, pauses again, sends a third byte, pauses again, and sends a fourth byte, and on the next frame in the sequence, I close the VISA connection. For some reason, the first three bytes are being properly transmitted to my reciever, but the fourth byte isn't being sent at all. Even with a slight delay before closing the byte isn't being transmitted. Any ideas about what could be causing this?

[tst]

Maybe your instrument identifies the third byte as a termination char?

I suggest you post your code and tell us what the third and fourth chars are.

[Kura]

Well, the VI is attached, though it won't let me add the three .txt files it must load to access the part of the program with the error. Essentially the error is in the loop structure where the serial outport commands are. The first three send properly, but the fourth doesn't send at all, or sends a 0 regardless of what I tell it to send. (I.E. I just watched it with the light bulb on and a 4 hit the output terminal and I watched a 0 come out on my reciever.)

[JeanPierre]

Why don't you use VISA Write function instead of writing directly to the port?

[Kura]

That produced a lot of errors because we need it to send -just- the number value. Sending with VISA Write seemed to include several bits of other information that was causing lots of errors in our reciever.

[JeanPierre]

---

Kura a écrit:
That produced a lot of errors because we need it to send -just- the number value. Sending with VISA Write seemed to include several bits of other information that was causing lots of errors in our reciever.

---

Most likely, you didn't format your data correctly using VISA Write. 
By the way, wouldn't using outport.vi to write a U32 at port 3F8 write data at addresses 3F8,3F9,3FA and 3FB and mess with other UART registers?

[rolfk]

You can't possibly hope to use VISA to intialize your port and then use outport to screw with the registers of the serial communication controller chip. This leaves the Windows communciation driver, which handles control of the serial port on behalve of VISA in a big confusion as the registers don't match its internal states anymore.
 
It is either all handling the serial port on your own with outport or letting VISA do all the work but not both mixed together. Basically if you say it doesn't work with VISA your external device either uses a very strange protocol such as 9 bit data or you send not the right information to the VISA Write. Also check the configuration of your VISA port. You can configure VISA through property nodes to automatically append a termination character to every message send. This would screw with a device only expecting specific characters. Please explain in more details what you saw being sent in addition to the actual byte that screwed with your device. Without more detailed information preferably optained by a serial port monitor device giving more accurate advice is virtually impossible.

Rolf Kalbermatter

Message Edited by rolfk on 08-12-2005 07:31 AM

[Kura]

I'm only writing U8's though.

[Kura]

Whenever I used Visa write to communicate it kept sending additional bits of data, I suppose its some sort of header and footer, but we're using a very specific reciever protocol. If it recieves -anything- other than the 8 bits of the U8 number it causes our model to stop functioning.

[rolfk]

You still don't say what that supposed additional data was it was sending. If you mean the start and stop bit, well that would be how RS-232 is supposed to work. There is really no way to stop that being done in normal serial port operation. If you need to do that, programming the serial port directly on register level entirely is the only option. If it is something else you will have to provide more information in order for anybody to figure out what you would possibly need to change in using VISA for your purpose.

Rolf Kalbermatter