VISA Write error

[michele.santucci]

I need to replace a test procedure made using external software with LabView code.

The test just write a text on a serial port, read it back on another serial port and compare

the text to be sent with the one received. 

I wrote this simple VI (attached):

The text to be sent (attached) is about 30kb.

I got this error:

Error -1073807339 occurred at VISA Write in DIG_X_rs485_test2.vi

Possible reason(s):

VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.

After the timeout occurred I got this:

The resulting rx buffer is evaluated much time before the tx timeout occours

and just receive the reported 739 bytes that are not the first '739' bytes neither the latest.... 

BTW I'm using virtual coms (com0com). 

Any hint?

Best regards,

 Mike

[michele.santucci]

BTW if I limit the tx to send just 700 bytes everything works.

[GerdW]

Hi Mike,

---

@michele.santucci wrote:

Any hint?

---

Did you care for TermChars? (Apparently you did not…)

At 115.2kBaud you transfer ~11kB/s, so to send your 30kB file should take ~3s.

Nevertheless I would send in chunks of 1kB or 2kB. Reading the port can still wait for the full amount of data…

Edit: After your edits/2nd post I would send data in chunks of 512 bytes…

[michele.santucci]

Hi Gerd!

---

---

@michele.santucci wrote:

Any hint?

---

Did you care for TermChars? (Apparently you did not…)

I must? I don't really think I should (but I'm ignorant) and such input text should not

contains anything else than plain ascii letters and maybe numbers... 

---

At 115.2kBaud you transfer ~11kB/s, so to send your 30kB file should take ~3s.

Yes I tried with a 60s timeout... and also shorter ... same result.

Nevertheless I would send in chunks of 1kB or 2kB.

Ok I can manage it this way with two different asyncronous loops?

Reading the port can still wait for the full amount of data…

The read doesn't get in error but as I stated it just received a random chunk of 738 bytes.

Edit: After your edits/2nd post I would send data in chunks of 512 bytes…

[MECSO]

I'm not sure about it, but just as idea: As it is fully parallel the write connection can be closed before everything is read, because the flush buffer is by default configoured to read buffer I think.

[crossrulz]

---

@michele.santucci wrote:

Hi Gerd!

---

---

@michele.santucci wrote:

Any hint?

---

Did you care for TermChars? (Apparently you did not…)

I must? I don't really think I should (but I'm ignorant) and such input text should not

contains anything else than plain ascii letters and maybe numbers... 

---

How do you define your messages? How is a receiver supposed to know it got a complete message? This is called protocol. For messages that are only ASCII letters and numbers, a Line Feed (0xA) is the most common termination character. The termination character is at the end of the message so the receiver knows it can do something with the message. VISA has the ability to set the termination character and then the VISA Read will stop reading when it encounters that termination character and return a single message.

For a lot more details: VIWeek 2020/Proper way to communicate over serial

You stated that you are replacing software. Is there any documentation on the protocol the old software was using to communicate with whatever devices?

[GerdW · Accepted solution]

Hi Michele,

---

@michele.santucci wrote:

Hi Gerd!

---

---

@michele.santucci wrote:

Any hint?

---

Did you care for TermChars? (Apparently you did not…)

I must? I don't really think I should (but I'm ignorant) and such input text should not

contains anything else than plain ascii letters and maybe numbers...

---

Did you read the help for the VISAConfigureSerialPort function?

Did you read the help for ALL its input values?

You are ignorant when you don't read that help and ignore its implied VISA behaviour!

(The video linked by crossrulz REALLY is worth watching!)

[michele.santucci]

---

---

How do you define your messages? How is a receiver supposed to know it got a complete message? This is called protocol.

You're making it too complex. This test doesn't need to (I better say it MUST NOT) make any kind of effort to enforce the reliability of the communication channel. It must work the way I said.. the procedure must read the content of the input file into a buffer send it trough the serial port without any protocol management.. it just send it. On the other end the data are recevied into another buffer then the two buffers are compared .. if they are identical the test is passed.

---

You stated that you are replacing software. Is there any documentation on the protocol the old software was using to communicate with whatever devices?

---

Nope.

The test is made trough two serial ports connected trough a "null modem cable" (not really but you can think about it in this way).

It's not meant to have any protocol over this communication just plain bytes transfered from one serial to another.

If you're familiar with realterm and winmerge these are the scripts that are used to manage the test till now:

Send and receive file:

@echo off
set port_TX=8
set port_RX=9

start realterm caption=receiving_RT half=1 port=%port_RX% capquit=C:\TEMP\output_file.txt capsecs=7

start /wait realterm caption=transmitting_RT half=1 port=%port_TX% sendquit=input_file.txt

Compare files:

@echo off

start /wait "" WinMergeU /noninteractive /enableexitcode input_file.txt C:\TEMP\output_file.txt

echo %errorlevel%

[michele.santucci]

you're right: I fixed that.

[michele.santucci]

---

---

Did you read the help for the VISAConfigureSerialPort function?

Did you read the help for ALL its input values?

You are ignorant when you don't read that help and ignore its implied VISA behaviour!

I got your point... those little phunny flags...