LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA Serial Write is not writing

Solved!
Go to solution

To be honest, most topics like this end up saying "go buy the book".  The reason why is that the book goes in-depth as to why you should do the things it says to do.  This is a great example of "you get what you pay for".

 

That being said, something like this might be of more use to you.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 11 of 18
(863 Views)

That is exactly what I was looking for, thanks a ton!

0 Kudos
Message 12 of 18
(857 Views)

Hi Tarnarmour,

Is your problem got resolved?

Regards,
Srikrishna


0 Kudos
Message 13 of 18
(844 Views)

No, unfortunately I still have no idea why the VISA write is not working. But I'm plugging away at it, we'll see.

0 Kudos
Message 14 of 18
(821 Views)

I've figured something out. I put the whole thing I had there into a while loop, and things started working on the second or third iteration. After figuring that out I tried putting a delay after I connect to the Arduino, and I found that if I delay for any less than 1.7 seconds the write VISA just won't write (and, importantly, it doesn't seem to know that it has failed to write, or perhaps it is writing and the COM connection doesn't realize that it's not ready...) but any more than 1.7 seconds and everything seems to work.

 

Is this typical? Is there a more clean way of delaying until the COM port is ready? I feel like a set delay like this is not only ugly and maybe slower than necessary, it's also not very secure. This is going to be in a medical device so I'd like it to be more robust.

 

I'd appreciate any help, I feel way out of my depth here with this stuff.

0 Kudos
Message 15 of 18
(812 Views)

@Tarnarmour wrote:

I've figured something out. I put the whole thing I had there into a while loop, and things started working on the second or third iteration. After figuring that out I tried putting a delay after I connect to the Arduino, and I found that if I delay for any less than 1.7 seconds the write VISA just won't write (and, importantly, it doesn't seem to know that it has failed to write, or perhaps it is writing and the COM connection doesn't realize that it's not ready...) but any more than 1.7 seconds and everything seems to work.

 

Is this typical? Is there a more clean way of delaying until the COM port is ready? I feel like a set delay like this is not only ugly and maybe slower than necessary, it's also not very secure. This is going to be in a medical device so I'd like it to be more robust.

 

I'd appreciate any help, I feel way out of my depth here with this stuff.


Apparently not SO much out of your depth, because your feelings are spot-on!  Needing a hard-coded time delay when communicating with an instrument is usually a sure sign that you have an incomplete understanding of how to communicate with the instrument.  This almost surely will lead to problems with communications down the road, and definitely should be addressed.  You are also correct that waiting a set amount of time usually means time wasted because all your code should be doing is waiting for the message to show up, not waiting X seconds and then checking to see if a message arrived.

 

Unfortunately, I still can't offer you a solution, just an assurance that you are on the right track.  😞

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 16 of 18
(806 Views)
Solution
Accepted by topic author Tarnarmour

@Tarnarmour wrote:

I've figured something out. I put the whole thing I had there into a while loop, and things started working on the second or third iteration. After figuring that out I tried putting a delay after I connect to the Arduino, and I found that if I delay for any less than 1.7 seconds the write VISA just won't write (and, importantly, it doesn't seem to know that it has failed to write, or perhaps it is writing and the COM connection doesn't realize that it's not ready...) but any more than 1.7 seconds and everything seems to work.

 

Is this typical? Is there a more clean way of delaying until the COM port is ready? I feel like a set delay like this is not only ugly and maybe slower than necessary, it's also not very secure. This is going to be in a medical device so I'd like it to be more robust.

 

I'd appreciate any help, I feel way out of my depth here with this stuff.


The reason for the delay is easy.  The Arduino is meant to be user-friendly out-of-the-box.  Notice how nice it is to plug in the USB cable and then program it and communicate with it?  We can thank the bootloader for that.  Also, isn't it nice that you don't have to power-cycle or push any buttons to reprogram it?  To accomplish this, it was decided that the board should reset every time the USB serial port is opened.  The board waits a bit to see if the signal comes to tell it that you want to flash a new program, otherwise it proceeds to the bootloader.  The reason for the delay is that every time you open the serial connection, the board resets, pauses, and then runs the bootloader.  This can take 1-7 seconds depending the the board and software version.  In your case it takes 1.7 seconds.  

 

What can you do?  A few things.  You can put a capacitor on the reset line to hold the voltage and prevent the reset.  Not an elegant solution.  A more robust solution than waiting a fixed time is to put a serial write in the arduino startup code and have LV wait to receive this message before proceeding.  The downside here is that you have to be super careful that you actually close the VISA session.  If you abort without closing the port, the next time you run the open will be a no-op since LV already has the port open, and there will be no reset and no message sent.  For this reason, If I do not receive the startup message, then I will close the port, re-open, and try again.  Works well with my Firmata library.

 

The best solution I can think of is also in your long-term interest IMO.  Dump the bootloader and program it using an ICSP (can actually use a second Arduino for this).  The reset is still there, but without the bootloader the restart is very quick, practically instantaneous.  I would personally not ship a medical device with a bootloader.

Message 17 of 18
(801 Views)

Okay, this makes sense now, thanks!

 

After doing a bit of googling, I agree that using ICSP sounds like the best long term option. Hooray, another couple dozen hours of googling and frustration ahead 😉

0 Kudos
Message 18 of 18
(791 Views)